ZipZy® API Terms

1.1 Licence. Subject to these API Terms and your plan entitlements, we grant you a limited, non-exclusive, non-transferable, non-sublicensable, revocable licence to access the API solely to build and operate an Application that interoperates with the Services for your own business purposes or those of your customers.

1.2 Reservation. All rights not expressly granted are reserved. The API, its structure, documentation, and specifications remain our intellectual property.

1.3 Plan Dependency. API availability, scopes, endpoints, and quotas depend on your plan. Downgrading may reduce or remove API access.

1.4 Documentation. The API must be used in accordance with the published Documentation. Undocumented behaviour is not part of the API and may change without notice.

2.1 Issuance. API keys are generated from your Account. Each key is associated with a Workspace and, where supported, a defined set of scopes.

2.2 One-Time Display. The secret portion of a key is displayed once at creation and stored by us only as a hash. We cannot recover a lost key; generate a new one and revoke the old.

2.3 Confidentiality. API keys are credentials equivalent to a password. You must:

• Store keys in a secret manager or server-side environment variable, never in source control
• Never embed keys in client-side JavaScript, mobile applications, browser extensions, or any distributed artefact
• Never transmit keys in URLs, query strings, logs, screenshots, or support tickets
• Never share keys between environments, organisations, or customers
• Restrict key scopes to the minimum required

2.4 Rotation. Rotate keys at least every 12 months, on any personnel change with key access, and immediately on suspected exposure.

2.5 Compromise. Revoke a compromised key immediately from your Account and notify security@zipzy.in. You are responsible for all activity performed with your keys until revocation.

2.6 Automated Revocation. We scan public code repositories and paste sites for exposed ZipZy® keys. Keys found publicly exposed are revoked automatically and the Account owner notified.

3.1 Transport. All API requests must be made over HTTPS with TLS 1.2 or higher. Requests over plaintext HTTP are rejected.

3.2 Method. Authenticate using the mechanism described in the Documentation — typically a bearer token in the Authorization header. OAuth 2.0 authorisation code flow is available for Applications acting on behalf of other ZipZy® users.

3.3 Scopes. Request only the scopes your Application requires. We may deny or revoke access for Applications requesting excessive scopes.

3.4 On Behalf of Users. Where your Application acts for another ZipZy® user, you must obtain their informed authorisation through the documented OAuth flow, must not store their credentials, and must revoke access on their request.

3.5 Webhook Verification. Inbound webhooks must be verified using the signature header and shared secret described in the Documentation before their contents are trusted.

4.1 Published Limits. Rate limits apply per API key, per endpoint class, and per plan, and are published in the Documentation. Limits are typically expressed as requests per minute with a burst allowance.

4.2 Headers. Every response includes rate limit headers indicating the limit, remaining quota, and reset time. Your Application must read and respect these.

4.3 429 Handling. On receiving 429 Too Many Requests, your Application must honour the Retry-After header and back off. Implement exponential backoff with jitter. Immediate retry loops are prohibited and may result in blocking.

4.4 5xx Handling. On 5xx responses, retry with exponential backoff and a maximum retry count. Use idempotency keys, where supported, for write operations to avoid duplicate creation.

4.5 Evasion Prohibited. Distributing traffic across multiple keys, Accounts, IP addresses, or affiliated organisations to exceed limits is a violation of the Acceptable Use Policy and may result in permanent revocation.

4.6 Protective Throttling. We may apply temporary limits below published thresholds where necessary to protect platform stability, and will notify you where the restriction is sustained.

4.7 Higher Limits. Requests for increased limits may be made to support@zipzy.in with a description of your use case and projected volume.

API usage counts against your plan entitlements. Sustained volume materially exceeding your plan, or usage patterns that degrade performance for other customers, may result in throttling, overage charges where disclosed, or a requirement to upgrade. Bulk operations should use documented batch endpoints rather than high-frequency single-record calls.

6.1 Required Caching. Your Application must cache responses where the API indicates they are cacheable, and must honour Cache-Control, ETag, and Last-Modified headers using conditional requests.

6.2 Do Not Poll. Polling for changes is discouraged. Use webhooks where available. Where polling is unavoidable, poll no more frequently than the interval stated in the Documentation.

6.3 Cache Limits. Do not cache authentication tokens beyond their stated lifetime. Do not cache personal data longer than necessary for your Application's function, and never beyond the retention period permitted by the Privacy Policy and your own obligations.

6.4 No Persistent Mirror. You must not build or maintain a persistent independent copy of ZipZy® data for purposes unrelated to your Application's function, and must delete cached data on revocation of access or on the relevant user's deletion request.

6.5 Deletion Propagation. When you receive a deletion event or a 404/410 for a previously retrieved resource, you must purge that resource from your caches promptly.

7.1 Endpoint Requirements. Webhook endpoints must be publicly reachable over HTTPS with a valid certificate, must respond within the documented timeout, and must return a 2xx status on successful receipt.

7.2 Signature Verification. You must verify the signature on every webhook before processing. Reject unsigned or invalid payloads.

7.3 Idempotency. Webhooks may be delivered more than once. Your handler must be idempotent, keyed on the event identifier.

7.4 Ordering. Delivery order is not guaranteed. Use event timestamps and sequence identifiers where ordering matters.

7.5 Retries and Disablement. Failed deliveries are retried with exponential backoff. Endpoints failing persistently may be automatically disabled, with notification to the Account owner.

7.6 Fast Acknowledgement. Acknowledge receipt immediately and process asynchronously. Long-running processing inside the webhook handler causes timeouts and retries.

You will:

• comply with these API Terms, the Terms of Service, the Acceptable Use Policy, and all applicable law;
• accurately identify your Application, including a descriptive User-Agent string and contact email;
• maintain a current technical contact so we can reach you about breaking changes, security issues, and abuse;
• handle errors gracefully and avoid cascading retry storms;
• test against non-production data before deploying;
• monitor the changelog and deprecation notices, and update your Application within the notified windows;
• provide your own end users with a privacy notice and terms covering your Application;
• implement appropriate security in your Application, including protection of credentials and data received from the API; and
• promptly investigate and remediate abuse originating from your Application.

9.1 Where you retrieve personal data through the API, you are responsible for a lawful basis, notices, and consents relating to your own processing.

9.2 You must respect deletion, correction, and consent-withdrawal signals received through the API or communicated to you, and propagate them to your systems.

9.3 Where your Application processes personal data on behalf of a ZipZy® Customer, you are that Customer's processor and must have your own written processing terms with them.

9.4 You must not use API-retrieved data to build advertising profiles, to enrich third-party data brokerage products, or for any purpose disclosed neither to us nor to the affected individuals.

9.5 The Privacy Policy and, where applicable, the Data Processing Addendum govern our own processing.

You must not:

• Use the API to build, train, or improve a competing product or service
• Resell, sublicense, or redistribute API access, or provide it as a standalone service to third parties
• Reverse engineer the API, probe for undocumented endpoints, or attempt to bypass authentication, authorisation, or rate limiting
• Access another Customer's data or attempt to escalate privileges
• Use the API for bulk extraction of data unrelated to your Application's stated purpose, or for scraping
• Circumvent, disable, or interfere with security or monitoring features
• Use the API to generate, distribute, or facilitate spam, phishing, malware, or fraud
• Misrepresent your Application's identity, functionality, or affiliation with us
• Use the API in a manner that could damage, disable, or impair the Services or interfere with other Customers
• Retain or use data after your access has been revoked
• Use the API in safety-critical environments as described in the Acceptable Use Policy

We log and monitor API requests, including endpoint, timestamp, source address, key identifier, response status, latency, and payload size, for security, abuse prevention, capacity planning, billing accuracy, and support. Logs are retained per the Data Retention Policy. We may contact you about anomalous patterns and may require remediation as a condition of continued access.

12.1 Versioning. The API is versioned. Breaking changes are introduced only in a new version.

12.2 Non-Breaking Changes. Adding new endpoints, optional parameters, or response fields is not a breaking change. Your Application must tolerate unknown fields and must not rely on field ordering.

12.3 Deprecation Notice. We provide at least 90 days' notice before deprecating a stable API version or endpoint, communicated by email to registered technical contacts, in the changelog, and via response headers where feasible.

12.4 Security Exception. Where a change is required to address a security vulnerability or legal obligation, we may act with shorter or no notice, and will explain afterwards.

12.5 Beta Endpoints. Endpoints marked beta or experimental may change or be removed at any time without notice and are excluded from the Service Level Agreement.

13.1 API availability commitments for eligible paid plans are set out in the Service Level Agreement.

13.2 Developer support is provided at support@zipzy.in according to your plan's support tier. We support the API itself; we do not debug your Application's code.

13.3 Sandbox or test-mode credentials, where offered, are for development only and carry no availability commitment.

You may state that your Application “works with ZipZy®” or “integrates with ZipZy®” using plain text. You must not use our logos, imply endorsement, partnership, or certification, use “ZipZy” in your product name, company name, or domain, or use our marks in advertising, without prior written permission. See the Trademark Policy.

15.1 We may throttle, suspend, or revoke API keys or Application access, with or without notice, where: these API Terms or the Acceptable Use Policy are violated; a key is compromised or publicly exposed; usage threatens platform stability or security; fees are overdue; or required by law.

15.2 Where practicable we notify you first and allow remediation. In cases of active abuse, exposure, or security risk, revocation is immediate.

15.3 On revocation you must cease all API calls and delete cached data obtained through the API, except where retention is required by law.

15.4 Appeals may be sent to support@zipzy.in. Repeated violations result in permanent revocation.

The API is provided “as is”. We do not warrant that it will be uninterrupted, error-free, backward compatible indefinitely, or fit for any particular purpose. The warranty disclaimers, liability limitations, and indemnities in the Terms of Service apply in full to your use of the API. You will indemnify us against claims arising from your Application, including claims by your own end users.

We may update these API Terms. Material changes take effect 30 days after posting and notification to registered technical contacts. Continued use of the API after that date constitutes acceptance.

Pranava Company Group (ZipZy®)
62, Mandola, Loni, Ghaziabad, Uttar Pradesh 201102, Bharat (India)