API Acceptable Use Policy

1.1 This API Acceptable Use Policy (“AUP”) establishes the permitted and prohibited uses of the StampMitra Developer Platform, APIs, SDKs, Documentation, Sandbox, Production environment, API credentials, webhooks and related technical services.

1.2 The purpose of this Policy is to ensure that StampMitra APIs are used:

• lawfully;
• securely;
• responsibly;
• proportionately;
• in accordance with their intended functionality;
• without compromising other users or systems.

1.3 This Policy forms part of the StampMitra Developer contractual framework.

1.4 The Policy must be read together with:

• StampMitra Developer Terms of Service;
• StampMitra Developer Privacy Policy;
• Data Processing Addendum;
• API Security Policy;
• Service-Specific Terms;
• Billing and other applicable policies.

This Policy applies to:

• Individual Developers;
• Freelancers;
• Consultants;
• Organizations;
• Agencies;
• Technical teams;
• Workspace administrators;
• Project members;
• API integrators;
• Sandbox users;
• Production users;
• persons acting through Developer credentials.

It applies whether API access is used directly or incorporated into another application, website, software product, mobile application, workflow or service.

Developers may use StampMitra APIs only for:

«lawful, authorized, transparent and technically appropriate purposes consistent with the API's documented functionality and approved use case.»

The fact that a technical endpoint permits a request does not by itself mean that the request is legally, contractually or operationally permitted.

Authorized use generally includes:

• building legitimate software integrations;
• testing APIs in Sandbox;
• operating approved Production integrations;
• processing lawful customer requests;
• retrieving permitted API responses;
• automating legitimate business workflows;
• integrating verification functionality;
• integrating approved document workflows;
• using e-Stamp functionality for lawful transactions;
• using e-Sign functionality for authorized signing workflows;
• maintaining internal business applications.

5.1 Production access may be granted for a specific use case.

5.2 The Developer shall not materially change the nature of the use case without appropriate approval where StampMitra requires such approval.

5.3 Examples of material changes include:

• changing the target customer segment;
• changing the purpose of verification;
• introducing automated bulk processing;
• using an API for a substantially different industry;
• introducing a new category of personal data;
• materially increasing transaction volume;
• reselling API access.

6.1 Individual Developers may use StampMitra APIs for legitimate personal, freelance, consulting, educational, research or client-development purposes where permitted.

6.2 An individual Developer does not need to falsely represent themselves as a company.

6.3 Where an individual Developer acts for a client, the Developer must have appropriate authority from that client.

7.1 Organizations must ensure that users accessing their Workspace are appropriately authorized.

7.2 Organizations are responsible for activities performed through credentials under their control.

7.3 Organizations should implement internal access controls appropriate to the sensitivity of their API usage.

8.1 A Developer may integrate StampMitra APIs into a client's application where authorized.

8.2 The Developer must not:

• expose the client's API credentials;
• transfer unauthorized Production credentials;
• use one client's credentials for another client;
• combine client data improperly;
• disclose client information to unauthorized parties.

8.3 Separate Projects or credentials should be used where technically appropriate.

Developers shall:

• keep API Keys confidential;
• restrict credential access;
• rotate compromised credentials;
• revoke unused credentials;
• avoid committing secrets to public repositories;
• avoid embedding secret Production credentials in client-side applications;
• immediately report suspected compromise.

The following are prohibited unless expressly authorized:

• selling API Keys;
• publishing API Keys;
• sharing Production credentials publicly;
• posting credentials in public forums;
• distributing credentials to unauthorized customers;
• allowing unknown third parties to use credentials.

11.1 A Developer may not represent StampMitra API access as an independently transferable credential or license.

11.2 A Developer may build a legitimate product powered by StampMitra APIs where permitted.

11.3 Where the Developer wishes to provide API-powered functionality to third parties, the Developer must comply with applicable commercial, technical and Production-access requirements.

A Developer must not:

• access another Developer's Project;
• access another user's account;
• use another person's API Key;
• bypass authentication;
• obtain credentials without authorization;
• use leaked credentials;
• access restricted endpoints.

The Developer shall not:

• impersonate another Developer;
• impersonate StampMitra;
• falsely represent affiliation;
• falsely represent government authorization;
• falsely represent regulatory approval;
• create deceptive developer profiles.

The Platform must not be used to:

• create fraudulent identities;
• impersonate individuals;
• fabricate identity records;
• manipulate verification information;
• facilitate identity theft;
• knowingly process stolen identity documents.

The Information Technology Act, 2000 contains provisions addressing identity theft and cheating by personation using computer resources.

Verification APIs must not be used to investigate or verify a person without a lawful and appropriate purpose.

Prohibited activities include:

• unauthorized employee surveillance;
• stalking;
• harassment;
• unlawful background investigations;
• checking individuals without appropriate authorization;
• mass profiling without lawful basis.

Developers must not use StampMitra APIs to create unauthorized databases of personal information.

Prohibited activities include:

• bulk harvesting;
• systematic extraction;
• scraping through APIs;
• building unauthorized identity databases;
• collecting personal data unrelated to the requested Service.

Developers must not systematically enumerate:

• identities;
• account numbers;
• application numbers;
• document numbers;
• transaction identifiers;
• verification identifiers;
• other sequential or predictable identifiers

for the purpose of discovering information that the Developer is not authorized to access.

The following are prohibited:

• brute-force authentication;
• OTP guessing;
• credential stuffing;
• password spraying;
• token guessing;
• systematic identifier guessing;
• repeated authentication attempts intended to defeat security controls.

Developers must not attempt to circumvent rate limits through:

• multiple unauthorized accounts;
• rotating credentials;
• IP rotation;
• proxy networks;
• artificial Project creation;
• credential cycling;
• distributed request abuse.

Developers must not generate traffic intended to:

• overwhelm systems;
• degrade availability;
• exhaust resources;
• cause service disruption;
• interfere with another Developer.

This includes intentional application-layer denial-of-service activity.

Production load testing requires prior authorization where it could materially affect StampMitra infrastructure.

Developers should conduct load testing in an approved environment and within expressly agreed limits.

Unapproved stress testing is prohibited where it could:

• impair service;
• trigger infrastructure failures;
• affect other customers;
• consume disproportionate resources.

StampMitra may permit security research through an authorized vulnerability-reporting process.

Absent authorization, Developers must not:

• exploit vulnerabilities;
• access restricted information;
• modify data;
• persist in compromised systems;
• exfiltrate information;
• disrupt services.

Developers who discover a security vulnerability should report it through the designated StampMitra security channel where one is provided.

Reports should contain sufficient technical information to enable investigation.

Where security testing has been expressly authorized, the Developer shall:

• remain within approved scope;
• use approved credentials;
• respect rate limits;
• avoid unnecessary data access;
• avoid service disruption;
• promptly report material findings.

Developers must not attempt to reverse engineer StampMitra systems to:

• discover proprietary source code;
• reconstruct confidential architecture;
• identify confidential upstream providers;
• extract secret algorithms;
• bypass security mechanisms.

Mandatory rights that cannot lawfully be restricted remain unaffected.

Developers must not attempt to identify confidential Underlying Service Providers through:

• traffic fingerprinting;
• undocumented endpoints;
• response manipulation;
• reverse engineering;
• infrastructure reconnaissance;
• unauthorized technical analysis.

StampMitra may abstract upstream services behind its own API architecture.

Developers must not use confidential information obtained through StampMitra to circumvent StampMitra's contractual or commercial relationships.

This does not prohibit lawful independent use of publicly available services unrelated to confidential StampMitra information.

StampMitra APIs must not be used to facilitate:

• financial fraud;
• identity fraud;
• document fraud;
• application fraud;
• payment fraud;
• impersonation;
• false claims;
• fraudulent registrations;
• fraudulent transactions.

Developers must not use StampMitra services to create, process or facilitate:

• forged documents;
• materially altered documents;
• fabricated certificates;
• fraudulent declarations;
• counterfeit records;
• manipulated identity documents.

e-Stamp-related APIs must not be used to:

• create fraudulent stamp transactions;
• misrepresent stamp duty;
• manipulate transaction information;
• circumvent applicable state requirements;
• fabricate stamp records;
• misuse another person's information.

e-Sign functionality must not be used to:

• sign without authorization;
• impersonate a signer;
• obtain signatures through deception;
• manipulate signing records;
• forge authorization;
• misrepresent a signature as belonging to another person.

Developers must not use StampMitra APIs to circumvent required:

• consent;
• notice;
• authorization;
• parental permission;
• identity verification;
• signing authorization.

Developers shall not use APIs to process children's personal data unless:

• the relevant Service permits it; and
• applicable legal requirements are satisfied.

The DPDP Act defines a child as an individual who has not completed eighteen years of age.

Developers must not submit unnecessary sensitive or high-risk information.

Examples include:

• passwords;
• authentication secrets;
• unnecessary financial credentials;
• unnecessary biometric information;
• unrelated medical information;
• private communications.

StampMitra APIs must not be used for unlawful:

• surveillance;
• tracking;
• monitoring;
• profiling;
• employee monitoring;
• customer monitoring;
• relationship monitoring.

The Platform must not be used to facilitate:

• stalking;
• harassment;
• intimidation;
• threats;
• repeated unwanted contact;
• targeted personal-data collection.

Developers must not use StampMitra services to unlawfully discriminate against individuals based on protected or legally relevant characteristics.

StampMitra APIs must not be used to facilitate unlawful:

• money laundering;
• fraud;
• unauthorized payment activity;
• financial impersonation;
• illegal investment schemes;
• fraudulent lending;
• fraudulent collection activity.

Developers must comply with applicable sanctions, export restrictions and other legally binding restrictions applicable to their activities.

StampMitra may restrict access where required by law or risk controls.

The Platform must not be used to facilitate:

• terrorism;
• terrorist financing;
• extremist violence;
• recruitment for violent extremist activity;
• unlawful procurement;
• operational support for violent organizations.

Developers must not use StampMitra systems to distribute or facilitate:

• malware;
• ransomware;
• spyware;
• viruses;
• worms;
• trojans;
• destructive scripts;
• malicious payloads.

Developers must not use StampMitra branding, APIs or credentials to create:

• phishing websites;
• credential-harvesting pages;
• deceptive login pages;
• fraudulent messages;
• impersonation campaigns.

It is prohibited to use the Platform to:

• collect passwords;
• steal API Keys;
• harvest OTPs;
• obtain authentication tokens;
• intercept credentials;
• facilitate credential theft.

Developers must not use StampMitra services to facilitate deceptive attempts to obtain:

• passwords;
• OTPs;
• identity documents;
• financial information;
• authentication credentials;
• confidential records.

Developers must not expose personal data through:

• public API responses;
• unsecured logs;
• public repositories;
• browser-side secrets;
• unprotected storage;
• public webhooks;
• unsecured dashboards.

Developers must not publish:

• Production API Keys;
• webhook secrets;
• access tokens;
• private credentials;
• confidential API configuration;
• personal data.

Secret Production credentials should not be embedded in:

• frontend JavaScript;
• publicly distributed mobile applications;
• browser extensions;
• client-side source code

where the credential could reasonably be extracted.

Developers must implement reasonable controls for webhook endpoints, including where applicable:

• signature validation;
• authentication;
• replay protection;
• HTTPS;
• request validation;
• appropriate access restrictions.

Developers must not:

• expose webhook data publicly;
• forward webhook payloads to unauthorized recipients;
• deliberately create webhook loops;
• trigger excessive webhook traffic;
• misuse webhook events for unauthorized profiling.

Developers must store API responses securely and only for legitimate purposes.

Where an API response contains personal data, the Developer must apply appropriate retention and security controls.

Developers should request and retain only the information reasonably necessary for their intended purpose.

The existence of an API field does not authorize unrelated collection.

Developers must not systematically probe undocumented endpoints or parameters to discover:

• hidden functionality;
• internal APIs;
• administrative endpoints;
• confidential data;
• security weaknesses.

Use of undocumented endpoints is prohibited unless expressly authorized.

Documentation may change as APIs evolve.

Developers must not manipulate protocol-level behavior to bypass:

• authentication;
• authorization;
• rate limits;
• geographic restrictions;
• API scopes;
• security controls.

Developers must not forge or manipulate:

• authentication headers;
• webhook signatures;
• transaction identifiers;
• request identifiers;
• authorization claims;
• service metadata

to obtain unauthorized functionality.

Developers must not intentionally manipulate or destroy records to:

• conceal fraud;
• evade audit;
• hide unauthorized usage;
• defeat security investigation;
• misrepresent API activity.

Attempts to conceal API activity through:

• credential cycling;
• multiple unauthorized accounts;
• false metadata;
• proxy chains;
• artificial identities;
• deletion of relevant evidence

may constitute a material policy violation.

Creating multiple Developer Accounts is not prohibited by itself.

However, multiple accounts must not be created to:

• evade suspension;
• bypass limits;
• obtain duplicate promotional credits;
• circumvent verification;
• conceal prohibited activity.

Sandbox must not be used to:

• attack Production;
• discover confidential architecture;
• test unauthorized credentials;
• conduct abusive automated traffic;
• circumvent Production restrictions.

Developers should not place real personal or confidential data in Sandbox unless expressly permitted.

Synthetic or anonymized test data should be used wherever reasonably possible.

Automation is permitted where:

• technically supported;
• within rate limits;
• lawful;
• authorized;
• reasonably implemented.

Automation becomes prohibited where it is designed to:

• overwhelm systems;
• evade controls;
• harvest information;
• generate fraudulent transactions.

Bots may be used for legitimate API integration.

Bots must not be designed to:

• attack services;
• evade security controls;
• create unauthorized accounts;
• conduct mass enumeration;
• manipulate service availability.

Scraping of StampMitra APIs or Platform data is prohibited where it:

• circumvents API controls;
• extracts data beyond authorization;
• creates unauthorized databases;
• violates applicable limits;
• impacts service performance.

Developers must not combine StampMitra data with other datasets for unlawful profiling, surveillance or discriminatory purposes.

Developers must not attempt to reidentify individuals from:

• anonymized data;
• aggregated information;
• masked identifiers;
• pseudonymized records

where such activity is unauthorized or unlawful.

Developers should use synthetic data that does not correspond to real individuals when realistic personal data is unnecessary.

Developers must not intentionally provide false information to obtain Production approval, including:

• false organization details;
• false use cases;
• false transaction volumes;
• false identity information;
• false domain ownership.

Developers must not:

• submit fabricated documents;
• use another person's documents;
• manipulate verification information;
• circumvent required checks;
• create multiple identities to evade verification.

Developers must not:

• manipulate billing records;
• create fraudulent payment confirmations;
• exploit billing errors deliberately;
• abuse promotional credits;
• use stolen payment information.

Promotional or trial credits may not be multiplied through:

• duplicate accounts;
• false identities;
• automated registration;
• referral manipulation;
• credential cycling.

Developers must not intentionally consume disproportionate resources for the purpose of:

• degrading availability;
• denying access to others;
• obtaining unfair capacity;
• interfering with platform operations.

Developers must not use StampMitra as a mechanism to attack or abuse another service.

This includes:

• credential attacks;
• automated harassment;
• unauthorized scanning;
• malicious submissions;
• denial-of-service attacks.

Where a Service interfaces with government or authorized systems, the Developer must comply with the relevant legal and technical restrictions.

StampMitra APIs must not be used to:

• overload government systems;
• submit fraudulent applications;
• bypass official controls;
• manipulate government records.

Developers must not represent StampMitra-generated or processed documents as:

• government-certified where they are not;
• legally approved where approval has not occurred;
• professionally certified where no such certification exists.

Developers must not falsely state that:

• they are StampMitra;
• they are an authorized StampMitra employee;
• their product is owned by StampMitra;
• StampMitra guarantees their service;
• StampMitra has approved a claim where it has not.

StampMitra names, logos and trademarks may only be used according to applicable brand permissions.

Documentation may not be:

• republished as proprietary Developer documentation;
• altered to misrepresent API capabilities;
• used to create deceptive claims;
• distributed with confidential materials.

Developers must not publicly disclose sensitive security information obtained through authorized security testing before reasonable remediation opportunity has been provided, unless disclosure is required by law.

The Developer must not develop or deploy exploits targeting StampMitra systems without authorization.

Authorized security research must remain within the approved scope.

Developers must not attempt to cause StampMitra systems to execute:

• arbitrary code;
• unauthorized scripts;
• malware;
• destructive commands;
• unauthorized database operations.

Direct database access is prohibited unless expressly authorized.

Developers must not attempt to:

• access database ports;
• obtain database credentials;
• query internal databases;
• exploit database interfaces;
• extract internal records.

Developers must not attempt to access:

• internal admin panels;
• employee systems;
• infrastructure dashboards;
• internal APIs;
• administrative credentials;
• internal monitoring systems.

Unauthorized network reconnaissance against StampMitra infrastructure is prohibited, including:

• port scanning;
• service discovery;
• vulnerability scanning;
• infrastructure enumeration.

Developers must not use StampMitra-related domains or infrastructure to:

• conduct phishing;
• impersonate services;
• redirect users deceptively;
• host malware.

StampMitra services must not be used to facilitate:

• spam;
• phishing;
• fraudulent notifications;
• deceptive communications;
• OTP interception;
• impersonation.

OTP systems must not be used for:

• OTP flooding;
• harassment;
• automated abuse;
• unauthorized account access;
• OTP interception.

Developers must not submit deliberately false or malicious support requests to:

• overload support;
• obtain unauthorized access;
• manipulate account status;
• social-engineer support personnel.

Developers must not falsely claim:

• account ownership;
• organizational authority;
• emergency access requirements;
• security incidents that do not exist

for the purpose of obtaining unauthorized assistance.

Developers must accurately communicate the nature of StampMitra-powered results to their End Users.

They must not falsely represent:

• verification results;
• government status;
• document validity;
• e-Sign status;
• transaction completion.

Developers must not intentionally alter or selectively present API results in a manner that creates a materially false representation of the underlying result.

Where StampMitra results contribute to automated decisions affecting individuals, the Developer remains responsible for ensuring that the decision-making process complies with applicable law.

StampMitra data must not be used to construct unlawful discriminatory profiles or decision systems.

StampMitra may require additional review for high-risk use cases involving:

• identity verification at scale;
• financial eligibility;
• regulated services;
• government-facing workflows;
• high-volume document processing;
• large-scale personal-data processing;
• automated decisions affecting individuals.

A Developer must notify StampMitra where a material increase in volume could reasonably affect:

• API capacity;
• rate limits;
• security;
• underlying services;
• transaction processing.

Developers shall respect:

• documented rate limits;
• transaction limits;
• concurrency limits;
• payload limits;
• authentication limits;
• storage limits;
• webhook limits.

Developers should implement:

• retry limits;
• exponential backoff;
• idempotency where supported;
• timeout handling;
• duplicate prevention.

Repeated retries without backoff that materially increase system load may constitute abuse.

Developers should use appropriate idempotency mechanisms where available to avoid accidental duplicate transactions.

Developers must not intentionally retry failed requests at excessive rates to force a successful response or bypass system controls.

Developers must use API resources proportionately and must not intentionally monopolize capacity.

The Developer shall maintain appropriate safeguards for data received from StampMitra, including:

• encryption where appropriate;
• access control;
• secure storage;
• credential management;
• secure deletion;
• appropriate logging.

The Developer shall promptly report material security incidents affecting StampMitra credentials, systems or Developer integrations.

Where a credential is suspected to be compromised, the Developer should:

• 1. revoke or rotate the credential;
• 2. investigate exposure;
• 3. review recent usage;
• 4. secure the affected system;
• 5. notify StampMitra where material;
• 6. implement remediation.

Developers must not bypass:

• CAPTCHA;
• OTP controls;
• authentication;
• authorization;
• API scopes;
• IP restrictions;
• rate limits;
• fraud controls;
• Production approval.

If an API feature is restricted, Developers must not obtain equivalent functionality by:

• discovering hidden endpoints;
• exploiting frontend functionality;
• accessing internal APIs;
• manipulating requests;
• using unauthorized third-party credentials.

Developers must not use credentials belonging to another person or organization without express authorization.

A Developer is responsible for ensuring it has the necessary authority to:

• submit data;
• initiate verification;
• request documents;
• initiate e-Sign;
• initiate e-Stamp workflows;
• perform other API actions.

Developers should maintain appropriate records demonstrating:

• authorization;
• consent where applicable;
• transaction history;
• user requests;
• relevant API activity.

Where an abuse investigation is reasonably required, the Developer shall cooperate with StampMitra subject to applicable law and confidentiality.

StampMitra may enforce this Policy through:

• warnings;
• requests for remediation;
• temporary throttling;
• rate-limit reduction;
• credential rotation;
• API restriction;
• Project suspension;
• Production suspension;
• account suspension;
• termination.

StampMitra may consider:

• severity;
• intent;
• impact;
• recurrence;
• affected users;
• security risk;
• legal risk;
• cooperation;
• remediation.

For lower-risk violations, StampMitra may provide an opportunity to remediate before suspension.

Examples may include:

• incorrect configuration;
• excessive but non-malicious retries;
• insecure webhook implementation;
• accidental credential exposure promptly corrected.

Serious violations may result in immediate restrictions.

Examples include:

• credential theft;
• fraud;
• unauthorized access;
• intentional security testing;
• data exfiltration;
• malware;
• deliberate rate-limit circumvention.

StampMitra may immediately suspend or terminate access where conduct presents a material:

• cybersecurity threat;
• legal risk;
• fraud risk;
• threat to other customers;
• threat to service availability;
• risk of unlawful data disclosure.

StampMitra may take immediate technical measures without prior notice where necessary to:

• stop an attack;
• prevent data loss;
• protect customers;
• prevent credential misuse;
• preserve service availability.

StampMitra may restrict only:

• an API;
• an endpoint;
• a Project;
• a credential;
• a Workspace;
• a geographic region;
• a transaction type.

A Developer may contact the designated support or legal channel to request review of an enforcement action.

The Developer should provide:

• account details;
• relevant Project;
• explanation;
• remediation steps;
• supporting information.

Reinstatement may require:

• remediation;
• credential rotation;
• security review;
• identity verification;
• updated use-case information;
• written assurances;
• additional controls.

Reinstatement is not guaranteed.

Repeated violations may result in stronger enforcement, including permanent termination.

Creating another account to circumvent a suspension or termination is prohibited.

Where conduct potentially involves unlawful activity, StampMitra may cooperate with competent authorities in accordance with applicable law.

StampMitra may preserve:

• API logs;
• authentication records;
• transaction records;
• security events;
• account information;
• communications

where reasonably necessary for investigation, security, compliance or legal proceedings.

StampMitra may restrict disclosure of investigation details where disclosure could:

• compromise security;
• interfere with an investigation;
• reveal confidential information;
• expose another customer;
• violate law.

Failure to enforce a provision immediately does not constitute a permanent waiver.

The Developer Terms of Service remain the principal contractual framework.

This AUP provides additional and more specific rules governing permitted and prohibited API usage.

The API Security Policy establishes technical and organizational security requirements.

This AUP establishes behavioral and usage restrictions.

The DPA governs applicable processing relationships concerning personal data.

This AUP governs whether and how the Developer may use the APIs.

Specific Service Terms may impose additional restrictions.

Where a Service has stricter requirements, those requirements shall apply to that Service.

Nothing in this Policy authorizes a Developer to violate:

• Indian law;
• applicable foreign law;
• regulatory requirements;
• court orders;
• contractual restrictions;
• intellectual-property rights;
• privacy rights.

The IT Act contains provisions addressing unauthorized computer activity, identity theft, personation, privacy violations, confidentiality and related cyber offences.

Developers must process personal data consistently with applicable data-protection law.

The DPDP Act establishes obligations for Data Fiduciaries, rights for Data Principals and specific provisions concerning children, processing outside India and exemptions.

Nothing in this AUP permits processing of children's personal data contrary to applicable law.

Developers must follow any additional requirements communicated for APIs that interact with government, regulated or otherwise restricted systems.

StampMitra may amend this AUP to address:

• new threats;
• regulatory requirements;
• new APIs;
• technical changes;
• abuse patterns;
• security developments.

Material changes may be communicated through the Developer Platform or other appropriate channels.

Unless otherwise required, changes shall become effective on the date specified in the updated Policy.

If any provision is invalid or unenforceable, the remaining provisions remain effective to the maximum extent permitted by law.

This Policy shall be governed by the laws of India, subject to mandatory applicable law.

For legal or policy matters:

• Legal Team
• BANI GLOBAL INDUSTRIES LLP
• LLPIN: ACI6373

Registered Office: 2-A/3, Kundan Mansion, Asaf Ali Road, Turkman Gate, Central Delhi, NCT of Delhi, India – 110002

Email: [email protected]

By accessing or using the StampMitra Developer Platform, the Developer acknowledges that:

• 1. API access is conditional upon lawful use;
• 2. technical accessibility does not create authorization;
• 3. credentials must be protected;
• 4. personal data must be processed lawfully;
• 5. API limits must be respected;
• 6. security controls must not be circumvented;
• 7. fraudulent or deceptive use is prohibited;
• 8. StampMitra may take enforcement action where required;
• 9. the Developer remains responsible for its own application and End User relationships; and
• 10. the Developer must comply with this Policy and the other applicable StampMitra policies.

• Policy: StampMitra API Acceptable Use Policy
• Document Type: Developer Platform Acceptable Use Policy
• Version: 1.0
• Status: FINAL — PUBLISHED POLICY
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026

• Legal Entity: BANI GLOBAL INDUSTRIES LLP
• LLPIN: ACI6373

Registered Office: 2-A/3, Kundan Mansion, Asaf Ali Road, Turkman Gate, Central Delhi, NCT of Delhi, India – 110002

Developer Platform: developer.stampmitra.in

Legal Contact: [email protected]

• Prepared by: Legal Team
• BANI GLOBAL INDUSTRIES LLP
• [email protected]

© 2026 BANI GLOBAL INDUSTRIES LLP. All rights reserved.