API Security Policy

1.1. This StampMitra API Security Policy (“Security Policy”) establishes the security requirements, controls, responsibilities, restrictions, safeguards, and procedures applicable to use of the StampMitra Developer Platform, APIs, Sandbox environment, Production environment, Developer Accounts, Workspaces, Projects, API credentials, webhooks, API data, integrations, and associated technical services.

1.2. The purpose of this Security Policy is to:

• (a) protect the confidentiality, integrity, and availability of StampMitra systems;
• (b) protect Developer Accounts and authentication credentials;
• (c) prevent unauthorized access and misuse;
• (d) establish minimum security requirements for Developers;
• (e) protect data transmitted through StampMitra APIs;
• (f) establish security controls for authentication and authorization;
• (g) establish procedures for security incident detection and response;
• (h) protect the StampMitra platform and its Developers from abuse;
• (i) establish requirements for secure API integration; and
• (j) support appropriate technical and organizational security practices.

2.1. This Security Policy forms part of the contractual framework governing access to and use of StampMitra Developer Services.

2.2. By creating a Developer Account, accessing the Developer Platform, generating API credentials, accessing Sandbox or Production, or making API requests, the Developer agrees to comply with this Security Policy.

2.3. This Security Policy shall be read together with:

• (a) StampMitra Developer Terms of Service;
• (b) StampMitra Developer Privacy Policy;
• (c) StampMitra Data Processing Addendum;
• (d) StampMitra API Acceptable Use Policy;
• (e) StampMitra Third-Party & Underlying Services Policy;
• (f) applicable Service Terms;
• (g) applicable Billing, Credits & Refund Policy; and
• (h) applicable API documentation.

2.4. In the event of a conflict, the contractual hierarchy specified in the Developer Terms shall apply.

3.1. StampMitra applies security principles including:

• (a) least privilege;
• (b) defense in depth;
• (c) environment isolation;
• (d) credential confidentiality;
• (e) data minimization;
• (f) secure-by-design principles;
• (g) monitoring and anomaly detection;
• (h) access control;
• (i) security incident preparedness; and
• (j) risk-based security management.

3.2. Security controls may evolve as the StampMitra platform, threat environment, technology, legal requirements, and industry practices develop.

4.1. Security is a shared responsibility between StampMitra and the Developer.

4.2. StampMitra is responsible for security controls applicable to infrastructure, systems, services, and components under StampMitra’s control.

4.3. The Developer remains responsible for securing:

• (a) Developer Accounts;
• (b) Developer personnel;
• (c) Developer applications;
• (d) Developer infrastructure;
• (e) API credentials;
• (f) databases;
• (g) frontend applications;
• (h) mobile applications;
• (i) servers;
• (j) cloud infrastructure;
• (k) webhook endpoints;
• (l) Developer-managed logs;
• (m) Developer-managed integrations; and
• (n) data submitted through the Developer’s application.

4.4. StampMitra security controls do not relieve the Developer of its own security obligations.

5.1. Developers must maintain accurate account information.

5.2. Developers must maintain access to the email address and mobile number associated with their account.

5.3. Developers must protect authentication information from unauthorized access.

5.4. Developer Accounts must not be:

• (a) sold;
• (b) rented;
• (c) transferred;
• (d) shared;
• (e) brokered;
• (f) lent;
• (g) made available to unauthorized persons; or
• (h) used to conceal the identity of unauthorized users.

5.5. Where multiple persons require access, Developers should use Workspace membership and role-based access rather than sharing credentials.

6.1. Each individual authorized to access a Developer Workspace should use their own account where individual user access is supported.

6.2. Shared credentials create additional security risks and should be avoided.

6.3. Developers are responsible for actions performed through credentials assigned to their users.

6.4. Access must be removed when an individual no longer requires access.

7.1. StampMitra may provide authentication mechanisms including:

• (a) OTP-based verification;
• (b) API keys;
• (c) scoped credentials;
• (d) OAuth or equivalent authorization mechanisms where applicable;
• (e) webhook signature verification; and
• (f) additional authentication controls introduced by StampMitra.

7.2. Developers must use the authentication mechanism specified in the applicable API documentation.

7.3. Developers must not circumvent, disable, manipulate, or bypass authentication controls.

7.4. Authentication credentials must be transmitted only through secure channels.

8.1. API keys are confidential security credentials.

8.2. Developers must protect API keys with a level of care appropriate to passwords, tokens, private keys, and other authentication secrets.

8.3. API keys must not be:

• (a) published on public repositories;
• (b) embedded in publicly accessible HTML;
• (c) embedded in browser-executed JavaScript;
• (d) embedded in mobile application binaries where extraction is reasonably possible;
• (e) included in screenshots;
• (f) posted in public forums;
• (g) posted in public support channels;
• (h) included in public documentation;
• (i) committed to source-control repositories;
• (j) disclosed to unauthorized persons; or
• (k) transmitted through insecure communication channels.

9.1. StampMitra may provide separate credentials for Sandbox and Production environments.

9.2. Test credentials may use the prefix:

sk_test_

9.3. Production credentials may use the prefix:

sk_live_

9.4. Developers must maintain strict separation between test and Production credentials.

9.5. Production credentials must not be used in environments where unauthorized users can inspect or retrieve the credential.

9.6. Production credentials must not be included in:

• (a) sample applications;
• (b) public tutorials;
• (c) test repositories;
• (d) frontend source code;
• (e) publicly distributed mobile applications; or
• (f) demonstration environments.

9.7. Developers must not attempt to convert, modify, forge, or manipulate credential prefixes to obtain unauthorized access.

10.1. API credentials should be stored using appropriate secret-management mechanisms.

10.2. Appropriate mechanisms may include:

• (a) cloud secret managers;
• (b) environment secrets;
• (c) encrypted configuration stores;
• (d) dedicated secret-management platforms; and
• (e) equivalent secure systems.

10.3. Credentials must not be unnecessarily stored in plaintext databases.

10.4. Access to credential storage must be restricted.

10.5. Developers should maintain separate credentials for separate applications, projects, or environments where reasonably appropriate.

11.1. Developers should rotate credentials periodically according to their security requirements.

11.2. Credentials must be rotated promptly where:

• (a) compromise is suspected;
• (b) a credential is accidentally exposed;
• (c) a repository containing a credential becomes publicly accessible;
• (d) an unauthorized person gains access;
• (e) an employee or contractor with access leaves;
• (f) a security incident occurs; or
• (g) StampMitra requires credential rotation.

11.3. Developers should maintain an internal emergency credential-revocation procedure.

12.1. Where a credential is suspected to be compromised, the Developer must take reasonable immediate action.

12.2. Appropriate action includes:

• (a) revoking the affected credential;
• (b) generating a replacement credential;
• (c) investigating unauthorized activity;
• (d) inspecting relevant logs;
• (e) securing affected infrastructure;
• (f) determining the source of compromise; and
• (g) notifying StampMitra where the incident may materially affect StampMitra systems or data.

12.3. StampMitra may independently revoke, rotate, suspend, or restrict compromised credentials.

13.1. Authentication establishes identity or possession of credentials.

13.2. Authorization determines what resources and actions a Developer is permitted to access.

13.3. Developers must not attempt to access resources outside their authorized permissions.

13.4. Developers must not manipulate request parameters, headers, identifiers, scopes, or endpoints to obtain unauthorized access.

14.1. StampMitra may provide API scopes or permission controls.

14.2. Developers must request only the permissions required for legitimate functionality.

14.3. Developers must not attempt to obtain broader permissions through technical manipulation.

14.4. Developers must protect scoped credentials according to their sensitivity.

15.1. Where Workspace roles are available, Developers must assign permissions according to actual responsibilities.

15.2. Administrative privileges should be limited to authorized personnel.

15.3. Read-only or restricted roles should be used where administrative access is unnecessary.

15.4. Privileged access should be reviewed periodically.

16.1. Developers should maintain appropriate Workspace separation.

16.2. Developers must not intentionally use one customer's Workspace, credentials, information, or permissions to access another customer's resources.

16.3. Cross-tenant access is prohibited unless expressly authorized.

17.1. Developers should appropriately separate:

• (a) development;
• (b) testing;
• (c) staging;
• (d) Production;
• (e) client projects; and
• (f) unrelated applications.

17.2. Production credentials must not be unnecessarily shared between unrelated applications.

17.3. Customer data should be logically segregated where multiple customers are served through the same application.

18.1. StampMitra may provide IP allowlisting for eligible Production integrations.

18.2. Developers using IP allowlisting are responsible for maintaining accurate authorized IP addresses.

18.3. Developers must update allowlists following infrastructure changes.

18.4. IP allowlisting does not replace API credential security.

19.1. Production API communications must use HTTPS.

19.2. Developers must not intentionally transmit credentials, authentication tokens, personal data, or confidential information through insecure HTTP connections.

19.3. Developers should maintain secure TLS configurations appropriate to their environment.

19.4. Certificate validation must not be disabled merely to bypass connection problems.

20.1. Developers must use valid server certificates when operating their own HTTPS endpoints.

20.2. Developers must not knowingly use invalid certificate configurations for Production security-sensitive traffic.

20.3. Developers must protect private keys associated with their certificates.

21.1. Developers should implement appropriate certificate validation and secure transport controls.

21.2. Developers must not knowingly permit unauthorized interception of API credentials or protected API data.

21.3. Debugging configurations that disable certificate verification must not be used in Production.

22.1. Developers must construct API requests according to official StampMitra documentation.

22.2. Developers must validate request parameters before submission.

22.3. Developers must not intentionally manipulate requests to bypass:

• (a) authorization;
• (b) authentication;
• (c) rate limits;
• (d) validation;
• (e) transaction controls;
• (f) usage restrictions; or
• (g) other security controls.

23.1. Developers must validate data received from their users.

23.2. Developers must not assume that user-supplied information is trustworthy.

23.3. Appropriate controls should address risks including:

• (a) injection;
• (b) cross-site scripting;
• (c) malicious uploads;
• (d) path traversal;
• (e) command injection;
• (f) malformed payloads;
• (g) oversized requests;
• (h) unexpected data types; and
• (i) unauthorized object references.

24.1. Developers must securely handle API responses.

24.2. API responses containing personal, confidential, or transactional information must not be exposed to unauthorized users.

24.3. Developers must not unnecessarily copy sensitive API responses into:

• (a) public logs;
• (b) public analytics systems;
• (c) public repositories;
• (d) publicly accessible storage; or
• (e) unsecured third-party services.

25.1. Developers receiving StampMitra webhooks are responsible for securing their webhook endpoints.

25.2. Where StampMitra provides webhook signing, Developers must verify the applicable signature before treating an event as authentic.

25.3. Developers should validate:

• (a) signature;
• (b) timestamp;
• (c) event identifier;
• (d) request integrity; and
• (e) replay conditions where applicable.

25.4. An unverified webhook must not be treated as a trusted transaction.

26.1. Developers should implement appropriate replay protection.

26.2. Previously processed events should not be processed repeatedly where duplicate processing could result in:

• (a) duplicate transactions;
• (b) duplicate documents;
• (c) financial loss;
• (d) incorrect customer status;
• (e) unauthorized actions; or
• (f) other material consequences.

27.1. Webhook endpoints should use HTTPS.

27.2. Developers should restrict access to webhook endpoints where technically appropriate.

27.3. Developers must prevent unauthorized persons from triggering business-critical webhook actions.

27.4. Developers should maintain appropriate authentication, signature verification, validation, and authorization controls.

28.1. Developers should use idempotency mechanisms where supported.

28.2. Developers must not assume that a timeout means a transaction was never received.

28.3. Developers should safely handle:

• (a) retries;
• (b) duplicate requests;
• (c) timeout responses;
• (d) delayed responses;
• (e) webhook retries; and
• (f) uncertain transaction states.

29.1. Developers must comply with applicable API rate limits.

29.2. Rate limits are operational and security controls.

29.3. Developers must not bypass rate limits through:

• (a) multiple accounts;
• (b) multiple API keys;
• (c) multiple IP addresses;
• (d) distributed infrastructure;
• (e) artificial concurrency; or
• (f) other circumvention mechanisms.

30.1. Developers operating high-volume integrations should implement:

• (a) queueing;
• (b) controlled concurrency;
• (c) backoff;
• (d) retry limits; and
• (e) traffic management.

30.2. Developers must not generate uncontrolled request bursts that materially affect service availability.

31.1. Developers should implement bounded retry mechanisms.

31.2. Excessive retries may be treated as resource abuse.

31.3. Recommended practices may include:

• (a) exponential backoff;
• (b) bounded retries;
• (c) idempotency;
• (d) appropriate timeouts; and
• (e) circuit-breaker mechanisms.

32.1. Developers must securely handle API errors.

32.2. Internal technical information contained in errors must not be unnecessarily exposed to end users.

32.3. Developers must not use errors as a method of discovering confidential infrastructure information.

32.4. Error responses must not be interpreted as authorization to retry indefinitely.

33.1. Developers must not attempt to obtain confidential StampMitra infrastructure information through:

• (a) API errors;
• (b) headers;
• (c) undocumented endpoints;
• (d) debugging interfaces;
• (e) response timing;
• (f) endpoint enumeration; or
• (g) other technical means.

33.2. Security testing intended to discover confidential architecture or provider information requires appropriate authorization.

34.1. Developers should maintain sufficient logs to investigate:

• (a) authentication events;
• (b) API requests;
• (c) API errors;
• (d) administrative actions;
• (e) credential changes;
• (f) webhook events;
• (g) security incidents; and
• (h) material application failures.

34.2. Logs must be protected against unauthorized access and unauthorized alteration.

35.1. Developers must avoid unnecessary logging of personal data.

35.2. Developers must not log:

• (a) API secret keys;
• (b) OTPs;
• (c) authentication tokens;
• (d) private keys;
• (e) payment authentication credentials; or
• (f) other sensitive authentication information.

35.3. Where reasonably practical, personal identifiers should be masked, truncated, hashed, or otherwise protected.

36.1. StampMitra may maintain audit records relating to:

• (a) account activity;
• (b) credential creation;
• (c) credential revocation;
• (d) API usage;
• (e) administrative actions;
• (f) Production access;
• (g) security events;
• (h) policy violations; and
• (i) platform operations.

36.2. Audit records may be retained for security, compliance, fraud prevention, dispute resolution, and operational purposes.

37.1. StampMitra may monitor activity to identify:

• (a) unusual authentication patterns;
• (b) credential abuse;
• (c) abnormal API traffic;
• (d) excessive request rates;
• (e) suspicious network activity;
• (f) account takeover indicators;
• (g) fraudulent activity;
• (h) unauthorized access attempts; and
• (i) other security anomalies.

37.2. Monitoring may result in automated or manual security action.

38.1. StampMitra may employ fraud-detection and risk-management controls.

38.2. Such controls may consider technical, transactional, behavioral, account, or other appropriate indicators.

38.3. Developers must not attempt to circumvent fraud controls.

39.1. Developers are responsible for securing applications that connect to StampMitra.

39.2. Applications should implement appropriate protection against:

• (a) account takeover;
• (b) credential theft;
• (c) SQL injection;
• (d) XSS;
• (e) CSRF;
• (f) SSRF;
• (g) command injection;
• (h) insecure direct object references;
• (i) broken access control;
• (j) insecure file handling;
• (k) malicious uploads;
• (l) session hijacking; and
• (m) other reasonably foreseeable application vulnerabilities.

40.1. Production secret API credentials must not be embedded in browser-executed frontend code unless StampMitra expressly documents a public-client authentication mechanism for the applicable service.

40.2. Developers should generally route privileged API operations through a secure backend.

40.3. Developers must distinguish between publicly usable identifiers and confidential API credentials.

41.1. Developers must recognize that secrets embedded in mobile application binaries may potentially be extracted.

41.2. Production secret API credentials should not be hardcoded into mobile applications.

41.3. Privileged operations should generally be performed through an appropriately secured backend.

42.1. Developers must maintain appropriate security controls over source code.

42.2. API credentials must not be committed to public or private source-control repositories where avoidable.

42.3. If a secret is accidentally committed, the Developer must treat it as compromised.

42.4. Removing a credential from the latest commit alone does not necessarily eliminate historical exposure.

42.5. Exposed credentials must be revoked or rotated.

43.1. Developers using CI/CD systems must protect:

• (a) API credentials;
• (b) deployment credentials;
• (c) cloud credentials;
• (d) signing keys;
• (e) environment variables; and
• (f) other secrets.

43.2. CI/CD secrets should be stored using the platform's secure secret-management mechanisms.

43.3. Production secrets must not be printed into build logs.

44.1. Developers should maintain supported versions of security-sensitive software dependencies.

44.2. Known material vulnerabilities should be assessed and remediated within a reasonable period appropriate to their severity.

44.3. Dependencies should be obtained from trusted sources.

45.1. Developers should maintain an appropriate vulnerability-management process.

45.2. Critical vulnerabilities affecting systems connected to Production APIs should receive priority remediation.

45.3. Developers must not knowingly operate materially compromised infrastructure against StampMitra Production APIs.

46.1. Developers should apply appropriate security updates.

46.2. Internet-facing systems should receive particular security attention.

46.3. Unsupported software should not be operated where it creates a material and reasonably avoidable security risk.

47.1. Developers may conduct security testing of systems they own or are authorized to test.

47.2. Testing involving StampMitra infrastructure must comply with the StampMitra API Acceptable Use Policy and any applicable authorization requirements.

47.3. Testing must not materially affect service availability or other Developers.

Without express authorization, Developers must not conduct:

• (a) denial-of-service testing;
• (b) distributed load testing;
• (c) destructive testing;
• (d) credential stuffing;
• (e) brute-force testing;
• (f) abusive vulnerability scanning;
• (g) exploit development against Production;
• (h) unauthorized penetration testing;
• (i) provider-discovery attacks;
• (j) endpoint enumeration intended to bypass controls;
• (k) attacks against third-party systems;
• (l) attempts to access another Developer's resources; or
• (m) testing likely to affect service availability.

49.1. Developers identifying a potential StampMitra security vulnerability should report it responsibly through the security or legal contact channel made available by StampMitra.

49.2. Reports should include sufficient technical information to permit investigation.

49.3. Developers should avoid public disclosure before StampMitra has had a reasonable opportunity to investigate and remediate the issue.

49.4. Security reports must not contain unnecessary personal data or unrelated confidential information.

50.1. Good-faith security research may be permitted where expressly authorized.

50.2. Authorization may define:

• (a) scope;
• (b) systems;
• (c) permitted techniques;
• (d) testing windows;
• (e) traffic limits;
• (f) reporting procedures; and
• (g) prohibited activities.

50.3. Absence of an explicit authorization must not be interpreted as permission to conduct intrusive testing.

51.1. A “Security Incident” includes an actual or reasonably suspected event involving:

• (a) unauthorized access;
• (b) unauthorized disclosure;
• (c) credential compromise;
• (d) malware;
• (e) account takeover;
• (f) unauthorized API use;
• (g) material data exposure;
• (h) compromise of systems connected to StampMitra;
• (i) material integrity compromise; or
• (j) material availability attacks.

52.1. Developers must take reasonable steps to contain and remediate security incidents affecting their integration.

52.2. Developers should:

• (a) isolate affected systems;
• (b) revoke compromised credentials;
• (c) preserve relevant evidence;
• (d) investigate unauthorized activity;
• (e) remediate vulnerabilities;
• (f) restore secure operation; and
• (g) cooperate with StampMitra where StampMitra systems or data may be affected.

53.1. Where a Developer reasonably believes that a security incident has affected StampMitra systems, StampMitra credentials, or StampMitra-provided data, the Developer should notify StampMitra without unreasonable delay.

53.2. Notification should contain available information concerning:

• (a) nature of the incident;
• (b) affected systems;
• (c) affected credentials;
• (d) relevant time period;
• (e) known or suspected impact;
• (f) containment measures; and
• (g) contact information for the responsible security representative.

54.1. Developers must reasonably cooperate with StampMitra during investigation of incidents that may affect StampMitra systems or other Developers.

54.2. Cooperation may include:

• (a) credential identification;
• (b) relevant logs;
• (c) technical indicators;
• (d) affected IP information;
• (e) timeline information; and
• (f) remediation status.

55.1. Developers should implement appropriate account takeover protections in applications integrating with StampMitra.

55.2. Such controls may include:

• (a) strong authentication;
• (b) session management;
• (c) login anomaly detection;
• (d) credential protection;
• (e) access reviews;
• (f) account recovery controls; and
• (g) suspicious activity detection.

56.1. Developers must not use social engineering to obtain:

• (a) API credentials;
• (b) OTPs;
• (c) access tokens;
• (d) administrative access;
• (e) confidential platform information; or
• (f) another person's account access.

56.2. StampMitra personnel will not require Developers to disclose confidential API secrets or OTPs through ordinary support processes.

57.1. Developers must not create phishing pages, messages, applications, or websites impersonating StampMitra.

57.2. Developers must not use StampMitra branding to falsely represent an official StampMitra service.

57.3. Suspected phishing involving StampMitra may be reported to [email protected].

58.1. Developers should not provide API secret keys, OTPs, private keys, passwords, or authentication tokens to support personnel.

58.2. Where troubleshooting requires technical information, Developers should provide sanitized logs, request identifiers, timestamps, error messages, and other non-secret information where possible.

59.1. Developers must submit only information reasonably necessary for the requested service.

59.2. Developers should avoid sending unnecessary personal, financial, identity, authentication, or confidential information.

59.3. Data minimization requirements may be especially important for verification, e-Stamp, e-Sign, identity, and legal-document services.

60.1. Developers are responsible for implementing appropriate security controls for personal data submitted through their applications.

60.2. Developers must comply with applicable data-protection obligations.

60.3. Where applicable, Developers must provide appropriate notices and obtain required permissions, consents, or other lawful authorization before submitting personal data.

61.1. Developers must not submit children's personal data unless legally permitted and necessary for the specific service.

61.2. Where applicable, Developers must implement legally required safeguards for children's data.

61.3. Developers must not use StampMitra APIs to facilitate unlawful collection, profiling, tracking, or exploitation of children's data.

62.1. Developers must not submit sensitive personal information unless the relevant StampMitra service expressly requires it and the Developer is legally authorized to provide it.

62.2. Developers must apply appropriate safeguards to sensitive information.

62.3. Sensitive information must not be unnecessarily copied into logs, analytics systems, or debugging environments.

63.1. Where identity documents are required for a permitted service, Developers must:

• (a) collect them lawfully;
• (b) transmit them through secure channels;
• (c) restrict access;
• (d) prevent unauthorized disclosure;
• (e) avoid unnecessary duplication; and
• (f) comply with applicable retention requirements.

64.1. Developers integrating e-Stamp-related services must protect transaction information, applicant information, documents, identifiers, and related data.

64.2. Developers must not manipulate or falsify information submitted for e-Stamp processing.

64.3. Developers must implement appropriate access restrictions around e-Stamp transaction information.

65.1. Developers integrating e-Sign-related services must comply with applicable security and legal requirements.

65.2. Developers must not misuse signing credentials, identity information, consent records, authentication information, or signing-related data.

65.3. Developers must not represent an unauthorized signature or authentication event as valid.

66.1. Developers should use appropriate encryption safeguards for protected data.

66.2. Data requiring confidentiality should be encrypted during transmission.

66.3. Sensitive data should be protected at rest where reasonably appropriate.

66.4. Encryption keys must themselves be securely managed.

67.1. Cryptographic keys must be protected against unauthorized access.

67.2. Developers should restrict key-management privileges.

67.3. Keys should be rotated or replaced when compromise is suspected.

67.4. Cryptographic keys must not be publicly disclosed.

68.1. Developer databases containing StampMitra-related information should implement:

• (a) access controls;
• (b) authentication;
• (c) least privilege;
• (d) appropriate backups;
• (e) monitoring;
• (f) secure network configuration; and
• (g) reasonable protection against unauthorized extraction.

69.1. Developers should maintain appropriate backups of critical integration data where necessary.

69.2. Backups containing protected information must be secured.

69.3. Backup access should be restricted.

69.4. Developers should periodically assess whether backup restoration procedures operate effectively.

70.1. Developers operating business-critical StampMitra integrations should maintain appropriate disaster-recovery procedures.

70.2. Disaster-recovery planning should address:

• (a) infrastructure failure;
• (b) credential compromise;
• (c) data corruption;
• (d) application failure;
• (e) cloud service disruption;
• (f) network failure; and
• (g) other reasonably foreseeable incidents.

71.1. Developers using StampMitra for critical business processes should maintain appropriate continuity procedures.

71.2. Such procedures may include:

• (a) fallback processing;
• (b) controlled retries;
• (c) incident escalation;
• (d) alternate infrastructure;
• (e) manual exception handling; and
• (f) customer communication procedures.

72.1. Developers should incorporate security throughout the software development lifecycle.

72.2. Appropriate practices may include:

• (a) threat modelling;
• (b) secure coding;
• (c) code review;
• (d) dependency review;
• (e) automated security testing;
• (f) vulnerability scanning;
• (g) secrets scanning;
• (h) pre-production testing; and
• (i) controlled deployment.

73.1. Material changes to Production integrations should be tested before deployment.

73.2. Developers should maintain appropriate rollback mechanisms.

73.3. Security-sensitive configuration changes should be subject to appropriate authorization.

74.1. Developers should deploy Production integrations only after appropriate testing.

74.2. Production credentials must not be used for development experimentation.

74.3. Production access should be restricted to authorized personnel.

75.1. Sandbox is intended for development and testing.

75.2. Developers must not intentionally place unnecessary real personal data, confidential customer information, or Production credentials into Sandbox.

75.3. Developers should use test or synthetic information whenever possible.

75.4. Sandbox must not be used to circumvent Production controls.

76.1. Developers must not copy Production data into Sandbox where unnecessary.

76.2. Where testing genuinely requires representative data, Developers should use appropriately anonymized, masked, synthetic, or otherwise legally permitted data.

77.1. Production access may require additional verification or security controls.

77.2. StampMitra may require:

• (a) identity verification;
• (b) business information;
• (c) use-case information;
• (d) technical information;
• (e) security information;
• (f) expected traffic information; or
• (g) additional verification appropriate to the requested API.

78.1. Production credentials may be subject to additional controls.

78.2. StampMitra may:

• (a) restrict issuance;
• (b) limit permissions;
• (c) require IP allowlisting;
• (d) require additional verification;
• (e) impose rate limits;
• (f) require credential rotation; or
• (g) temporarily restrict credentials where security risk exists.

79.1. StampMitra may apply enhanced security requirements to integrations presenting elevated risk.

79.2. Elevated risk may arise from:

• (a) high transaction volume;
• (b) identity verification;
• (c) legal-document processing;
• (d) financial transactions;
• (e) sensitive personal information;
• (f) automated decision processes;
• (g) government-related services; or
• (h) other materially sensitive use cases.

80.1. Developers remain responsible for security risks introduced by third-party software used within their integration.

80.2. Developers should conduct reasonable due diligence before providing API credentials to third-party systems.

80.3. Developers must not disclose StampMitra credentials to unrelated third parties unless expressly authorized and technically appropriate.

81.1. StampMitra may route API requests through authorized underlying service providers or external systems.

81.2. Developers must not attempt to bypass StampMitra security controls to directly access such systems.

81.3. Information concerning underlying providers may be confidential.

81.4. Security requirements relating to such providers may be addressed under the StampMitra Third-Party & Underlying Services Policy.

82.1. Developers must not request, obtain, use, or attempt to discover credentials belonging to StampMitra's underlying service providers.

82.2. Developers must not attempt to access upstream systems using StampMitra-issued information for an unauthorized purpose.

83.1. Developers must use current official StampMitra documentation.

83.2. Developers must not rely upon undocumented endpoints for Production use.

83.3. Undocumented endpoints may change or be removed without notice.

83.4. Attempting to reverse engineer undocumented security mechanisms is prohibited.

84.1. Developers must not reverse engineer, decompile, disassemble, probe, or otherwise attempt to discover confidential security mechanisms except where expressly permitted by applicable law or authorized by StampMitra.

84.2. This restriction includes attempts to discover confidential provider relationships or internal routing mechanisms.

85.1. Developers operating web applications should implement appropriate security headers and browser security controls.

85.2. Depending upon application architecture, controls may include:

• (a) Content Security Policy;
• (b) secure cookies;
• (c) HttpOnly cookies;
• (d) SameSite controls;
• (e) frame protections;
• (f) referrer controls; and
• (g) appropriate CORS configuration.

86.1. Developers must configure CORS policies according to actual application requirements.

86.2. Developers should not use unrestricted cross-origin access where sensitive authenticated operations are involved.

86.3. Credentials should not be exposed through unnecessarily broad cross-origin policies.

87.1. Developer applications should implement secure session management.

87.2. Sessions should:

• (a) expire appropriately;
• (b) be invalidated after logout;
• (c) be protected against fixation;
• (d) use secure transport; and
• (e) prevent unauthorized reuse.

88.1. Where Developers maintain passwords for their own applications, passwords must be securely stored.

88.2. Passwords must not be stored in plaintext.

88.3. Developers should use appropriate password hashing mechanisms and authentication controls.

89.1. Account recovery processes must provide security controls appropriate to the sensitivity of the account.

89.2. Developers must not attempt to bypass StampMitra account-recovery controls.

89.3. Recovery credentials or OTPs must not be disclosed to unauthorized persons.

90.1. OTPs are confidential authentication credentials.

90.2. Developers and their users must not disclose OTPs to unauthorized persons.

90.3. Developers must not attempt to intercept, manipulate, replay, or bypass OTP authentication.

90.4. OTPs must not be stored unnecessarily.

91.1. Developers must apply reasonable physical security to infrastructure under their control.

91.2. Devices used to administer Production systems should be protected against unauthorized access.

91.3. Lost or stolen devices with privileged access must be treated as a potential security incident.

92.1. Devices used for privileged administration should have appropriate:

• (a) authentication;
• (b) operating-system security;
• (c) malware protection;
• (d) software updates;
• (e) screen locking; and
• (f) access controls.

93.1. Developers must ensure that employees and contractors with API access are appropriately authorized.

93.2. Access must be revoked when no longer required.

93.3. Privileged credentials must not remain active after personnel separation where access is no longer authorized.

94.1. Developers should provide reasonable security awareness to personnel who handle:

• (a) API credentials;
• (b) personal data;
• (c) customer information;
• (d) Production systems; or
• (e) security-sensitive integrations.

95.1. StampMitra may require additional security information from enterprise or high-risk Developers.

95.2. Requests may address:

• (a) architecture;
• (b) authentication;
• (c) access controls;
• (d) data security;
• (e) incident response;
• (f) business continuity; or
• (g) compliance controls.

96.1. Where contractually applicable, StampMitra may conduct or request reasonable security assessments.

96.2. Security assessments shall be proportionate to the relevant risk and contractual relationship.

96.3. Developers must not misrepresent their security controls.

97.1. Enterprise integrations may be subject to additional contractual security requirements.

97.2. Such requirements may include:

• (a) IP restrictions;
• (b) additional authentication;
• (c) enhanced logging;
• (d) access reviews;
• (e) security documentation;
• (f) incident procedures; and
• (g) other mutually agreed controls.

98.1. A Developer must not assume that an unavailable security feature constitutes permission to bypass security requirements.

98.2. Where a Developer requires an exception for a legitimate technical reason, the Developer should seek written authorization from StampMitra.

98.3. Any security exception may be:

• (a) time-limited;
• (b) scope-limited;
• (c) conditional; or
• (d) revoked based upon changing security risk.

99.1. StampMitra may respond to security incidents using measures appropriate to the circumstances.

99.2. Measures may include:

• (a) credential revocation;
• (b) API key rotation;
• (c) account restriction;
• (d) rate reduction;
• (e) IP blocking;
• (f) API suspension;
• (g) Workspace restriction;
• (h) investigation;
• (i) data-protection measures; and
• (j) cooperation with competent authorities where legally required.

100.1. Where StampMitra reasonably determines that immediate action is necessary to protect systems, users, data, or third parties, StampMitra may take emergency security measures without prior notice where reasonably necessary.

100.2. Emergency measures may include temporary suspension or restriction of API access.

101.1. Security enforcement may be limited to:

• (a) a particular API;
• (b) a particular credential;
• (c) a particular IP address;
• (d) a particular Workspace;
• (e) a particular Project;
• (f) a particular user; or
• (g) a particular transaction type.

101.2. Partial restriction may be used where it is reasonably sufficient to address the identified risk.

102.1. StampMitra may suspend access where reasonably necessary to address:

• (a) suspected credential compromise;
• (b) unauthorized access;
• (c) fraud;
• (d) malicious traffic;
• (e) material security vulnerability;
• (f) abuse;
• (g) data exposure;
• (h) serious policy violations; or
• (i) threats to platform integrity.

103.1. StampMitra may revoke credentials where necessary for security.

103.2. Revocation may occur following:

• (a) suspected compromise;
• (b) prolonged inactivity where applicable;
• (c) unauthorized use;
• (d) security policy violation;
• (e) account termination;
• (f) Production access withdrawal; or
• (g) other material security concerns.

104.1. Developers should use official StampMitra support channels for security-related issues.

104.2. Developers should avoid sending secrets through ordinary support communications.

104.3. Developers should provide request IDs, timestamps, sanitized logs, and relevant technical information wherever possible.

105.1. Developers must not impersonate StampMitra personnel.

105.2. Developers must not attempt to persuade personnel to:

• (a) disclose credentials;
• (b) bypass verification;
• (c) disable security controls;
• (d) disclose confidential provider information;
• (e) provide unauthorized access; or
• (f) alter security records.

106.1. API credentials must not be shared with unauthorized persons.

106.2. If a business relationship requires delegated access, the Developer should use authorized Workspace, team, project, or integration mechanisms where available.

106.3. Credential sharing may result in security restrictions.

107.1. Public exposure of a Production credential constitutes a material security risk.

107.2. Developers must immediately revoke exposed credentials.

107.3. Developers should investigate the period during which the credential was exposed.

108.1. Freelancers, consultants, agencies, and Developers operating client projects remain responsible for protecting API credentials and client data.

108.2. Client credentials must not be mixed with unrelated client environments.

108.3. A Developer must ensure that it has appropriate authorization before integrating StampMitra on behalf of a client.

109.1. Developers operating SaaS or multi-tenant applications must implement logical tenant isolation.

109.2. One customer must not be able to access another customer's:

• (a) API data;
• (b) documents;
• (c) credentials;
• (d) transaction records;
• (e) identity information; or
• (f) configuration.

110.1. Developers must implement authorization controls appropriate to their own customer-facing applications.

110.2. Possession of a StampMitra transaction identifier must not automatically be treated as sufficient authorization to access protected information.

111.1. Developers must carefully assess whether API responses may be cached.

111.2. Responses containing personal, confidential, transactional, or security-sensitive information must not be placed into publicly accessible caches.

111.3. Cached information must be subject to appropriate access controls and retention requirements.

112.1. Developers should retain API data only for as long as reasonably necessary for the applicable purpose or legal requirement.

112.2. Unnecessary copies of personal or confidential information should be deleted securely.

112.3. Backup copies should be managed according to applicable retention and deletion practices.

113.1. Developers should securely delete information that is no longer required.

113.2. Secure deletion should consider:

• (a) primary databases;
• (b) file storage;
• (c) logs;
• (d) caches;
• (e) backups; and
• (f) replicated environments.

114.1. Exports containing StampMitra-related information must be protected.

114.2. Developers must not place sensitive exports into publicly accessible storage.

114.3. Export access should be limited to authorized personnel.

115.1. Developers using cloud infrastructure are responsible for appropriately configuring their cloud environments.

115.2. Developers should secure:

• (a) IAM permissions;
• (b) storage buckets;
• (c) databases;
• (d) network rules;
• (e) secrets;
• (f) compute resources;
• (g) logs; and
• (h) administrative accounts.

116.1. Cloud storage containing StampMitra-related information must not be publicly accessible unless the information is specifically intended to be public.

116.2. Access permissions should follow least privilege.

116.3. Developers should regularly review public-access configurations.

117.1. Where applications accept documents or files, Developers should implement appropriate controls including:

• (a) file-type validation;
• (b) size limits;
• (c) malware scanning where appropriate;
• (d) access control;
• (e) secure storage;
• (f) filename sanitization; and
• (g) controlled download mechanisms.

118.1. Documents submitted through StampMitra integrations may contain confidential or personal information.

118.2. Developers must restrict document access to authorized persons.

118.3. Documents must not be exposed through predictable public URLs without appropriate authorization.

119.1. Developers should not expose sensitive internal identifiers unnecessarily.

119.2. Transaction IDs, application IDs, customer IDs, and similar identifiers must not be treated as authorization credentials unless expressly designed for that purpose.

120.1. Access tokens, authorization tokens, refresh tokens, and similar credentials must be treated as confidential.

120.2. Tokens must not be included in public URLs where secure alternatives exist.

120.3. Tokens should be stored securely and revoked when no longer necessary.

121.1. Webhook signing secrets must be protected as confidential credentials.

121.2. Webhook secrets must not be committed to source-control repositories.

121.3. Compromised webhook secrets should be rotated promptly.

122.1. Developers must handle payment-related information according to applicable legal, contractual, and security requirements.

122.2. Developers must not store authentication information unnecessarily.

122.3. Developers must not represent themselves as StampMitra's payment processor or financial institution unless expressly authorized.

123.1. Developers must securely reconcile transaction status.

123.2. A client-side indication of success must not automatically be treated as final transaction confirmation where server-side confirmation is required.

123.3. Developers should use authoritative API responses or webhooks for transaction reconciliation where applicable.

124.1. Developers must implement reasonable controls to prevent duplicate transactions.

124.2. Duplicate requests resulting from retries, network failures, or user actions must be handled safely.

125.1. Developers sending customer notifications based upon StampMitra API responses must ensure that confidential information is not unnecessarily disclosed.

125.2. Notification content should be limited to information reasonably necessary for the customer.

126.1. Developers must protect support systems containing API-related information.

126.2. Customer support personnel should receive only the information necessary to resolve an issue.

126.3. Sensitive credentials must not be exposed through support tickets.

127.1. Developers should assess third-party services that receive StampMitra-related information.

127.2. Developers must not disclose StampMitra API credentials to third parties unless authorized.

127.3. Third-party tools must be configured to prevent unauthorized access.

128.1. Developers must carefully assess personal and confidential information sent to analytics systems.

128.2. API secrets and authentication tokens must never be sent to analytics systems.

128.3. Sensitive customer information should be minimized or masked where analytics is genuinely necessary.

129.1. Error-monitoring systems must be configured to avoid unnecessary capture of:

• (a) API secrets;
• (b) OTPs;
• (c) authentication tokens;
• (d) personal information; and
• (e) confidential documents.

129.2. Developers should apply appropriate data scrubbing.

130.1. Development environments should not contain unnecessary Production credentials.

130.2. Developers should use synthetic or sanitized data.

130.3. Access to development systems must be restricted appropriately.

131.1. Test data should be synthetic wherever possible.

131.2. Real customer information should not be used merely for convenience.

131.3. If real information is legitimately required, appropriate safeguards must be implemented.

132.1. Demonstrations, tutorials, screenshots, videos, and presentations must not reveal:

• (a) API secrets;
• (b) OTPs;
• (c) private keys;
• (d) personal information;
• (e) customer information; or
• (f) confidential platform information.

133.1. Developers must not publish confidential API credentials in documentation.

133.2. Documentation examples should use test credentials or placeholders.

133.3. Developers must not publish confidential StampMitra infrastructure information without authorization.

134.1. Developers may publish open-source integrations provided that they do not disclose confidential information or credentials.

134.2. Production credentials must never be included in open-source code.

134.3. Example configurations must use placeholders or test credentials.

135.1. Automated systems accessing StampMitra APIs must comply with authentication, rate, authorization, and security controls.

135.2. Automated agents must not be configured to bypass security restrictions.

135.3. Developers remain responsible for actions performed by automated systems using their credentials.

136.1. Developers integrating StampMitra APIs into AI systems, agents, assistants, or automated decision systems must protect API credentials and customer data.

136.2. Developers must prevent unauthorized prompt or instruction content from causing disclosure of:

• (a) API secrets;
• (b) customer information;
• (c) system credentials;
• (d) confidential documents; or
• (e) protected API responses.

136.3. Developers should implement appropriate authorization boundaries for AI agents with API access.

137.1. AI-enabled applications must not expose confidential credentials through prompts, model context, logs, traces, debugging systems, or generated responses.

137.2. Developers must apply appropriate controls against prompt injection where an AI system can invoke StampMitra APIs.

137.3. API authorization must not rely solely upon natural-language instructions.

138.1. AI agents or automated systems must use restricted credentials appropriate to their authorized functionality.

138.2. Developers should avoid granting broad Production permissions to autonomous systems where narrower permissions are sufficient.

138.3. High-impact operations should include appropriate confirmation, authorization, or transaction controls.

139.1. Internal dashboards, administrative tools, support systems, and integration consoles connected to StampMitra must be appropriately secured.

139.2. Administrative tools must not be publicly exposed without appropriate authentication and access control.

140.1. Administrative actions should be attributable to authorized users.

140.2. Material administrative actions may be logged for security and audit purposes.

140.3. Developers must not attempt to disguise unauthorized administrative actions.

141.1. StampMitra may use automated security systems to identify potentially malicious behavior.

141.2. Automated controls may temporarily restrict activity pending investigation.

141.3. Security decisions may consider multiple signals and may not be based upon a single technical indicator.

142.1. A legitimate Developer may occasionally trigger automated security controls.

142.2. Developers may contact StampMitra support or the applicable security/legal channel for review.

142.3. Developers must provide sufficient information to assist with legitimate security review.

143.1. StampMitra may periodically review Developer security posture where appropriate to the Developer's access level, use case, traffic volume, or risk profile.

143.2. Security review does not constitute a certification or guarantee of the Developer's security.

144.1. Developers must comply with applicable laws and regulations relevant to their use of StampMitra APIs.

144.2. Depending upon the activity and jurisdiction, relevant legal requirements may include applicable provisions of:

• (a) the Information Technology Act, 2000;
• (b) applicable rules and regulations made under information technology legislation;
• (c) the Digital Personal Data Protection Act, 2023, to the extent applicable and in force;
• (d) applicable rules made under the Digital Personal Data Protection Act;
• (e) applicable contractual obligations; and
• (f) other applicable Indian or foreign laws.

144.3. References to legislation are subject to amendments, replacements, notifications, commencement provisions, and applicable governmental directions.

145.1. Security obligations under this Policy operate together with applicable privacy and data-protection obligations.

145.2. The allocation of Data Fiduciary, Data Processor, controller, processor, or equivalent roles depends upon the relevant processing activity and applicable law.

145.3. This Security Policy does not independently determine the legal role of either party for every processing activity.

146.1. StampMitra may disclose information where required or permitted by applicable law.

146.2. Developers must not interfere with lawful investigations.

146.3. Developers must not use StampMitra APIs to facilitate unlawful access to government systems or records.

147.1. Developers using APIs relating to government, regulatory, identity, registration, verification, documentation, or similar services must apply heightened care.

147.2. Developers must not attempt to bypass governmental authentication, verification, authorization, or technical safeguards.

148.1. Developers must ensure that information submitted for legal-document services is accurate and lawfully obtained.

148.2. Developers must not manipulate documents or information to obtain an unlawful benefit.

148.3. Security controls must be implemented to prevent unauthorized alteration or substitution of documents.

149.1. Developers must use verification services only for legitimate and authorized purposes.

149.2. Developers must not:

• (a) perform unauthorized searches;
• (b) harvest verification data;
• (c) build unauthorized databases;
• (d) repeatedly query individuals without legitimate purpose; or
• (e) circumvent access controls.

150.1. Where StampMitra retrieves or processes information from authorized external systems or data sources, Developers must not attempt to circumvent StampMitra's authorized access model.

150.2. Developers must not use StampMitra APIs to perform unauthorized bulk extraction of external information.

151.1. StampMitra may dynamically route requests through authorized service providers or systems.

151.2. Developers must not attempt to manipulate routing decisions for the purpose of obtaining unauthorized access, lower controls, confidential information, or prohibited services.

152.1. Technical and commercial information relating to underlying service providers may constitute confidential information.

152.2. Developers must not attempt to identify, map, probe, or circumvent confidential provider relationships through technical means.

153.1. Developers must protect confidential pricing, transaction, contractual, technical, and commercial information obtained through StampMitra.

153.2. Confidential information must not be disclosed to unauthorized third parties.

154.1. Developers must distribute credentials only through secure channels.

154.2. Credentials must not be distributed through:

• (a) public email threads;
• (b) public messaging groups;
• (c) source repositories;
• (d) public documents;
• (e) screenshots; or
• (f) unsecured file-sharing systems.

155.1. Developers should use appropriate security controls for email accounts associated with Developer Accounts.

155.2. Access to account recovery email addresses should be protected.

155.3. Developers should implement strong authentication for privileged email accounts where available.

156.1. Developers operating API integration domains should maintain appropriate domain and DNS security.

156.2. Domain credentials must be protected.

156.3. Unauthorized DNS changes affecting API or webhook infrastructure should be treated as potential security incidents.

157.1. TLS certificates and private keys must be protected.

157.2. Developers should monitor certificate validity and expiration.

157.3. Compromised private keys must be replaced promptly.

158.1. Developers should apply appropriate network security controls.

158.2. Such controls may include:

• (a) firewalls;
• (b) network segmentation;
• (c) restricted administrative ports;
• (d) intrusion detection;
• (e) secure VPN access where appropriate; and
• (f) access-control rules.

159.1. Administrative interfaces should not be unnecessarily exposed to the public internet.

159.2. Where remote administration is required, Developers should use appropriate authentication and network restrictions.

160.1. Cloud identity and access management should follow least privilege.

160.2. Root or equivalent administrative credentials should be strongly protected.

160.3. Access should be reviewed periodically.

161.1. Service accounts must be limited to required permissions.

161.2. Service-account credentials must be protected.

161.3. Unused service accounts and credentials should be disabled or removed.

162.1. Environment variables containing secrets must be protected.

162.2. Developers must ensure that environment configuration is not accidentally exposed through:

• (a) logs;
• (b) error pages;
• (c) debugging endpoints;
• (d) client-side bundles;
• (e) repositories; or
• (f) support screenshots.

163.1. Debug mode should not be enabled in Production where it may disclose confidential information.

163.2. Stack traces, environment variables, credentials, internal paths, and infrastructure details must not be publicly exposed.

164.1. Development tools with access to Production systems must be appropriately secured.

164.2. Developers should restrict access to source code, deployment systems, cloud consoles, databases, and secret stores.

165.1. Third-party testing or monitoring services must not receive API credentials unless necessary and authorized.

165.2. Developers should minimize sensitive data supplied to testing services.

166.1. Monitoring, tracing, logging, and observability platforms must be configured to prevent unnecessary collection of secrets and personal data.

166.2. Access to observability systems should be restricted.

167.1. Incident evidence should be preserved where necessary for investigation.

167.2. Evidence containing personal or confidential information must itself be protected.

167.3. Developers should avoid altering relevant logs or records during investigation except as necessary to contain the incident.

168.1. Developers should conduct reasonable forensic investigation following material security incidents.

168.2. Investigation may include:

• (a) credential analysis;
• (b) authentication logs;
• (c) network logs;
• (d) application logs;
• (e) source-code review;
• (f) access review; and
• (g) timeline reconstruction.

169.1. Following an incident, Developers should identify and address the underlying cause.

169.2. Remediation may include:

• (a) credential rotation;
• (b) patching;
• (c) access revocation;
• (d) configuration changes;
• (e) application updates;
• (f) network restrictions; and
• (g) enhanced monitoring.

170.1. Developers should conduct a post-incident review following material security incidents.

170.2. The review should identify:

• (a) root cause;
• (b) impact;
• (c) security control failures;
• (d) remediation;
• (e) lessons learned; and
• (f) preventive actions.

171.1. StampMitra may enforce this Security Policy through proportionate technical, administrative, and contractual measures.

171.2. Enforcement may include:

• (a) warnings;
• (b) remediation requirements;
• (c) increased monitoring;
• (d) rate restrictions;
• (e) credential rotation;
• (f) API restrictions;
• (g) Production access restriction;
• (h) account suspension;
• (i) credential revocation; and
• (j) termination.

172.1. StampMitra may take immediate action where necessary to protect:

• (a) platform security;
• (b) Developer Accounts;
• (c) customer information;
• (d) other Developers;
• (e) underlying systems;
• (f) availability; or
• (g) legal or regulatory interests.

173.1. Developers must not evade security restrictions by:

• (a) creating replacement accounts;
• (b) creating replacement credentials;
• (c) changing IP addresses;
• (d) using proxies;
• (e) using alternate identities;
• (f) using third-party accounts;
• (g) modifying applications; or
• (h) otherwise circumventing enforcement.

174.1. StampMitra may consider reinstatement following security enforcement.

174.2. Reinstatement may require:

• (a) remediation;
• (b) credential rotation;
• (c) security review;
• (d) additional verification;
• (e) implementation of specified controls; or
• (f) other reasonable conditions.

175.1. Access to the StampMitra API does not constitute certification of a Developer's security practices.

175.2. StampMitra does not represent that a Developer's application is secure merely because it successfully connects to StampMitra.

176.1. No internet-connected system can be guaranteed to be completely secure.

176.2. StampMitra maintains reasonable and appropriate security controls according to the nature of its services and applicable requirements.

176.3. Developers remain responsible for implementing appropriate safeguards within their own environments.

177.1. StampMitra may communicate security notices, credential alerts, vulnerability information, maintenance notices, or security-related instructions through appropriate channels.

177.2. Developers must maintain current contact information for security-related communications.

178.1. Security-related legal and policy communications may be directed to:

[email protected]

178.2. Developers should not include unnecessary secrets, passwords, API keys, OTPs, or sensitive personal information in initial security communications.

179.1. Security architecture, credentials, technical controls, non-public documentation, vulnerability information, and provider information may constitute confidential information.

179.2. Developers must not disclose such information except where authorized or legally required.

180.1. StampMitra may update this Security Policy where reasonably necessary due to:

• (a) security developments;
• (b) technological changes;
• (c) legal requirements;
• (d) regulatory requirements;
• (e) changes to API architecture;
• (f) changes to authentication mechanisms; or
• (g) operational requirements.

180.2. The current published version shall govern future use subject to applicable contractual requirements.

181.1. If any provision of this Security Policy is held invalid or unenforceable, the remaining provisions shall continue to operate to the extent permitted by law.

182.1. Failure to enforce a security requirement on one occasion does not constitute a permanent waiver of that requirement.

183.1. This Security Policy operates together with the StampMitra Developer Terms and other applicable policies.

183.2. The Security Policy does not replace the Acceptable Use Policy, Privacy Policy, DPA, Third-Party & Underlying Services Policy, Service Terms, or other contractual documents.

184.1. This Security Policy shall be governed by the laws of India, subject to the dispute-resolution provisions contained in the applicable StampMitra Developer Terms of Service.

• 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: https://developer.stampmitra.in/
• Legal Contact: [email protected]

By accessing or using StampMitra Developer Services, the Developer acknowledges that it has read, understood, and agreed to comply with this Security Policy.

The Developer understands that:

• (a) API credentials are confidential;
• (b) Production and Sandbox credentials must be appropriately separated;
• (c) security is a shared responsibility;
• (d) unauthorized access and security testing are prohibited;
• (e) personal and confidential information must be appropriately protected;
• (f) security incidents must be addressed promptly;
• (g) StampMitra may implement monitoring and security controls;
• (h) StampMitra may restrict or suspend access where necessary to protect security; and
• (i) continued access to StampMitra APIs is subject to compliance with applicable security requirements.

• Policy Name: StampMitra API Security Policy
• Policy Number: 06/10
• Version: 1.0
• Status: FINAL — PUBLISHED POLICY
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026
• Operator: BANI GLOBAL INDUSTRIES LLP
• LLPIN: ACI6373
• Legal Contact: [email protected]
• Prepared By: Legal Team, BANI GLOBAL INDUSTRIES LLP
• Developer Platform: https://developer.stampmitra.in/