API SLA & Service Availability Policy

1.1. This StampMitra API SLA & Service Availability Policy (“SLA Policy”) establishes the framework governing service availability, API operation, maintenance, incidents, support, service interruptions, external dependencies, performance expectations, and related service-level principles applicable to StampMitra Developer Services.

1.2. The purpose of this SLA Policy is to establish a clear and commercially reasonable framework concerning:

• (a) availability of StampMitra Developer Services;
• (b) planned maintenance;
• (c) emergency maintenance;
• (d) service incidents;
• (e) API degradation;
• (f) service interruptions;
• (g) external dependencies;
• (h) incident communication;
• (i) support and escalation;
• (j) transaction processing;
• (k) service restoration;
• (l) service exclusions;
• (m) service credits where expressly applicable; and
• (n) limitations relating to availability commitments.

1.3. This SLA Policy does not guarantee that the StampMitra API or any individual API endpoint will operate continuously without interruption.

2.1. This SLA Policy forms part of the StampMitra Developer Services contractual framework.

2.2. It must 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 API Security Policy;
• (f) StampMitra Third-Party & Underlying Services Policy;
• (g) applicable Service Terms; and
• (h) applicable Billing, Credits & Refund Policy.

2.3. In the event of conflict, the applicable contractual hierarchy established under the Developer Terms shall apply.

2.4. Any specific commercial SLA agreed in writing with an eligible Enterprise Developer may supplement or supersede the general provisions of this Policy to the extent expressly stated in that agreement.

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

3.2. “Availability” means the operational accessibility of an applicable StampMitra API or service, subject to the exclusions and measurement methodology contained in this Policy.

3.3. “Developer” means an individual or organization authorized to access StampMitra Developer Services.

3.4. “Developer Services” means the developer platform, APIs, documentation, dashboards, credentials, webhooks, and related services made available by StampMitra.

3.5. “Production” means the live environment authorized for actual service transactions.

3.6. “Sandbox” means the testing and development environment.

3.7. “Maintenance” means planned or unplanned technical activity performed to maintain, improve, secure, modify, or restore services.

3.8. “Planned Maintenance” means maintenance scheduled in advance.

3.9. “Emergency Maintenance” means maintenance reasonably required to address an urgent security, operational, infrastructure, legal, or service risk.

3.10. “Service Incident” means an event materially affecting availability, functionality, performance, integrity, or operation of an applicable StampMitra service.

3.11. “Degraded Service” means a condition where a service remains operational but experiences material reduction in performance, functionality, reliability, or response behavior.

3.12. “Underlying Service Provider” means an external provider, service, system, data source, infrastructure provider, governmental system, authorized external system, or other dependency used by StampMitra to deliver or support a service.

3.13. “Business Day” means a day recognized as a business day under applicable Indian commercial practice, unless otherwise specified.

3.14. “Service Credit” means a credit that may be granted under an applicable contractual SLA and does not constitute a cash refund unless expressly agreed.

4.1. StampMitra aims to operate its Developer Services in a reliable and commercially reasonable manner.

4.2. Availability may vary by:

• (a) API;
• (b) service;
• (c) region;
• (d) environment;
• (e) dependency;
• (f) maintenance requirement;
• (g) traffic conditions;
• (h) security conditions; and
• (i) other technical circumstances.

4.3. Availability is not necessarily uniform across every StampMitra service.

4.4. A service being accessible does not necessarily mean that every underlying transaction, verification, external dependency, or third-party process is available.

5.1. Unless a separate written SLA expressly states otherwise, StampMitra does not provide an unconditional guarantee of uninterrupted or error-free service.

5.2. Temporary service interruptions may occur due to:

• (a) maintenance;
• (b) infrastructure failure;
• (c) network failure;
• (d) security incidents;
• (e) traffic spikes;
• (f) software defects;
• (g) external dependencies;
• (h) governmental system availability;
• (i) telecommunications failures;
• (j) force majeure events; or
• (k) other circumstances beyond reasonable operational control.

5.3. Developers must design critical applications accordingly.

6.1. StampMitra may provide separate:

• (a) Sandbox;
• (b) staging or testing environments; and
• (c) Production environments.

6.2. Availability characteristics may differ between these environments.

6.3. Sandbox availability is not necessarily subject to the same service expectations as Production.

6.4. Developers must not treat Sandbox availability as a representation of Production availability.

7.1. Sandbox is primarily intended for:

• (a) development;
• (b) integration;
• (c) testing;
• (d) demonstrations; and
• (e) technical validation.

7.2. Sandbox may be subject to:

• (a) maintenance;
• (b) resets;
• (c) test-data changes;
• (d) functional limitations;
• (e) rate restrictions; and
• (f) other development-related changes.

7.3. Unless expressly agreed otherwise, Sandbox is not intended for critical Production workloads.

8.1. Production is intended for authorized live integrations.

8.2. Production access may require additional verification, technical controls, or commercial authorization.

8.3. Production service may be subject to:

• (a) rate limits;
• (b) security controls;
• (c) maintenance;
• (d) external dependencies;
• (e) service-specific limitations; and
• (f) applicable contractual terms.

9.1. Where an availability commitment is expressly applicable, availability may be measured using StampMitra's reasonable service monitoring and operational records.

9.2. Availability calculations may consider:

• (a) API health;
• (b) successful connectivity;
• (c) service response behavior;
• (d) error rates;
• (e) infrastructure monitoring;
• (f) incident records; and
• (g) other relevant technical indicators.

9.3. StampMitra's monitoring systems may constitute the primary operational record for determining service availability unless otherwise agreed in writing.

10.1. API availability means that the applicable API is operationally accessible for authorized requests.

10.2. API availability does not guarantee:

• (a) successful completion of every request;
• (b) successful completion of external transactions;
• (c) accuracy of external data;
• (d) immediate response from an external system;
• (e) uninterrupted webhook delivery; or
• (f) successful processing where Developer-submitted information is invalid or incomplete.

11.1. API availability and transaction success are separate concepts.

11.2. A functioning API may return an unsuccessful transaction because of:

• (a) invalid information;
• (b) failed verification;
• (c) external service failure;
• (d) regulatory restrictions;
• (e) insufficient information;
• (f) payment failure;
• (g) duplicate transaction controls;
• (h) external system rejection; or
• (i) other legitimate processing conditions.

11.3. Such transaction outcomes do not necessarily constitute an API availability failure.

12.1. StampMitra may depend upon external systems and service providers.

12.2. Such dependencies may include:

• (a) authorized underlying service providers;
• (b) payment infrastructure;
• (c) verification systems;
• (d) communication systems;
• (e) identity systems;
• (f) government or regulatory systems;
• (g) telecommunications infrastructure;
• (h) cloud infrastructure;
• (i) network providers; and
• (j) other external systems.

12.3. StampMitra does not control all external dependencies.

13.1. An external service may become:

• (a) unavailable;
• (b) degraded;
• (c) slow;
• (d) rate-limited;
• (e) unavailable in a particular region;
• (f) subject to maintenance;
• (g) modified without advance notice; or
• (h) discontinued.

13.2. Such conditions may affect StampMitra service performance.

13.3. External dependency failure may therefore prevent StampMitra from completing otherwise valid requests.

14.1. Additional provisions regarding external providers are contained in the StampMitra Third-Party & Underlying Services Policy.

14.2. StampMitra may dynamically route requests through authorized underlying systems.

14.3. A particular external provider may be substituted, replaced, added, removed, or temporarily disabled without creating a permanent entitlement to a particular provider.

15.1. StampMitra may maintain confidential relationships with external providers.

15.2. StampMitra is not required to publicly disclose confidential provider identities, technical configurations, commercial arrangements, or routing logic unless required by law or expressly agreed otherwise.

16.1. StampMitra may conduct Planned Maintenance.

16.2. Planned Maintenance may be required for:

• (a) software upgrades;
• (b) infrastructure upgrades;
• (c) database maintenance;
• (d) security improvements;
• (e) configuration changes;
• (f) network changes;
• (g) capacity improvements;
• (h) API upgrades;
• (i) disaster-recovery testing; or
• (j) other operational purposes.

16.3. StampMitra will use reasonable efforts to provide advance notice where practical and where the maintenance is expected to materially affect Production services.

17.1. Maintenance notifications may be communicated through:

• (a) Developer Platform notifications;
• (b) service status pages;
• (c) email;
• (d) API documentation;
• (e) support channels;
• (f) dashboards; or
• (g) other appropriate communication channels.

17.2. The method and timing of notification may vary according to the nature and urgency of the maintenance.

18.1. StampMitra may perform Emergency Maintenance without advance notice where reasonably necessary.

18.2. Emergency Maintenance may be required to address:

• (a) security vulnerabilities;
• (b) active attacks;
• (c) infrastructure failures;
• (d) critical software defects;
• (e) data integrity risks;
• (f) regulatory requirements;
• (g) external system failures; or
• (h) other urgent risks.

18.3. StampMitra will use reasonable efforts to restore affected services as soon as practicable.

19.1. Security-related maintenance may take priority over normal availability considerations.

19.2. StampMitra may temporarily restrict services where necessary to protect:

• (a) Developers;
• (b) customer data;
• (c) API infrastructure;
• (d) platform integrity;
• (e) external systems; or
• (f) other affected parties.

20.1. StampMitra may classify incidents according to severity.

20.2. Factors may include:

• (a) affected services;
• (b) number of affected Developers;
• (c) geographic scope;
• (d) duration;
• (e) transaction impact;
• (f) security implications; and
• (g) business impact.

21.1. A Critical Incident may involve substantial unavailability or severe impairment of a material Production service.

21.2. Examples may include:

• (a) widespread API unavailability;
• (b) material authentication failure;
• (c) significant transaction-processing disruption; or
• (d) serious security incidents affecting service operation.

21.3. Incident classification remains subject to StampMitra's reasonable operational assessment.

22.1. A Major Incident may involve significant degradation or partial unavailability affecting a material portion of the service.

22.2. Examples may include:

• (a) substantial endpoint failure;
• (b) significant processing delays;
• (c) major webhook disruption; or
• (d) material regional service degradation.

23.1. A Minor Incident may involve limited degradation or an issue affecting a smaller portion of functionality.

23.2. Examples may include:

• (a) non-critical endpoint issues;
• (b) isolated functionality failures;
• (c) documentation inconsistencies; or
• (d) limited performance degradation.

24.1. StampMitra may respond to incidents through:

• (a) monitoring;
• (b) technical investigation;
• (c) service isolation;
• (d) traffic management;
• (e) failover;
• (f) rollback;
• (g) configuration changes;
• (h) provider escalation;
• (i) infrastructure restoration; and
• (j) other reasonable remediation measures.

25.1. Where appropriate, StampMitra may communicate material incidents through a status page, Developer Platform, email, support channels, or other suitable means.

25.2. Incident communications may include:

• (a) affected services;
• (b) current status;
• (c) known impact;
• (d) mitigation activity;
• (e) estimated restoration information where reasonably available; and
• (f) resolution status.

25.3. StampMitra does not guarantee that every incident will receive a separate individualized notification.

26.1. StampMitra may operate a public or authenticated status page.

26.2. Status information may include:

• (a) API availability;
• (b) service incidents;
• (c) maintenance;
• (d) historical incidents; and
• (e) service component status.

26.3. Status information is intended as an operational communication mechanism and may not contain confidential technical details.

27.1. During a material incident, StampMitra may provide updates as reasonably practical.

27.2. Updates may be less frequent during complex investigations where premature information could be misleading or interfere with remediation.

28.1. An incident may be considered resolved when StampMitra reasonably determines that the affected service has returned to an operational state.

28.2. Temporary restoration does not prevent StampMitra from continuing post-incident investigation.

29.1. StampMitra may conduct an internal post-incident review.

29.2. Depending upon the circumstances, a review may examine:

• (a) root cause;
• (b) affected services;
• (c) duration;
• (d) mitigation;
• (e) preventive measures;
• (f) external dependency contribution; and
• (g) lessons learned.

30.1. StampMitra may provide a root-cause summary for material incidents where appropriate.

30.2. Root-cause information may be limited where disclosure could reveal:

• (a) security vulnerabilities;
• (b) confidential infrastructure information;
• (c) third-party confidential information;
• (d) provider information;
• (e) security controls; or
• (f) legally protected information.

31.1. A service may remain operational while experiencing degradation.

31.2. Degradation may include:

• (a) increased response times;
• (b) elevated error rates;
• (c) delayed processing;
• (d) delayed webhooks;
• (e) reduced functionality; or
• (f) partial service unavailability.

32.1. API response times may vary.

32.2. Response time can be affected by:

• (a) request complexity;
• (b) payload size;
• (c) infrastructure conditions;
• (d) external dependencies;
• (e) network conditions;
• (f) verification processing;
• (g) transaction processing; and
• (h) other factors.

32.3. Unless expressly agreed in a separate written SLA, StampMitra does not provide a universal response-time guarantee for every API request.

33.1. Certain services may operate asynchronously.

33.2. An asynchronous request may require:

• (a) polling;
• (b) webhook notification;
• (c) subsequent API retrieval;
• (d) background processing; or
• (e) another documented completion mechanism.

33.3. Developers must follow the applicable API documentation.

34.1. Where webhooks are provided, StampMitra may attempt delivery according to the applicable technical architecture.

34.2. Webhook delivery may be affected by:

• (a) Developer endpoint availability;
• (b) DNS failures;
• (c) TLS errors;
• (d) network failures;
• (e) timeout conditions;
• (f) response status codes;
• (g) external infrastructure; or
• (h) other technical conditions.

34.3. Developers must maintain reliable webhook endpoints where webhook functionality is business-critical.

35.1. StampMitra may retry webhook delivery where supported.

35.2. Retry behavior may vary according to service architecture.

35.3. Developers must implement idempotent processing where duplicate webhook delivery could create adverse consequences.

36.1. StampMitra is not responsible for unavailability caused solely by a Developer's systems.

36.2. Developer endpoint failures may include:

• (a) HTTP errors;
• (b) DNS failures;
• (c) certificate failures;
• (d) firewall restrictions;
• (e) application crashes;
• (f) overloaded servers; or
• (g) incorrect webhook configuration.

37.1. Developers must maintain infrastructure reasonably capable of consuming the applicable StampMitra services.

37.2. Developers should implement:

• (a) timeout handling;
• (b) retries;
• (c) idempotency;
• (d) monitoring;
• (e) alerting;
• (f) logging;
• (g) fallback handling; and
• (h) reconciliation procedures.

38.1. Developers must correctly handle documented API error responses.

38.2. Developers must not treat temporary errors as permanent transaction failures without appropriate reconciliation.

38.3. Developers should distinguish between:

• (a) validation errors;
• (b) authentication errors;
• (c) authorization errors;
• (d) rate-limit responses;
• (e) temporary service errors;
• (f) external dependency errors; and
• (g) transaction-specific failures.

39.1. StampMitra may enforce rate limits.

39.2. Rate limiting may be used to:

• (a) protect availability;
• (b) prevent abuse;
• (c) maintain fair resource allocation;
• (d) protect external dependencies; and
• (e) manage capacity.

39.3. Rate-limit enforcement is not necessarily an availability failure.

40.1. StampMitra may manage capacity dynamically.

40.2. Capacity controls may include:

• (a) request throttling;
• (b) concurrency controls;
• (c) queueing;
• (d) traffic shaping;
• (e) temporary restrictions; and
• (f) infrastructure scaling.

41.1. Developers expecting material increases in API volume should communicate such requirements where applicable.

41.2. Sudden unexplained traffic increases may trigger security or capacity controls.

41.3. Developers must not intentionally generate artificial traffic to test capacity without authorization.

42.1. Traffic spikes may result in temporary rate limiting or service degradation.

42.2. StampMitra may prioritize platform stability and security during unusually high traffic conditions.

43.1. Developer access is subject to reasonable use of platform resources.

43.2. Developers must not consume disproportionate resources in a manner that materially affects other Developers or platform operations.

44.1. StampMitra may maintain multiple API versions.

44.2. Developers should use the version specified in their Production integration.

44.3. Developers may be required to migrate from deprecated versions.

45.1. StampMitra may deprecate APIs, endpoints, fields, authentication mechanisms, or features.

45.2. Deprecation may be required because of:

• (a) security;
• (b) technology changes;
• (c) external dependency changes;
• (d) legal requirements;
• (e) operational requirements; or
• (f) product evolution.

46.1. Where commercially and technically practicable, StampMitra may provide advance notice of material API deprecations.

46.2. Notice may be provided through:

• (a) Developer Platform;
• (b) API documentation;
• (c) email;
• (d) release notices;
• (e) dashboards; or
• (f) other appropriate channels.

47.1. StampMitra may make immediate changes where required to address:

• (a) security vulnerabilities;
• (b) serious service instability;
• (c) external provider changes;
• (d) regulatory requirements; or
• (e) other urgent circumstances.

47.2. Advance notice may not always be possible.

48.1. StampMitra may seek to maintain reasonable backward compatibility but does not guarantee that every historical behavior will remain unchanged.

48.2. Developers should avoid relying on undocumented API behavior.

49.1. Underlying external systems may change without StampMitra's control.

49.2. Changes may affect:

• (a) fields;
• (b) response formats;
• (c) transaction processing;
• (d) verification behavior;
• (e) availability;
• (f) processing times; or
• (g) service functionality.

50.1. Where an underlying external system becomes unavailable, StampMitra may:

• (a) retry;
• (b) queue requests;
• (c) fail over;
• (d) return a temporary error;
• (e) return a pending status;
• (f) suspend affected functionality; or
• (g) take another reasonable operational action.

51.1. Where technically and commercially feasible, StampMitra may use alternate authorized systems or service providers.

51.2. Failover is not guaranteed for every service.

51.3. Provider selection and routing remain under StampMitra's operational control.

52.1. Government, regulatory, registration, verification, or public infrastructure systems may have independent operating hours, maintenance windows, technical limitations, or outages.

52.2. StampMitra cannot guarantee availability of external governmental systems.

52.3. Such external unavailability may affect transaction completion.

53.1. Services involving SMS, email, messaging, OTP, voice, or similar communication may depend upon telecommunications or messaging infrastructure.

53.2. Delivery may be affected by:

• (a) carrier issues;
• (b) network congestion;
• (c) filtering;
• (d) regional restrictions;
• (e) recipient configuration;
• (f) external provider issues; or
• (g) regulatory controls.

54.1. Payment-related services may depend upon external payment infrastructure.

54.2. Payment authorization, settlement, refund, reconciliation, or status may be affected by external systems.

54.3. Payment failure does not necessarily constitute StampMitra API unavailability.

55.1. Developers must implement appropriate transaction reconciliation.

55.2. Where a transaction status is uncertain, Developers should use the documented status-retrieval mechanism rather than assuming success or failure.

55.3. Duplicate requests should be avoided.

56.1. StampMitra may define maintenance windows for specific services.

56.2. Maintenance windows may vary by service and infrastructure.

56.3. A maintenance window does not necessarily mean that the entire StampMitra Developer Platform will become unavailable.

57.1. Where practical, planned material maintenance may be announced in advance.

57.2. The notice may include:

• (a) expected start time;
• (b) expected duration;
• (c) affected services;
• (d) expected impact; and
• (e) additional information where appropriate.

58.1. StampMitra may postpone, shorten, extend, or cancel planned maintenance.

58.2. Updated notices may be issued where practical.

59.1. StampMitra will use commercially reasonable operational efforts to restore affected services following material incidents.

59.2. Restoration may occur progressively rather than simultaneously across all components.

60.1. During major incidents, StampMitra may prioritize recovery based upon:

• (a) security;
• (b) data integrity;
• (c) platform-wide impact;
• (d) critical services;
• (e) external dependency availability; and
• (f) technical feasibility.

61.1. Service availability does not guarantee that all external transaction data will be immediately finalized.

61.2. Developers must rely on authoritative transaction statuses.

61.3. Developers must not assume that an interrupted connection means that the underlying transaction was rolled back.

62.1. Some operations may produce partial or intermediate results.

62.2. Developers must follow applicable API documentation for handling:

• (a) pending;
• (b) processing;
• (c) partially completed;
• (d) failed; and
• (e) completed states.

63.1. A network timeout does not necessarily mean transaction failure.

63.2. Developers should reconcile transaction status before initiating a duplicate operation.

64.1. Following a service incident, Developers must not automatically generate uncontrolled retries.

64.2. Developers should use appropriate backoff and idempotency mechanisms.

65.1. Security incidents may require temporary service restrictions.

65.2. StampMitra may prioritize security containment over normal availability.

65.3. Security-related restrictions may occur without advance notice where reasonably necessary.

66.1. StampMitra may implement traffic controls in response to suspected denial-of-service activity.

66.2. Such controls may affect legitimate traffic temporarily.

66.3. Developers must cooperate with reasonable mitigation requirements.

67.1. StampMitra may restrict traffic associated with:

• (a) abuse;
• (b) credential compromise;
• (c) automated attacks;
• (d) excessive traffic;
• (e) fraudulent activity;
• (f) prohibited usage; or
• (g) security threats.

67.2. Such restriction is not necessarily a service availability failure.

68.1. StampMitra shall not be responsible for failure or delay caused by circumstances beyond reasonable control.

68.2. Such circumstances may include:

• (a) natural disasters;
• (b) war;
• (c) terrorism;
• (d) civil unrest;
• (e) governmental action;
• (f) widespread internet disruption;
• (g) telecommunications failure;
• (h) power failure;
• (i) major cloud infrastructure failure;
• (j) epidemic or pandemic events;
• (k) cyberattacks;
• (l) strikes;
• (m) regulatory restrictions; or
• (n) other comparable events.

69.1. An external provider's material outage or failure beyond StampMitra's reasonable control may constitute an external dependency event.

69.2. StampMitra will use reasonable operational efforts to mitigate the resulting impact where technically feasible.

70.1. Unless expressly agreed otherwise, availability calculations do not necessarily include downtime or degradation caused by:

• (a) Developer systems;
• (b) Developer network connectivity;
• (c) Developer configuration;
• (d) Developer credentials;
• (e) Developer applications;
• (f) Developer misuse;
• (g) Developer rate-limit violations;
• (h) unauthorized security testing;
• (i) external systems;
• (j) underlying service providers;
• (k) governmental systems;
• (l) telecommunications providers;
• (m) force majeure events;
• (n) scheduled maintenance;
• (o) emergency maintenance;
• (p) security containment;
• (q) abusive traffic;
• (r) unsupported API usage;
• (s) deprecated API versions; or
• (t) other events outside reasonable StampMitra control.

71.1. A transaction failure resulting from invalid, incomplete, fraudulent, unauthorized, or legally restricted information is not necessarily a service availability failure.

71.2. A transaction rejected by an external authority or system is not necessarily a StampMitra service outage.

72.1. Availability issues caused by incorrect Developer configuration are excluded from service availability calculations.

72.2. Examples include:

• (a) incorrect API credentials;
• (b) incorrect webhook URLs;
• (c) invalid certificates;
• (d) incorrect IP allowlisting;
• (e) incorrect API version;
• (f) invalid request formats; and
• (g) application-side failures.

73.1. StampMitra is not responsible for internet connectivity between the Developer and StampMitra infrastructure.

73.2. Network routing outside StampMitra's reasonable control may affect API access.

74.1. Developer-controlled DNS failures are excluded from StampMitra availability calculations.

74.2. StampMitra may similarly rely upon DNS infrastructure outside its direct control.

75.1. Status-page information may be updated as an incident develops.

75.2. Historical status information may be corrected where technical investigation identifies an earlier classification or timing error.

76.1. StampMitra may provide support through designated channels.

76.2. Support channels may include:

• (a) Developer Platform;
• (b) support portal;
• (c) email;
• (d) ticketing systems;
• (e) technical documentation; and
• (f) other channels designated by StampMitra.

77.1. Support availability may vary according to:

• (a) Developer plan;
• (b) service;
• (c) severity;
• (d) contract;
• (e) channel; and
• (f) operational circumstances.

77.2. Unless expressly agreed otherwise, general support access does not constitute a contractual guarantee of a particular response time.

78.1. Developers reporting an incident should provide:

• (a) account or project identifier;
• (b) affected API;
• (c) timestamp;
• (d) request identifier where available;
• (e) error response;
• (f) affected environment;
• (g) geographic impact where relevant; and
• (h) steps already taken.

79.1. Developers must not include confidential credentials in support tickets.

79.2. Screenshots and logs should be sanitized before submission.

80.1. Developers must not intentionally submit false or misleading service incident reports.

80.2. Repeated abuse of support or incident channels may result in access restrictions.

81.1. API documentation may describe:

• (a) endpoint behavior;
• (b) request formats;
• (c) response formats;
• (d) rate limits;
• (e) authentication;
• (f) webhook behavior;
• (g) errors; and
• (h) version information.

81.2. Documentation may change as the service evolves.

82.1. Documentation may contain errors or omissions.

82.2. Developers should report material documentation inconsistencies through appropriate support channels.

82.3. Undocumented behavior should not be relied upon for critical Production functionality.

83.1. StampMitra may modify, improve, suspend, replace, or discontinue services subject to applicable contractual requirements.

83.2. Changes may arise from:

• (a) security requirements;
• (b) technology changes;
• (c) provider changes;
• (d) regulatory requirements;
• (e) commercial considerations;
• (f) product development; or
• (g) operational requirements.

84.1. Where reasonably practicable, StampMitra may provide advance communication for material changes likely to substantially affect Production integrations.

84.2. Advance notice may not be possible for urgent security or regulatory changes.

85.1. StampMitra may discontinue a service subject to applicable contractual requirements.

85.2. Where reasonably practicable, affected Developers may receive migration or discontinuation information.

86.1. Developers are responsible for completing required API migrations within applicable timelines.

86.2. StampMitra may provide migration documentation where appropriate.

87.1. Service Credits are available only where expressly provided under:

• (a) a written Enterprise agreement;
• (b) an applicable commercial SLA; or
• (c) another written agreement expressly granting such credits.

87.2. The general publication of this SLA Policy does not independently create an unconditional Service Credit entitlement.

88.1. Where a separate SLA provides Service Credits, the applicable agreement shall determine:

• (a) eligibility;
• (b) measurement period;
• (c) credit percentage;
• (d) maximum credit;
• (e) claim procedure; and
• (f) exclusions.

88.2. No Service Credit shall be implied merely because an incident occurs.

89.1. Where applicable, a Service Credit claim must be submitted according to the applicable contractual SLA.

89.2. Claims may require:

• (a) affected service;
• (b) incident period;
• (c) relevant account;
• (d) evidence of impact; and
• (e) other information reasonably required for verification.

90.1. A Service Credit is not automatically a cash refund.

90.2. Unless otherwise expressly agreed, Service Credits may be applied against future eligible charges according to the applicable agreement.

91.1. A Developer shall not receive duplicate compensation for the same service incident under multiple contractual mechanisms unless expressly agreed.

92.1. Temporary API unavailability does not automatically suspend subscription or recurring billing obligations.

92.2. Billing and refund matters are governed by the applicable Billing, Credits & Refund Policy and commercial agreement.

93.1. A failed transaction may result from causes unrelated to API availability.

93.2. Developers must use the applicable transaction status and reconciliation mechanisms before requesting duplicate processing.

94.1. Refund eligibility is governed by the applicable Billing, Credits & Refund Policy and Service Terms.

94.2. A service outage does not automatically establish entitlement to a refund of every related transaction or subscription charge.

95.1. StampMitra will maintain reasonable operational controls designed to protect data integrity.

95.2. Developers remain responsible for maintaining appropriate backups of data that they control or are legally required to retain.

95.3. Developers should not treat StampMitra as their sole backup mechanism unless expressly agreed otherwise.

96.1. StampMitra may maintain disaster-recovery and business-continuity measures appropriate to its services.

96.2. Specific recovery objectives are not guaranteed unless expressly stated in a written SLA.

97.1. StampMitra may maintain business-continuity procedures for material service disruptions.

97.2. Such procedures may include:

• (a) infrastructure redundancy;
• (b) operational failover;
• (c) provider alternatives;
• (d) restoration procedures;
• (e) incident escalation; and
• (f) controlled service recovery.

98.1. Unless expressly agreed in writing, StampMitra does not guarantee a specific recovery time for every incident.

98.2. Recovery duration may depend upon:

• (a) incident complexity;
• (b) security considerations;
• (c) infrastructure damage;
• (d) external dependencies;
• (e) provider response;
• (f) data integrity requirements; and
• (g) other circumstances.

99.1. Unless expressly agreed in writing, no specific recovery-point objective is guaranteed.

99.2. StampMitra will use reasonable operational measures to preserve data integrity.

100.1. Security incidents may require immediate restriction of API traffic.

100.2. Such restriction may be implemented even where it temporarily reduces availability.

100.3. Security containment takes precedence where necessary to protect users, systems, or data.

101.1. Security-related maintenance or containment may be excluded from availability calculations where expressly permitted by the applicable commercial SLA.

101.2. Developers acknowledge that temporary restrictions may be necessary to prevent larger security consequences.

102.1. StampMitra may modify or restrict services to comply with:

• (a) applicable law;
• (b) governmental directions;
• (c) regulatory requirements;
• (d) court orders; or
• (e) lawful authority requests.

103.1. Services involving regulated processes may depend upon regulatory or governmental systems.

103.2. Changes in government rules, processes, APIs, service availability, or operating procedures may affect StampMitra services.

104.1. Certain services may be available only in specified jurisdictions, states, districts, offices, or service areas.

104.2. Availability may therefore differ geographically.

104.3. Geographic restrictions may be imposed by law, service-provider coverage, or operational requirements.

105.1. Coverage information published by StampMitra may change.

105.2. Coverage does not constitute a guarantee that every transaction within a listed geographic area will succeed.

106.1. Certain APIs or services may be subject to:

• (a) subscription plans;
• (b) transaction limits;
• (c) credits;
• (d) eligibility requirements;
• (e) verification;
• (f) Production approval; or
• (g) separate commercial terms.

107.1. API access may depend upon an active Developer Account and compliance with applicable contractual requirements.

107.2. Suspended, terminated, or restricted accounts may not have normal API availability.

108.1. API access may be temporarily restricted because of:

• (a) suspected account compromise;
• (b) fraud;
• (c) abusive traffic;
• (d) policy violations;
• (e) security incidents;
• (f) legal requirements; or
• (g) other material risks.

109.1. Developer-controlled maintenance is outside StampMitra's availability measurement.

109.2. Developers should monitor their own:

• (a) application;
• (b) servers;
• (c) databases;
• (d) webhook endpoints;
• (e) network;
• (f) DNS; and
• (g) deployment infrastructure.

110.1. Developers using Production APIs should maintain appropriate monitoring.

110.2. Monitoring should identify:

• (a) API errors;
• (b) elevated latency;
• (c) authentication failures;
• (d) webhook failures;
• (e) transaction discrepancies; and
• (f) unusual traffic.

111.1. Developers should configure alerts appropriate to the criticality of their integration.

111.2. Alerts should be routed to personnel capable of responding to technical incidents.

112.1. StampMitra is responsible only for service components within its reasonable control.

112.2. Developers remain responsible for their own systems and integrations.

112.3. External service failures may require coordinated troubleshooting.

113.1. Where a service incident originates from an external provider, StampMitra may:

• (a) investigate;
• (b) escalate;
• (c) monitor;
• (d) implement alternatives where available; and
• (e) communicate material impact.

113.2. StampMitra cannot guarantee the actions or restoration timelines of external providers.

114.1. An incident may have multiple causes.

114.2. Root cause classification may therefore identify:

• (a) StampMitra infrastructure;
• (b) Developer infrastructure;
• (c) external provider;
• (d) telecommunications;
• (e) cloud infrastructure;
• (f) governmental system; or
• (g) combined causes.

115.1. During active incidents, information may be incomplete.

115.2. StampMitra may update or correct incident information as facts become available.

116.1. Incident investigations may contain confidential security information.

116.2. StampMitra may withhold information where disclosure could increase security risk or breach confidentiality obligations.

117.1. Developers are responsible for communicating service disruptions to their own end users where appropriate.

117.2. Developers must not falsely attribute a Developer-side outage to StampMitra.

118.1. Developers must not publicly represent that StampMitra guarantees a particular uptime, response time, or availability level unless such commitment is expressly contained in an applicable written agreement.

119.1. A Developer must not advertise an SLA on behalf of StampMitra unless expressly authorized.

119.2. Developer-specific customer contracts remain the Developer's responsibility.

120.1. A Developer must not assume that an SLA applicable to StampMitra with one external provider automatically applies to the Developer.

120.2. External provider agreements do not create third-party beneficiary rights for Developers unless expressly stated otherwise.

121.1. StampMitra may maintain internal availability records.

121.2. Availability information may be used for:

• (a) service improvement;
• (b) incident analysis;
• (c) capacity planning;
• (d) contractual SLA measurement; and
• (e) operational reporting.

122.1. Where a Developer disputes an availability determination, the Developer should provide:

• (a) relevant timestamps;
• (b) request identifiers;
• (c) affected endpoints;
• (d) error information;
• (e) relevant logs; and
• (f) other supporting evidence.

122.2. StampMitra may review available operational records.

123.1. StampMitra's monitoring records may include:

• (a) system metrics;
• (b) request logs;
• (c) error metrics;
• (d) infrastructure events;
• (e) deployment records;
• (f) incident records; and
• (g) external dependency information.

124.1. Technical records may be retained for security, operational, legal, audit, contractual, and service-improvement purposes, subject to applicable retention requirements.

125.1. Availability of an external data source does not guarantee the accuracy, completeness, or timeliness of the information supplied by that source.

125.2. StampMitra may normalize or transform external responses as part of service operation.

126.1. StampMitra may normalize external responses into StampMitra API formats.

126.2. Changes in external source behavior may require corresponding changes in StampMitra responses.

127.1. Developers should use documented response schemas.

127.2. Undocumented fields, headers, or response behavior should not be relied upon for critical Production functionality.

128.1. StampMitra may update documentation to reflect service changes.

128.2. Developers are responsible for reviewing relevant documentation for material changes affecting their integration.

129.1. API lifecycle matters are further governed by the StampMitra API Versioning, Suspension & Deprecation Policy.

129.2. Developers must comply with applicable migration requirements.

130.1. StampMitra may suspend all or part of a service where reasonably necessary due to:

• (a) security;
• (b) legal requirements;
• (c) material technical failure;
• (d) provider discontinuation;
• (e) abuse;
• (f) non-payment;
• (g) policy violations; or
• (h) other contractual grounds.

131.1. Where practical, StampMitra may restrict only the affected:

• (a) API;
• (b) endpoint;
• (c) credential;
• (d) project;
• (e) account;
• (f) region; or
• (g) transaction type.

132.1. Restoration may require:

• (a) security remediation;
• (b) verification;
• (c) payment resolution;
• (d) policy compliance;
• (e) technical correction; or
• (f) external dependency restoration.

133.1. Service restrictions resulting from Developer non-compliance are not considered StampMitra service availability failures.

134.1. Where permitted by applicable commercial terms, unpaid or overdue accounts may be subject to restricted service access.

134.2. Such restriction is not an infrastructure availability incident.

135.1. Restoration following billing resolution may depend upon system processing and applicable verification.

135.2. Developers should not assume instantaneous restoration unless expressly stated.

136.1. StampMitra may prioritize security, data integrity, and legal compliance over uninterrupted availability where necessary.

136.2. Temporary restrictions may therefore be implemented to prevent a more serious incident.

137.1. API availability or technical service operation does not constitute legal, financial, tax, regulatory, or professional advice.

137.2. Developers remain responsible for determining whether a service is appropriate for their particular use case.

138.1. Availability of an API does not guarantee:

• (a) regulatory approval;
• (b) government approval;
• (c) verification success;
• (d) transaction approval;
• (e) customer acceptance;
• (f) document validity;
• (g) payment completion; or
• (h) any particular commercial outcome.

139.1. Any liability arising from service availability shall be governed by the liability provisions of the StampMitra Developer Terms and any applicable written commercial agreement.

139.2. Nothing in this Policy independently expands StampMitra's liability beyond applicable contractual obligations.

140.1. Service interruption does not automatically create a right to damages, compensation, refund, credit, or other remedy except where such remedy is expressly provided by applicable contract or law.

141.1. Events qualifying as force majeure shall be treated according to the applicable Developer Terms and law.

141.2. StampMitra will use reasonable efforts to mitigate material impact where practicable.

142.1. StampMitra may maintain operational continuity measures appropriate to the scale and nature of its services.

142.2. Specific redundancy architecture, geographic redundancy, recovery objectives, or infrastructure details may remain confidential.

143.1. StampMitra is not required to disclose confidential infrastructure architecture, security configurations, provider relationships, internal routing logic, or operational procedures merely because a service incident occurs.

144.1. Where provided, Developers should consult official StampMitra status information before initiating incident escalation for widespread issues.

144.2. Developers should nevertheless report suspected incidents where status information does not adequately explain the observed issue.

145.1. Developers may report material service issues through the designated support channels.

145.2. Security-related incidents may also be communicated through:

[email protected]

146.1. A useful incident report should contain:

• (a) Developer identifier;
• (b) affected environment;
• (c) API;
• (d) endpoint;
• (e) approximate timestamps;
• (f) HTTP status;
• (g) request identifier;
• (h) error response;
• (i) geographic information where relevant;
• (j) frequency of occurrence; and
• (k) steps already taken.

147.1. Developers must sanitize credentials, OTPs, tokens, passwords, and unnecessary personal information before submitting incident reports.

148.1. StampMitra may escalate incidents internally or to appropriate external providers where required.

148.2. External escalation may affect resolution timelines.

149.1. StampMitra may use aggregated operational information to improve:

• (a) reliability;
• (b) performance;
• (c) security;
• (d) capacity;
• (e) API design; and
• (f) incident response.

150.1. StampMitra may collect technical service metrics including:

• (a) request counts;
• (b) error rates;
• (c) latency;
• (d) throughput;
• (e) availability;
• (f) infrastructure health; and
• (g) incident indicators.

151.1. Service monitoring and incident records containing personal data shall be handled in accordance with applicable privacy and data-protection requirements.

151.2. The StampMitra Developer Privacy Policy and DPA govern applicable personal-data processing matters.

152.1. StampMitra may update this SLA Policy where reasonably necessary due to:

• (a) technical changes;
• (b) service changes;
• (c) legal requirements;
• (d) regulatory requirements;
• (e) security requirements;
• (f) operational requirements; or
• (g) changes to external dependencies.

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

153.1. No statement in marketing materials, technical documentation, support communications, or informal correspondence shall create a binding SLA unless expressly incorporated into a written agreement.

154.1. StampMitra may enter into separate Enterprise SLA arrangements.

154.2. Such agreements may specify:

• (a) availability targets;
• (b) support commitments;
• (c) response targets;
• (d) incident escalation;
• (e) service credits;
• (f) maintenance procedures;
• (g) exclusions; and
• (h) other commercial terms.

155.1. If a written Enterprise SLA expressly conflicts with this Policy, the Enterprise SLA shall control solely with respect to the conflicting subject matter.

155.2. All other provisions of this Policy remain applicable.

156.1. If any provision of this SLA Policy is held invalid or unenforceable, the remaining provisions shall continue to apply to the maximum extent permitted by law.

157.1. Failure to enforce a provision on one occasion does not constitute a permanent waiver of that provision.

158.1. This SLA 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:

• (a) API availability may be affected by maintenance, security events, external dependencies, and other circumstances;
• (b) API availability does not guarantee successful completion of every transaction;
• (c) external systems may affect service operation;
• (d) Developers are responsible for their own infrastructure and integration reliability;
• (e) Developers should implement appropriate retries, idempotency, monitoring, reconciliation, and error handling;
• (f) StampMitra may conduct planned and emergency maintenance;
• (g) StampMitra may temporarily restrict services where necessary for security, legal, operational, or other legitimate reasons;
• (h) specific SLA commitments apply only where expressly agreed;
• (i) Service Credits are not implied unless expressly provided; and
• (j) the applicable Developer Terms and other policies remain binding.

• Policy Name: StampMitra API SLA & Service Availability Policy
• Policy Number: 07/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
• Registered Office: 2-A/3, Kundan Mansion, Asaf Ali Road, Turkman Gate, Central Delhi, NCT of Delhi, India – 110002
• Legal Contact: [email protected]
• Prepared By: Legal Team, BANI GLOBAL INDUSTRIES LLP
• Developer Platform: https://developer.stampmitra.in/