API Key Management and Rotation
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers who hold Platform credentials.
Article 1: Introduction and Scope
1.1 This document governs every Credential the Company issues to or accepts from a Developer: an API key, a client secret, a session credential, and a webhook signing secret. It states the custody, storage, rotation, and compromise duties that attach to a Credential and the Developer's liability for use made with it. It does not govern a credential of the Company itself, which is never issued to a Developer.
1.2 If a provision of this document conflicts with the Terms of Use, this document controls for its subject. If a provision of this document conflicts with the Developer Agreement, the Developer Agreement controls, except that this document controls for Credential duties. Policies and help pages explain this document; they do not amend it.
Article 2: Definitions
2.1 In this document, terms defined in the Developer Agreement have the same meaning, and Compromise: disclosure, loss, or suspected disclosure or loss of a Credential to a person or system not authorized to hold it, including appearance of the Credential in a prohibited place under Article 5.
Rotation: replacement of a Credential by a newly issued Credential, followed by revocation of the replaced Credential.
Article 3: Issuance and Scopes
3.1 A Credential is issued per Application and per environment. A production Credential does not operate in the Sandbox, and a Sandbox Credential does not operate in Production. Issuance is to the Developer account; team access is exercised through the developer portal's member roles. The Developer shall not share a Credential among individuals as a substitute for separate access.
3.2 Every Credential carries scopes that name the resources and operations the Credential may reach. Scopes follow the principle of least privilege. The Developer shall request only the scopes the Application requires. The Company may narrow an over-scoped Credential on five (5) business days' notice, and the Application shall continue to operate under the narrowed scope.
3.3 A Credential is shown once at issuance and is not retrievable afterward; it is revocable and rotatable only. The Company stores only a protected representation of the Credential from which the Credential itself cannot be recovered. The Developer shall transmit a Credential only in the header or other protected position the API Policies prescribe, and shall not place a Credential in a query string, in client-side code, in a mobile application package, or in a public repository.
Article 4: Session Credentials
4.1 Where access is by session credential, the Developer shall: (a) store the token on the server side only, and not in storage accessible to client-side scripts for a server-to-server integration; (b) not record the token in a log, and, if a token appears in a log, rotate the session and purge the log; (c) destroy the session on operator logout and on offboarding of the Seller or person the session serves; (d) treat an authentication failure as a direction to re-authenticate through the sign-in procedure, and not as a direction to retry by another means; and (e) handle expiry as the API Policies prescribe, without repeated submission of an expired token.
4.2 A session serves exactly one Seller or one person, as issued. An Application acting for multiple Sellers holds one session per Seller. Sessions shall not be shared, pooled, or transferred. The Developer shall not create a session credential for a Platform domain, and shall report a sign-in failure caused by a host mismatch to support@aapawz.com rather than forwarding a token to work around it.
4.3 A session credential has the maximum lifetime stated in the API Policies, measured from issuance, without renewal by use. Long-lived automation shall not be built on a session credential, and automation that re-authenticates with stored account credentials is treated as a compromised-credential pattern under the Partner Security Requirements.
4.4 The Developer shall not create, alter, or re-sign a session payload. A token the Company cannot verify is rejected, and an attempt to present an altered token is a material breach.
Article 5: Storage and Custody Duties
5.1 The Developer shall store each Credential as a secret: in environment variables at a minimum, and in a secrets manager or equivalent protected store where one is available.
5.2 The Developer shall not: (a) embed a Credential in client-side code, a mobile application, or a desktop program; (b) commit a Credential to version control; (c) transmit a Credential over an unencrypted channel; (d) share a Credential by email, chat, ticket, or image; or (e) record a Credential in an application log, an error report, or an analytics record.
5.3 A Credential found in a prohibited place is deemed compromised on discovery, whether or not evidence of use exists. The Developer shall revoke it within one (1) hour of discovery and shall notify the Company in accordance with Article 7.
Article 6: Rotation and Revocation
6.1 Maximum Credential age is ninety (90) days for a production Credential and one hundred eighty (180) days for a Sandbox Credential, measured from issuance and not from last use. A client secret under the OAuth App Registration and Review rotates on the same ninety (90) day schedule.
6.2 Rotation procedure: the Developer issues the replacement, deploys it, verifies traffic on the new Credential, and then revokes the replaced Credential. A dual-Credential grace period of up to seven (7) days is permitted during Rotation. The replaced Credential shall not outlive the grace period.
6.3 The Company gives notice before a Credential reaches its maximum age, in accordance with the schedule in the developer portal. On the day after the maximum age is reached without Rotation, the Credential is suspended automatically. Suspension for missed Rotation is a protective measure and ends when a fresh Credential is issued. A third such suspension in twelve (12) months is subject to review of the Developer's credential practices under Article 10.
6.4 A revoked Credential ceases to operate within sixty (60) seconds of revocation. On revoking a Credential, the Developer shall cease sending it immediately and shall purge it from every store within twenty-four (24) hours. Active use of a revoked Credential after twenty-four (24) hours is evidence of an incomplete secret inventory, and the Company may require an accounting of every place the Credential was held.
Article 7: Compromise Response and Liability for Credential Use
7.1 On suspected Compromise, the Developer shall: (a) revoke the Credential immediately, and in any event within one (1) hour of discovery; (b) determine the exposure period, from issuance or last Rotation to revocation, and the data and operations the Credential's scopes could reach in that period; (c) notify the Company without delay and in any event within twenty-four (24) hours, by notice to support@aapawz.com, with the exposure period, the scope assessment, and the remediation taken, in accordance with the Breach Notification Requirements; and (d) preserve logs for the exposure period for twelve (12) months and produce them on the Company's request within five (5) business days.
7.2 A scope assessment shall name the tenants whose data the scopes reached, the operations permitted (read or write), the time period, and whether a payment, payout, or refund scope was included. Where a payment, payout, or refund scope was exposed, the Developer shall state that fact expressly in the notice in clause 7.1(c) so that the notice receives payment escalation.
7.3 The Company may revoke a Credential unilaterally on evidence of Compromise, disclosure, or abuse, with notice to the Developer as soon as practicable after containment. Revocation under this clause does not require a prior proceeding, and appeal rights under Article 10 attach afterward.
7.4 The Developer is liable for every Call made with the Developer's Credentials, whether the Developer made the Call or another person made it using a Credential the Developer failed to protect, except where the Call results from the Company's own failure to apply the revocation period in clause 6.4. Liability under this clause includes the data, fee, and third-party consequences stated in the Developer Agreement and the Data Use, Retention and Deletion.
Article 8: Records
8.1 The Company records each Credential event: issuance, scope change, Rotation, suspension, revocation, and anomalous-use flag: with time, actor, and reason, and retains the record for twelve (12) months. The Developer may view the record for the Developer's own account in the developer portal.
8.2 The Developer shall keep a record of the same events for Credentials the Developer holds, including where each Credential was deployed and when it was purged, for twelve (12) months, and shall produce the record on the Company's request within five (5) business days.
Article 9: Liability
9.1 Exclusion of certain damages. To the fullest extent permitted by law, neither party is liable to the other for indirect, incidental, special, punitive, or consequential damages, or for lost profits, lost revenue, or loss of goodwill, arising out of or relating to this document, even if the party has been advised of the possibility of those damages.
9.2 Cap. To the fullest extent permitted by law, the Company's total liability arising out of or relating to this document shall not exceed the greater of (a) the amounts the Developer paid to the Company under this document in the twelve months before the event giving rise to the claim, or (b) one hundred dollars ($100).
9.3 Carve-outs. This article does not limit (a) a party's indemnification obligations under this document; (b) liability for fraud or willful misconduct; (c) amounts the Developer owes for Orders, fees, chargebacks, or refunds under this document; or (d) liability that cannot be limited under applicable law.
9.4 Essential purpose. The parties agree that this article allocates risk between them, that it is an essential part of the basis of their bargain, and that it applies even if a limited remedy fails of its essential purpose.
Article 10: Indemnification
10.1 Duty. The Developer shall indemnify, defend, and hold harmless the Company and its members, managers, employees, and agents from and against every claim, demand, action, loss, liability, judgment, settlement, cost, and expense (including reasonable attorneys' fees) arising out of or relating to: (a) the Developer's breach of this document; (b) the Developer's Applications and content; (c) the Developer's violation of any law or of the rights of any person; and (d) taxes for which the Developer is responsible under this document.
10.2 Procedure. The Company shall give prompt written notice of a claim under this article. The Developer shall control the defense with counsel reasonably acceptable to the Company. The Company may participate in the defense at its own expense. The Developer shall not settle a claim in a manner that imposes any obligation or restriction on the Company, or that does not release the Company fully, without the Company's prior written consent.
10.3 Survival. This article survives the termination of this document.
Article 11: Enforcement and Appeals
11.1 Investigation. The Company may investigate any suspected violation of this document. The Developer shall cooperate with an investigation and shall produce the records this document requires the Developer to keep.
11.2 Notice. If the Company determines that the Developer has violated this document, the Company shall give written notice stating the provision violated and the facts relied on, except where notice would compromise an investigation of fraud, a safety risk, or a legal obligation. Automatic suspension for missed Rotation and unilateral revocation on Compromise evidence are protective measures under Articles 6 and 7.
11.3 Opportunity to cure. Where a violation is capable of cure, the Developer has ten (10) business days from notice to cure it and to confirm the cure in writing. No cure period applies to sharing a Credential to evade a Tier limit, to fraud, or to a violation that by its nature cannot be cured.
11.4 Measures. If a violation is established and is not cured within the period allowed, the Company may, proportionate to the violation: (a) issue a written warning; (b) suspend or revoke a Credential; (c) suspend the Account or a program participation, in whole or in part; (d) terminate this document and the Account; and (e) exercise any other right or remedy available under this document or at law. Repeated protective suspensions, a storage violation under Article 5, and conduct described in clause 11.3 are subject to procedure under the Partner Suspension, Termination and Appeals.
11.5 Appeal. The Developer may appeal a measure under this article by written notice to legal@aapawz.com within thirty (30) days of the measure, stating the grounds and attaching the records relied on. The appeal is decided by a person who did not make the original decision. The Company's decision on appeal is final. A measure remains in effect during an appeal unless the Company directs otherwise in writing.
11.6 No waiver by delay. The Company's delay in acting on a violation is not a waiver of the violation or of any later violation of the same kind.
Article 12: Term and Termination
12.1 Term. This document takes effect when the Developer first holds a Credential and continues until terminated under this article or until the Developer Agreement terminates, whichever occurs first.
12.2 Termination by the Company. The Company may terminate this document on thirty (30) days' written notice for any reason, and immediately on written notice if the Developer materially breaches this document, engages in fraud, or becomes ineligible to participate.
12.3 Termination by the Developer. The Developer may terminate this document on thirty (30) days' written notice to support@aapawz.com, provided the Developer has no investigation outstanding and has revoked and purged every Credential.
12.4 Effect of termination. On termination: (a) every Credential is revoked and the Developer shall purge each Credential from every store within twenty-four (24) hours; (b) obligations that arose before termination survive until satisfied; and (c) the Company shall pay amounts owed, less amounts the Company may set off under this document, within thirty (30) days, except amounts held in connection with an open investigation or dispute.
12.5 Survival. The Definitions, Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions articles survive termination, together with the record duties in Article 8 for the periods stated there.
Article 13: Dispute Resolution
13.1 Any dispute arising out of or relating to this document, or to the relationship it governs, is governed by the Dispute Resolution Policy, which is incorporated into this document by reference.
Article 14: General Provisions
14.1 Amendments. The Company may amend this document by posting the amended document in the Document Center and giving notice to the Developer at the email address in the Account. An amendment that materially increases the Developer's fees or obligations takes effect thirty (30) days after notice; other amendments take effect on posting. Continued use of the Platform after the effective date of an amendment is acceptance of it. If the Developer does not accept an amendment, the Developer's remedy is to terminate under Article 12 before the amendment takes effect.
14.2 Notices. Legal notices under this document shall be sent to legal@aapawz.com. Operational notices, including a Compromise notice under Article 7, and all other communications shall be sent to support@aapawz.com. A notice to the Company is effective when the Company acknowledges receipt or, for email, one business day after sending, whichever is earlier. Notices to the Developer are effective when sent to the email address in the Account or posted to the Account's notice facility in the portal, whichever occurs first. The Developer shall keep the email address in the Account current. DMCA notices are given as provided in the DMCA and Copyright Policy, to the designated agent at legal@aapawz.com.
14.3 Governing law. This document is governed by the laws of the State of Tennessee, without regard to its conflict-of-laws rules. Subject to the Dispute Resolution Policy, any proceeding arising out of this document shall be brought in the state or federal courts located in Shelby County, Tennessee, and the parties consent to personal jurisdiction there.
14.4 Severability. If any provision of this document is held unenforceable, the provision shall be enforced to the fullest extent permitted, and the remaining provisions continue in full effect.
14.5 Entire agreement. This document, together with the documents it incorporates by reference, is the entire agreement between the Company and the Developer for the subject it governs and supersedes every prior or contemporaneous statement, communication, or agreement on that subject, whether written or oral.
14.6 Assignment. The Developer shall not assign this document or any right or obligation under it without the Company's prior written consent, and an assignment without consent is void. The Company may assign this document to an affiliate or in connection with a sale of all or part of its business, on notice to the Developer.
14.7 Waiver. A waiver of any provision of this document is effective only in writing and only for the instance stated. No waiver is a waiver of any other provision or instance.
14.8 Interpretation. Headings are for convenience only. "Including" means "including without limitation." This document shall not be construed against a party on the ground that the party prepared it. The English-language text controls over any translation.