API Versioning, Suspension & Deprecation Policy

1.1 This API Versioning, Suspension & Deprecation Policy (“Policy”) establishes the framework governing the lifecycle of StampMitra APIs, including API versions, releases, changes, deprecation, migration, suspension, restriction, retirement, and discontinuation.

1.2 The purpose of this Policy is to provide Developers with a predictable framework for API lifecycle management while preserving StampMitra's ability to protect security, legal compliance, service integrity, infrastructure, external dependencies, and the interests of its Developers and End Users.

1.3 This Policy applies to APIs, API versions, endpoints, schemas, authentication mechanisms, webhook interfaces, SDKs, developer-facing technical interfaces, and other API-related functionality designated by StampMitra.

1.4 This Policy forms part of the StampMitra Developer Policy Framework.

2.1 This Policy forms part of the StampMitra Developer Terms of Service.

2.2 By accessing or using StampMitra APIs, the Developer agrees to comply with this Policy.

2.3 Additional API-specific documentation may impose technical requirements that supplement this Policy.

2.4 A written Enterprise or commercial agreement may contain additional lifecycle provisions applicable to that Developer.

3.1 “API” means an application programming interface made available by StampMitra.

3.2 “API Version” means a formally identified version of an API.

3.3 “Current Version” means an API version designated by StampMitra as the principal supported version for new integrations.

3.4 “Legacy Version” means an API version that remains operational but is no longer the principal version for new integrations.

3.5 “Deprecated Version” means a version for which StampMitra has formally announced that continued use is being phased out.

3.6 “Retired Version” means an API version that is no longer available for normal use.

3.7 “Breaking Change” means a change that may reasonably require a Developer to modify an existing integration to maintain compatibility.

3.8 “Non-Breaking Change” means a change that is reasonably designed to preserve compatibility with an existing integration.

3.9 “Sunset Date” means the date on which a Deprecated Version is scheduled to cease normal operation.

3.10 “Migration” means the process of moving an integration from one API version, interface, or Service to another.

3.11 “Security Emergency” means a security circumstance requiring urgent modification, restriction, or discontinuation of an API or API functionality.

3.12 “Service Dependency” means an external or internal service required for an API function to operate.

3.13 “Developer” means an individual or organisation authorised to use StampMitra Services.

3.14 “Production” means the live environment intended for real Transactions.

3.15 “Sandbox” means a test or development environment made available by StampMitra.

4.1 StampMitra may manage APIs through lifecycle stages including:

• (a) Development;
• (b) Preview;
• (c) Beta;
• (d) General Availability;
• (e) Current;
• (f) Legacy;
• (g) Deprecated;
• (h) Restricted;
• (i) Suspended; and
• (j) Retired.

4.2 Not every API will necessarily pass through every lifecycle stage.

4.3 StampMitra may designate lifecycle stages through documentation, dashboard notices, release notes, technical communications, or other official channels.

5.1 API versions may be identified through URL paths, headers, parameters, API configuration, SDK versions, documentation identifiers, or another technical mechanism.

5.2 Developers must use the version identifier specified in the applicable documentation.

5.3 Developers must not infer API version support from undocumented implementation behaviour.

5.4 Internal provider versions or internal system versions do not necessarily correspond to public StampMitra API versions.

6.1 StampMitra may designate one or more API versions as Current.

6.2 New integrations should generally use the Current Version unless otherwise directed.

6.3 StampMitra may maintain multiple supported versions where operationally appropriate.

7.1 A Legacy Version may remain available for existing integrations.

7.2 StampMitra may restrict the creation of new integrations on a Legacy Version.

7.3 Legacy Versions may receive limited maintenance and may not receive new functionality.

8.1 StampMitra may designate an API Version as Deprecated when continued operation is being phased out.

8.2 Deprecation does not necessarily mean immediate unavailability.

8.3 Developers using a Deprecated Version are expected to migrate within the applicable migration period.

9.1 A Retired Version is no longer available for normal API use.

9.2 Requests to a Retired Version may return an error indicating that the version is unavailable or unsupported.

9.3 StampMitra is not required to maintain compatibility with a Retired Version.

10.1 StampMitra may determine the supported API versions based on technical, security, commercial, regulatory, operational, and external dependency considerations.

10.2 Support for a version may include documentation, technical operation, bug fixes, security remediation, or other support determined by StampMitra.

10.3 A version being technically accessible does not necessarily mean that it remains fully supported.

11.1 StampMitra may announce material version changes through:

• (a) Developer Portal notices;
• (b) API documentation;
• (c) changelogs;
• (d) dashboard notifications;
• (e) email;
• (f) technical notices;
• (g) service communications; or
• (h) other official channels.

12.1 StampMitra may maintain a changelog describing API changes.

12.2 Developers should regularly review applicable release information.

12.3 The changelog may describe:

• (a) new functionality;
• (b) modified functionality;
• (c) deprecated functionality;
• (d) bug fixes;
• (e) security changes;
• (f) schema changes;
• (g) endpoint changes; and
• (h) migration requirements.

13.1 StampMitra may introduce reasonable Non-Breaking Changes without creating a new major API Version.

13.2 Examples may include:

• (a) adding optional response fields;
• (b) adding new optional request fields;
• (c) adding new endpoints;
• (d) improving documentation;
• (e) adding new error descriptions;
• (f) performance improvements; or
• (g) security improvements.

13.3 Developers must design integrations to tolerate documented additive changes where reasonably possible.

14.1 StampMitra may introduce Breaking Changes through a new API Version or another appropriate lifecycle mechanism.

14.2 Breaking Changes may include:

• (a) removing an endpoint;
• (b) changing required parameters;
• (c) changing authentication requirements;
• (d) materially changing response structure;
• (e) changing data types;
• (f) removing supported functionality;
• (g) changing webhook contracts; or
• (h) materially changing error behaviour.

15.1 Developers are responsible for migrating their integrations when a version is Deprecated or Retired.

15.2 StampMitra may provide migration documentation where reasonably practicable.

15.3 Developers should test migration changes in Sandbox before deploying them to Production.

16.1 Migration documentation may include:

• (a) version differences;
• (b) changed endpoints;
• (c) changed fields;
• (d) authentication changes;
• (e) webhook changes;
• (f) error changes;
• (g) example requests;
• (h) example responses; and
• (i) implementation instructions.

17.1 The Developer remains responsible for implementing migration changes.

17.2 StampMitra is not responsible for changes to the Developer's application, infrastructure, database, business logic, or customer workflows required for migration.

18.1 Where an API supports explicit version negotiation, Developers must use the mechanism documented by StampMitra.

18.2 Developers must not attempt to manipulate undocumented version headers, parameters, routes, or identifiers.

19.1 StampMitra may use headers for version identification, compatibility, deprecation notices, request tracing, security, or other technical purposes.

19.2 Developers must not depend on undocumented headers.

20.1 StampMitra may add, modify, move, or retire endpoints in accordance with the applicable lifecycle process.

20.2 Material endpoint removals may be treated as Breaking Changes.

21.1 New optional request fields may be introduced.

21.2 Required request fields may be modified where necessary through an appropriate versioning or migration mechanism.

21.3 Developers must not assume that undocumented fields will remain accepted.

22.1 New response fields may be introduced.

22.2 Developers should ignore unknown response fields unless the documentation states otherwise.

22.3 Removal or semantic alteration of a material response field may constitute a Breaking Change.

23.1 New enum values may be introduced where documented.

23.2 Developers should design applications to handle unknown or future enum values safely.

23.3 Developers must not assume that an enumeration is permanently closed unless expressly documented.

24.1 Error codes and error structures may evolve.

24.2 Developers must implement robust error handling.

24.3 Developers must not rely solely on human-readable error messages for application logic where stable error identifiers are provided.

25.1 StampMitra may use standard HTTP status codes and documented service-specific error information.

25.2 Developers must handle documented status codes appropriately.

25.3 Undocumented status-code behaviour must not be treated as guaranteed.

26.1 Webhook payloads may be versioned independently or as part of an API Version.

26.2 Developers must use the webhook schema specified for their integration.

26.3 Material webhook contract changes may require migration.

27.1 New webhook event types may be introduced.

27.2 Developers should ignore event types they do not recognise unless the documentation requires another response.

27.3 Existing event semantics must not be assumed beyond documented behaviour.

28.1 StampMitra may modify webhook authentication or security mechanisms where necessary.

28.2 Security changes may require Developers to update webhook verification logic.

29.1 Authentication methods may be modified or replaced for security or operational reasons.

29.2 StampMitra may require migration from an older authentication mechanism.

29.3 Developers must not continue using a deprecated authentication method after its retirement.

30.1 StampMitra may introduce changes to API credential formats, permissions, scopes, or lifecycle management.

30.2 Developers must maintain secure credential management.

30.3 A security-driven credential change may occur without ordinary migration periods where necessary.

31.1 StampMitra may introduce, modify, restrict, or retire API scopes.

31.2 A scope change may require Developer action.

31.3 Developers must request only the permissions necessary for their use case.

32.1 Rate limits may be adjusted based on security, capacity, service stability, abuse prevention, commercial terms, or operational requirements.

32.2 Rate-limit changes do not necessarily constitute API version changes.

32.3 Developers should implement backoff and retry controls.

33.1 File sizes, payload sizes, request limits, concurrency limits, pagination limits, or other resource limits may change.

33.2 Material changes will be communicated where reasonably practicable.

34.1 StampMitra may implement security changes independently of normal versioning.

34.2 Security changes may include:

• (a) authentication changes;
• (b) credential rotation;
• (c) endpoint restriction;
• (d) validation changes;
• (e) encryption changes;
• (f) webhook security changes;
• (g) rate controls; or
• (h) emergency restrictions.

35.1 Where an API contains a material security vulnerability, StampMitra may immediately modify, restrict, suspend, or retire the affected functionality.

35.2 StampMitra may provide limited notice where advance disclosure would increase security risk.

36.1 A Breaking Change may be implemented without the ordinary migration period where reasonably necessary to address:

• (a) an active security threat;
• (b) fraud;
• (c) unlawful access;
• (d) regulatory requirements;
• (e) material service abuse;
• (f) external system requirements; or
• (g) another serious operational risk.

37.1 Changes in applicable law or regulatory requirements may require API changes.

37.2 StampMitra may implement such changes within the timeframe reasonably necessary for compliance.

38.1 Government or authority systems may change their requirements independently of StampMitra.

38.2 StampMitra may modify API behaviour to accommodate such changes.

38.3 Such changes may require Developer migration.

39.1 StampMitra may depend on Underlying Service Providers and External Systems.

39.2 Changes to an underlying service may require changes to StampMitra APIs.

39.3 StampMitra may substitute, modify, or discontinue an underlying service in accordance with its Third-Party & Underlying Services Policy.

40.1 StampMitra is not required to disclose the identity of confidential Underlying Service Providers merely because an API behaviour changes.

40.2 Developers must not attempt to reverse engineer provider identities or routing arrangements.

41.1 If an external dependency is discontinued, restricted, or materially changed, StampMitra may:

• (a) replace the dependency;
• (b) modify the API;
• (c) restrict the affected functionality;
• (d) migrate traffic;
• (e) suspend the affected Service; or
• (f) discontinue the affected Service.

42.1 StampMitra may substitute underlying systems where reasonably necessary for continuity, security, compliance, performance, cost management, or operational reasons.

42.2 Internal substitution does not necessarily constitute a public API version change.

43.1 StampMitra may seek to preserve backward compatibility where commercially and technically reasonable.

43.2 Backward compatibility is not guaranteed indefinitely.

43.3 Security, legal, regulatory, and external dependency requirements may require compatibility changes.

44.1 Documentation may be updated independently of API versions.

44.2 Documentation corrections or clarifications do not necessarily constitute API changes.

45.1 SDKs may have independent release cycles.

45.2 An SDK update may be required to support a new API Version.

45.3 Developers are responsible for maintaining compatible SDK versions.

46.1 Client libraries may be updated to address API changes, security issues, or compatibility requirements.

46.2 StampMitra does not guarantee indefinite support for obsolete client libraries.

47.1 Sandbox may contain functionality that differs from Production.

47.2 Sandbox may be used to test migration changes.

47.3 Sandbox behaviour must not be treated as an unconditional guarantee of Production behaviour.

48.1 Developers should validate migration changes before deploying them to Production.

48.2 Developers are responsible for ensuring that Production credentials and endpoints are correctly configured.

49.1 StampMitra may permit multiple API versions to operate concurrently.

49.2 Dual-version availability does not mean that both versions will remain available indefinitely.

50.1 An End-of-Life notice may identify:

• (a) affected API version;
• (b) reason for retirement;
• (c) migration target;
• (d) expected migration requirements;
• (e) applicable dates; and
• (f) other relevant information.

51.1 StampMitra may establish a Sunset Date for a Deprecated Version.

51.2 After the Sunset Date, the version may be disabled.

51.3 Developers remain responsible for migration before the applicable Sunset Date.

52.1 StampMitra may, but is not required to, provide an extension to a Sunset Date.

52.2 Extensions may be granted based on technical, commercial, security, Enterprise, or other considerations.

52.3 An extension does not create a permanent right to continued operation.

53.1 Enterprise customers may receive migration arrangements under a written agreement.

53.2 Such arrangements may include additional migration support or agreed timelines.

54.1 Developers should test:

• (a) authentication;
• (b) request validation;
• (c) responses;
• (d) error handling;
• (e) webhooks;
• (f) retries;
• (g) idempotency;
• (h) transaction reconciliation; and
• (i) security controls.

55.1 API Version migration does not necessarily migrate historical data.

55.2 Developers remain responsible for migrating data stored in their own systems.

55.3 Where StampMitra provides migration tooling, its availability and scope will be described separately.

56.1 Historical Transactions may retain their original API version or data structure.

56.2 Developers must not assume that historical Transactions will be transformed automatically into a newer schema.

57.1 Developers must not assume that every response field will exist indefinitely.

57.2 Developers should implement defensive parsing and validation.

58.1 Developers should generally ignore unknown fields unless the applicable API documentation requires otherwise.

58.2 Unknown fields may be introduced as part of Non-Breaking Changes.

59.1 Individual fields may be Deprecated without immediately retiring the entire API Version.

59.2 Developers should stop using Deprecated fields within the communicated migration period.

60.1 Individual endpoints may be Deprecated.

60.2 A Deprecated endpoint may continue to operate temporarily.

60.3 Continued operation does not guarantee indefinite support.

61.1 Parameters may be Deprecated.

61.2 Developers may be required to replace them with newer parameters or workflows.

62.1 Error codes may be Deprecated or replaced.

62.2 Developers should rely on documented stable identifiers where available.

63.1 Webhook fields may be Deprecated.

63.2 Developers should update webhook processors accordingly.

64.1 Legacy authentication methods may be Deprecated.

64.2 Continued use after the applicable deadline may result in authentication failure.

65.1 StampMitra may communicate deprecation through documentation, headers, dashboard notices, emails, changelogs, or other channels.

65.2 Developers should not rely on one communication mechanism exclusively.

66.1 Migration deadlines may vary according to the nature and risk of the change.

66.2 Security or regulatory changes may have shorter timelines.

67.1 If a Developer fails to migrate before a Sunset Date, the affected API may stop functioning.

67.2 StampMitra is not responsible for Developer losses resulting solely from failure to complete a communicated migration.

68.1 StampMitra may provide technical documentation or reasonable migration guidance.

68.2 Migration assistance does not constitute custom software development unless separately agreed.

69.1 StampMitra may provide automated migration tools where feasible.

69.2 Developers must validate the output of automated migration tools before Production use.

70.1 Developers should test critical workflows against the target version.

70.2 Testing should include real-world business logic relevant to the Developer's application.

71.1 Developers may be required to explicitly select an API Version.

71.2 Version pinning does not guarantee indefinite availability.

72.1 StampMitra may designate a default API Version for requests where explicit versioning is not required.

72.2 Developers should not rely on the default version indefinitely unless expressly documented.

73.1 StampMitra may override or restrict version selection where necessary for security, legal, regulatory, or operational reasons.

74.1 Unsupported versions may continue to respond in limited circumstances but are not guaranteed to function.

74.2 Developers should migrate to a supported version.

75.1 StampMitra may restrict a version to selected Developers, environments, use cases, or traffic levels.

75.2 Restricted access may be necessary for beta testing, migration, security, or capacity management.

76.1 StampMitra may suspend API access in accordance with the Developer Terms of Service, API Acceptable Use Policy, API Security Policy, and applicable law.

77.1 API access may be suspended or restricted due to:

• (a) material policy violation;
• (b) security risk;
• (c) suspected fraud;
• (d) unlawful activity;
• (e) credential compromise;
• (f) excessive abuse;
• (g) non-payment;
• (h) regulatory requirements;
• (i) external provider restrictions;
• (j) operational instability;
• (k) misuse of Services;
• (l) false verification information;
• (m) unauthorised access; or
• (n) other legitimate reasons permitted by contract or law.

78.1 StampMitra may suspend only specific:

• (a) endpoints;
• (b) API scopes;
• (c) Services;
• (d) projects;
• (e) workspaces;
• (f) credentials;
• (g) environments; or
• (h) transaction types.

79.1 StampMitra may immediately suspend access where credentials or systems appear compromised.

79.2 Security suspension may remain in effect until reasonable remediation is completed.

80.1 StampMitra may revoke API keys or other credentials where necessary for security, policy enforcement, account protection, or other legitimate purposes.

80.2 Developers must rotate credentials when requested.

81.1 Developers must immediately report suspected credential compromise.

81.2 StampMitra may revoke compromised credentials without advance notice.

82.1 API access may be restricted due to overdue amounts in accordance with the Billing, API Credits & Refund Policy and applicable commercial terms.

82.2 Restoration may require resolution of the outstanding billing issue.

83.1 API access may be restricted where traffic patterns indicate abuse, automated attacks, scraping, credential attacks, excessive retries, or other prohibited behaviour.

84.1 StampMitra may restrict or suspend Services where required by applicable law, court order, governmental direction, regulatory requirement, or lawful authority request.

85.1 An API function may be suspended where a required external service becomes unavailable, unlawful, restricted, or technically incompatible.

86.1 StampMitra may immediately suspend an API, endpoint, credential, account, or Service where necessary to prevent material harm.

86.2 Advance notice may not be possible in an emergency.

87.1 Where reasonably practicable, StampMitra may provide notice of suspension and the general reason.

87.2 Security, legal, fraud, or confidentiality considerations may limit the information provided.

88.1 Developers may contact StampMitra regarding a suspension where a review mechanism is available.

88.2 The Developer should provide accurate remediation information.

89.1 Reinstatement may require:

• (a) remediation;
• (b) credential rotation;
• (c) additional verification;
• (d) payment of outstanding amounts;
• (e) security controls;
• (f) compliance commitments; or
• (g) other reasonable conditions.

90.1 Submission of a support request does not automatically restore API access.

90.2 StampMitra may require completion of remediation before restoration.

91.1 API access may be terminated in accordance with the Developer Terms of Service.

91.2 Termination may result in permanent loss of access to the affected APIs.

92.1 Suspension does not necessarily result in immediate deletion of Developer data.

92.2 Data may be retained according to applicable retention, legal, security, contractual, and operational requirements.

93.1 Data handling following termination is governed by applicable policies and agreements.

93.2 Developers should export data they are lawfully entitled to retain before termination where export functionality is available.

94.1 API credentials associated with a terminated account may be revoked.

94.2 Revoked credentials must not be reused or circumvented.

95.1 Developers must not circumvent:

• (a) version restrictions;
• (b) suspension;
• (c) credential revocation;
• (d) rate limits;
• (e) endpoint restrictions;
• (f) account restrictions;
• (g) geographic restrictions; or
• (h) Service eligibility requirements.

96.1 Creating additional accounts, identities, credentials, projects, or organisations to evade a restriction is prohibited.

97.1 Developers must not use proxies, intermediary systems, unauthorised clients, credential sharing, or other mechanisms to circumvent a restriction.

98.1 Security research involving StampMitra APIs must comply with the API Security Policy.

98.2 Testing a Deprecated, Suspended, or Restricted API does not create an entitlement to continued access.

99.1 Developers must not conduct load, stress, penetration, or performance testing against Production APIs without appropriate authorisation.

100.1 StampMitra may throttle, queue, reject, or otherwise manage traffic to protect service stability.

101.1 Rate limits may be enforced automatically.

101.2 Repeated rate-limit violations may result in additional restrictions.

102.1 Developers must implement reasonable retry logic.

102.2 Excessive retries may be treated as abusive traffic.

103.1 Developers must preserve idempotency controls when migrating API versions.

103.2 Migration must not create duplicate Transactions.

104.1 Where technically supported, a version migration may continue to reference existing Transaction identifiers.

104.2 Developers must follow the migration documentation for transaction continuity.

105.1 Developers must ensure that migration does not incorrectly process delayed webhook or status events.

105.2 Event ordering must not be assumed unless documented.

106.1 Developers should design webhook processing to tolerate duplicate or replayed events.

106.2 Version migration must not disable existing security controls.

107.1 StampMitra may maintain backward-compatible webhook formats for a period determined by the applicable lifecycle plan.

107.2 Developers must migrate where required.

108.1 Where a request contains conflicting version indicators, StampMitra may reject the request.

108.2 Developers must use the documented version-selection method.

109.1 Documentation may identify the API version to which it applies.

109.2 Developers must ensure that examples correspond to the version being used.

110.1 Example code is provided for implementation guidance.

110.2 Example code does not constitute a guarantee of compatibility with every future version.

111.1 Human-readable error messages may change without constituting a Breaking Change.

111.2 Developers must use documented machine-readable identifiers where available.

112.1 StampMitra may introduce or modify security-related headers.

112.2 Developers must not reject valid requests merely because undocumented response headers change.

113.1 StampMitra may require updated network security standards.

113.2 Deprecated transport mechanisms may be retired for security reasons.

114.1 StampMitra may update certificate infrastructure.

114.2 Developers must maintain appropriate certificate validation and must not implement insecure certificate bypasses.

115.1 StampMitra may change API infrastructure, domains, routing, or network architecture where reasonably necessary.

115.2 Developers will be expected to use current official documentation.

116.1 Developers should not hard-code undocumented infrastructure IP addresses.

116.2 API connectivity should use documented hostnames and connection methods.

117.1 Infrastructure migrations may occur without an API version change where public behaviour remains compatible.

117.2 Developers must not depend on internal infrastructure characteristics.

118.1 StampMitra may change cloud, hosting, infrastructure, network, database, or service architecture.

118.2 Such changes do not necessarily create a public API version change.

119.1 Internal implementation may change without notice where public API compatibility is preserved.

120.1 StampMitra may monitor API usage to detect:

• (a) abuse;
• (b) security threats;
• (c) excessive traffic;
• (d) service instability;
• (e) policy violations;
• (f) operational anomalies; and
• (g) version migration patterns.

121.1 StampMitra may retain technical logs relating to version usage, requests, authentication, errors, suspension, migration, and other lifecycle events.

122.1 StampMitra may analyse aggregate API version usage to plan migrations and service lifecycle decisions.

122.2 Such analysis remains subject to applicable privacy and data protection requirements.

123.1 Developers are responsible for maintaining accurate administrative contact information.

123.2 Failure to receive a notice because of inaccurate contact information does not necessarily invalidate a published deprecation or retirement notice.

124.1 Official lifecycle communications may be delivered through:

• (a) Developer Portal;
• (b) API documentation;
• (c) dashboard;
• (d) registered email;
• (e) service notices;
• (f) changelog; or
• (g) other official StampMitra channels.

125.1 Developers should not rely on unofficial social media posts, community discussions, third-party documentation, or reverse-engineered information as authoritative lifecycle notices.

126.1 API lifecycle matters must be read together with the API SLA & Service Availability Policy.

126.2 Temporary service interruption does not necessarily constitute deprecation.

127.1 Security-related lifecycle matters are also governed by the API Security Policy.

127.2 In a security emergency, the Security Policy may permit immediate action.

128.1 Suspension or termination for misuse is also governed by the API Acceptable Use Policy.

129.1 Billing-related suspension is also governed by the Billing, API Credits & Refund Policy.

130.1 External service changes are also governed by the Third-Party & Underlying Services Policy.

131.1 Verification, e-Stamp, e-Sign, and other specialised Services may be subject to Service-specific terms.

131.2 Service-specific lifecycle changes may occur independently.

132.1 Retirement may be permanent.

132.2 Retired versions are not required to remain accessible for historical compatibility.

133.1 StampMitra may identify a replacement API Version or Service.

133.2 The replacement may have materially different technical or functional requirements.

134.1 Unless expressly agreed otherwise, the Developer bears its own costs associated with API migration.

135.1 Custom migration engineering, consulting, integration development, or dedicated support may be subject to separate commercial terms.

136.1 StampMitra may consider extension requests individually.

136.2 Approval of one extension does not create a right to future extensions.

137.1 StampMitra may temporarily freeze changes to an API Version for operational or migration purposes.

137.2 A freeze does not guarantee indefinite stability.

138.1 Beta or Preview APIs may change without the stability guarantees applicable to General Availability APIs.

138.2 Preview features may be withdrawn without becoming part of a Current Version.

139.1 Experimental features may be changed or discontinued at any time.

139.2 Developers should not use experimental features for critical Production workloads unless expressly approved.

140.1 Developers may provide feedback regarding API lifecycle changes.

140.2 Feedback does not create an obligation to maintain or modify a Service.

141.1 Feature requests are evaluated at StampMitra's discretion.

141.2 A requested feature may not be implemented or may be implemented differently from the request.

142.1 No compatibility commitment exists beyond what is expressly stated in the applicable documentation, commercial agreement, or policy.

143.1 Access to any API Version does not create a perpetual right to use that version.

144.1 Use of one version does not create a right to receive every future feature.

145.1 The documented API contract governs supported behaviour.

145.2 Internal implementation details do not form part of the public API contract unless expressly documented.

146.1 Undocumented endpoints are not supported.

146.2 Accessing or relying on undocumented endpoints may result in restriction or termination.

147.1 Developers must not reverse engineer APIs for the purpose of discovering internal services, providers, credentials, hidden endpoints, routing logic, or other confidential architecture.

148.1 Developers must not use API responses, network inspection, metadata, error messages, traffic analysis, or other techniques to identify confidential Underlying Service Providers.

149.1 Internal architecture, routing information, provider information, internal identifiers, security controls, and non-public lifecycle information may constitute Confidential Information.

150.1 StampMitra may suspend an individual endpoint without suspending the entire API.

151.1 StampMitra may revoke or restrict individual API scopes where necessary.

152.1 A particular project may be restricted independently from other projects associated with the same Developer account where appropriate.

153.1 A workspace may be restricted independently where supported by the platform architecture.

154.1 Production access may be suspended while Sandbox remains available, or vice versa, depending on the circumstances.

155.1 StampMitra may restrict Production access where additional security review is required.

156.1 Access to particular Production APIs may require additional verification, approval, contractual acceptance, or entitlement.

157.1 Sandbox access may be broader than Production access.

157.2 Sandbox access does not create an automatic entitlement to Production access.

158.1 StampMitra may periodically review API access based on security, usage, commercial, legal, or operational factors.

159.1 Material increases in API traffic may require advance coordination or review.

159.2 High-volume traffic without appropriate coordination may be subject to throttling or restriction.

160.1 StampMitra may migrate traffic between internal systems or external service dependencies without requiring Developer action where the public API remains compatible.

161.1 StampMitra may use failover or alternate service paths where available.

161.2 Failover does not guarantee uninterrupted service.

162.1 API lifecycle decisions may be influenced by business continuity requirements.

162.2 StampMitra may replace or retire systems to preserve long-term service continuity.

163.1 Disaster recovery events may require temporary service restrictions or technical changes.

164.1 Lifecycle changes or service restrictions caused by events beyond reasonable control are subject to the force majeure provisions of the Developer Terms of Service.

165.1 Nothing in this Policy limits StampMitra's obligation or right to comply with applicable law.

166.1 A lawful regulatory or governmental direction may require immediate API modification, restriction, suspension, or retirement.

167.1 A court order or other lawful legal requirement may require API access restrictions or data handling changes.

168.1 Changes in applicable data protection requirements may require changes to API fields, retention, access, consent, or processing mechanisms.

169.1 StampMitra may retire data fields that are no longer necessary, lawful, secure, or operationally supported.

170.1 StampMitra may reduce, restrict, or redesign API data collection where necessary for privacy or data minimisation.

171.1 Sensitive fields may be removed, masked, restricted, or changed for security reasons.

172.1 Logging behaviour may change to improve security, privacy, compliance, or operational reliability.

173.1 StampMitra may introduce additional audit or logging requirements for certain Services.

174.1 Developers may be required to implement additional controls following a material security or lifecycle change.

175.1 Developers must not disable security controls merely to maintain compatibility with an older version.

176.1 Deprecated authentication or security mechanisms must be removed from Production use within the applicable migration period.

177.1 Documentation for retired APIs may be archived or removed from the primary Developer Portal.

178.1 Archived documentation may be provided for historical reference but does not create a support commitment.

179.1 References to retired versions in historical transaction records, logs, or source code do not create continued API availability.

180.1 Developers should validate:

• (a) successful requests;
• (b) unsuccessful requests;
• (c) edge cases;
• (d) retries;
• (e) duplicate requests;
• (f) webhooks;
• (g) authentication;
• (h) authorisation;
• (i) error handling; and
• (j) reconciliation.

181.1 Developers are responsible for selecting an appropriate Production cutover time.

181.2 Developers should maintain rollback or contingency procedures where appropriate.

182.1 StampMitra may provide rollback mechanisms where technically feasible.

182.2 A rollback is not guaranteed.

183.1 Developers should monitor migrated integrations for:

• (a) error increases;
• (b) latency changes;
• (c) webhook failures;
• (d) transaction discrepancies;
• (e) authentication failures; and
• (f) unexpected response changes.

184.1 Developers must report material migration-related incidents through appropriate support or security channels.

185.1 Technical migration disputes should first be raised through the applicable support process.

185.2 Contractual disputes remain subject to the Developer Terms of Service.

186.1 StampMitra may maintain records of:

• (a) version releases;
• (b) deprecation notices;
• (c) sunset dates;
• (d) suspensions;
• (e) security changes;
• (f) migrations;
• (g) retirements; and
• (h) related communications.

187.1 StampMitra may update this Policy to reflect changes in technology, law, security, operations, API architecture, external dependencies, or commercial practices.

187.2 Material updates may be communicated through appropriate channels.

188.1 If any provision of this Policy is found invalid or unenforceable, the remaining provisions shall remain effective to the extent permitted by law.

189.1 Failure to enforce a provision does not constitute a waiver of future enforcement.

190.1 Unless expressly stated otherwise, this Policy does not create rights for third parties.

191.1 This Policy shall be governed by the governing law provisions of the StampMitra Developer Terms of Service, subject to applicable Indian law.

192.1 Disputes relating to this Policy shall be handled under the dispute-resolution mechanism contained in the StampMitra Developer Terms of Service.

193.1 This Policy forms part of the StampMitra Developer Policy Framework.

193.2 Where another StampMitra policy expressly governs a specific issue, that policy shall apply to that issue subject to the applicable order of precedence.

194.1 Legal and policy correspondence may be directed to:

[email protected]

194.2 Official Developer Platform:

https://developer.stampmitra.in/

195.1 By accessing or using StampMitra APIs, the Developer acknowledges that:

• (a) APIs may evolve;
• (b) API versions may be deprecated;
• (c) Developers are responsible for migration;
• (d) security or regulatory circumstances may require emergency changes;
• (e) API access may be restricted or suspended;
• (f) continued access to a version is not perpetual;
• (g) undocumented behaviour is not guaranteed;
• (h) external dependencies may require API changes; and
• (i) this Policy forms part of the contractual framework governing API use.

• Policy Name: API Versioning, Suspension & Deprecation Policy
• Policy Number: 10 of 10
• Version: 1.0
• Status: FINAL — PUBLISHED POLICY
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026
• Legal Entity: BANI GLOBAL INDUSTRIES LLP
• Prepared By: Legal Team
• Legal Contact: [email protected]