API Policies

This guide summarizes, for builders, the instruments that govern use of the All About Pawz API: principally the Developer Agreement, the API Access Tiers, the API Rate Limits and Quotas, and the API Key Management and Rotation Policy. It creates no terms of its own. Where this summary and any instrument differ, the instrument governs: read the instrument, not the summary, before you rely on a rule. The summary exists so an integrator can find the right instrument and understand, in working terms, what it requires: what you may do with the API and its data, what you may not, and what happens when the line is crossed.

Access is issued, not self-service

API access is issued by the Company and limited by seller type: manufacturer and supplier accounts receive API access for importing data (Developer Agreement; API Access Tiers). There is no self-service key sign-up, and access granted to one account is not transferable to another. Every policy in this guide applies to an issued credential from its first call. How keys are requested, scoped, rotated, and revoked is summarized in Authentication and Authorization and specified in API Key Management and Rotation.

Fair use

The API exists to build on the Platform, not to extract from it. Normal integration traffic: syncing your products, managing your orders, reading your analytics, serving the accounts that authorized you: is permitted within your tier. The following are not fair use

• Replicating the Platform's catalog or data to compete with the Platform.
• Collecting buyer data beyond what your integration's purpose requires.
• Reselling or sublicensing API access to third parties.
• Building a competing marketplace on data obtained through the API.

The distinction is intent made visible through behavior: an integration that reads its own account's data is using the API; an integration that reads everyone's data to copy the marketplace is abusing it. Access obtained for one declared purpose and used for another is a violation of the Developer Agreement however polite its traffic pattern looks.

Data usage

Data you access through the API is licensed for your integration's purpose, not sold to you. You may use it to operate your integration and to serve the account or buyer it belongs to. You may not

• Sell Platform data, or provide it to third parties beyond the service providers your service genuinely requires.
• Use buyer data for purposes the buyer did not consent to.
• Retain data after the authorizing relationship ends.

When an account disconnects your integration or the relationship otherwise ends, its data is deleted on the schedule the Data Use, Retention and Deletion policy sets: from your databases, caches, exports, and analytics alike. Aggregated statistics are permitted only where the aggregation genuinely prevents re-identification and the governing instruments allow it. If a business model depends on the data rather than on the service, the business model is the violation. Scraping the Platform: through the API or around it: is prohibited outright (Scraping Prohibition).

Rate limits and quotas as policy

The technical limits in Rate Limit Headers and Core Concepts are also policy. Circumventing them: rotating keys to multiply a per-key limit, distributing load across identities, ignoring the stated backoff: is a violation of the API Rate Limits and Quotas independent of any technical harm. The intended behavior is modeled throughout this guide set: a 429 means back off for the stated window while other work continues (Feeds and Bulk Data). Tiers reflect the use described at issuance; a material change in use calls for a new tier, requested in advance: consistently hitting your ceiling because the business grew is a success to mark with a tier change, not a limit to engineer around.

Change, deprecation, and your side of the bargain

The Platform's commitments: changes are additive wherever possible; a change that cannot be made additively is announced in advance in the Changelog, under the Deprecation and Breaking Changes Policy, with time to move. Your commitments in return

1. Build clients that tolerate additive change: ignore unknown fields rather than failing (Overview).
2. Treat deprecation notices as work items with deadlines, not as noise.
3. Complete required moves within the announced window; integrations running past a window on a retired behavior are disabled, because unmaintained integrations are the ones that fail badly and publicly.
4. Keep your account's contact details current so notices reach someone who acts on them.

Security obligations

The controls in Security and Compliance and the Partner Security Requirements, restated as obligations under the Developer Agreement

• Credentials stay secret, server-side, and scoped to the minimum (Authentication and Authorization).
• Webhook signatures are verified on every delivery (Webhooks).
• Card data never touches your systems (Payments).
• Platform data stays inside the account scope that authorized it; cross-account use of a grant is prohibited (Solution Providers for providers serving several accounts).
• Incidents are disclosed promptly under the Breach Notification Requirements. A security failure in your integration that exposes Platform data is your incident to contain, disclose, remediate, and document. Prompt, honest disclosure is treated as mitigation; concealment as aggravation: because it is.

Automated clients

Automated and agent-driven integrations are bound by AI Agents and MCP and the Automated Access and Agent Disclosure policy: register the client, scope it narrowly, identify it as automated wherever it meets people, and accept that the account holder answers for its actions. An unregistered automated client calling the API is treated as unauthorized access.

Enforcement and appeals

Violations are handled in graduated steps: investigation, notice, an opportunity to cure, restriction of access for ongoing violations, and revocation of credentials for severe or repeated ones: under the Developer Agreement and the Partner Suspension, Termination and Appeals policy. Every enforcement action cites the policy violated and the evidence observed. Actions may be appealed through the channels those instruments provide; enforcement appeals and legal notices go to legal@aapawz.com. The Platform does not want to revoke integrations: every revocation is an account whose tooling broke: but it does revoke, because one bad integration's reach is every account and buyer it touches. Build as if revocation is real, because it is. How standing, certification, and appeals fit together is walked through in Governance.

The relationship

The API program works when both sides hold up their end: the Platform keeps the API stable and documented, and states plainly what each surface does and what each rule requires; the integrator builds within the contract, respects the data, and maintains the integration. The Developer Agreement, the API Access Tiers, and the API Rate Limits and Quotas are the written form of that arrangement. Cite them by section, not by memory: and when a policy changes, it is announced with the same notice discipline as an API change, and the same expectation that you will read it.

Questions about these policies: support@aapawz.com. Appeals and legal notices: legal@aapawz.com.