API & Developer Terms

1. Scope

These terms apply to developers using VettiGuard APIs, SDKs, webhooks, sandbox environments, developer documentation, downloadable packages and integration credentials. They supplement the Terms of Service.

2. Credentials

Private site secrets, server API keys, mobile secrets and signing secrets must be protected according to their documented trust boundary. Do not place private server credentials in browser JavaScript, public mobile bundles, URLs, client-side logs, analytics or public repositories.

If a credential may have been exposed, rotate or revoke it promptly.

3. Server-side verification

Client-side completion is not final authority for a protected action. Where the integration contract requires server verification, the customer's backend must verify the response and enforce hostname/application, action, expiry, replay and assurance requirements before performing the protected operation.

4. Data minimisation

Send only fields required by the documented endpoint. Use opaque subject, device and transaction references where possible. Do not send passwords, access tokens, cookies, full request bodies, payment-card security data or unrelated sensitive information in generic metadata or custom keys.

5. Sandbox

Sandbox credentials, deterministic scenarios and sandbox response tokens are for development and testing only. Production endpoints must not treat sandbox proof as production assurance. Developers must not attempt to convert, forge or replay a sandbox artefact into production.

6. Rate limits and fair use

Developers must respect published rate limits, quotas and concurrency controls and must not split accounts or credentials to evade them. Load testing that could materially affect shared infrastructure requires prior authorisation.

7. Webhooks

Webhook consumers must verify signatures using the exact method documented by VettiGuard, protect webhook secrets, use idempotency where appropriate and reject stale, malformed or replayed events.

8. SDKs and packages

VettiGuard SDKs may include separate open-source or package licence notices. Use of an SDK does not change the security responsibilities of the underlying API. Customers should pin supported versions, review release notes and plan migration before announced end-of-support dates.

9. Prohibited developer activity

Developers must not reverse engineer private services to bypass controls, scrape another customer's data, forge trust outcomes, defeat licensing, remove required security checks, or use undocumented privileged endpoints without authorisation.

10. Compatibility and changes

VettiGuard may evolve APIs to address security, reliability and product changes. Material breaking changes to public production APIs should be documented and, where practicable, accompanied by a migration path or notice period. Emergency security changes may take effect sooner.

11. Third-party dependencies

An integration may depend on device attestation, communications, hosting, recipient networks or other providers. Developers must handle timeout, unavailable, retry and fail-safe conditions and must not silently convert a required verification dependency failure into success.

12. Support

Integration questions may be submitted to support@vettiguard.com. Include safe request references and error codes, not production secrets or identity evidence.