OAuth App Registration and Review
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers who register or operate an Application that acts on behalf of a Seller, a Buyer, or another End User.
Article 1: Introduction and Scope
1.1 This document governs registration and review of an Application that seeks delegated access: access to Platform data or actions on behalf of an End User, granted by that End User. It states the registration duties, the Company's review discretion, the scope of a grant, and the duty to obtain re-review for a change.
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 registration and review. 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 Grant: the scopes an End User authorizes for an Application through the consent procedure, together with the tokens issued under that authorization.
Redirect Address: an address registered for an Application to which the Company returns an End User after an authorization request.
Scope: a named permission for a resource and an operation, as the API Policies define the scope vocabulary.
Article 3: Eligibility and Registration
3.1 No Application shall operate against Production with delegated access without registration and written approval under this document. Access in the Sandbox for development does not authorize production access; production requires a separate registration and a separate approval.
3.2 Production registration requires Elevated Tier under the API Access Tiers, because delegated access is the means by which one Credential reaches data of more than one tenant. A Developer in a lower Tier shall obtain Elevated Tier before review; review does not substitute for the Tier decision.
3.3 The registration submission shall contain, completely and truthfully: (a) the Application name, a description, and a monitored support contact; (b) a privacy policy address and a data-retention statement that satisfies the Data Use, Retention and Deletion, stating what End User data the Application keeps, for how long, and when deletion occurs; (c) every requested Scope with a justification tied to a feature of the Application that a reviewer can see and exercise; (d) each exact Redirect Address, in the form Article 5 requires; and (e) a description of the flow of End User data: where the data travels, where it rests, and which subprocessors receive it, as the input to review under the Partner Security Requirements.
3.4 Registration truthfulness is a continuing duty. A false, incomplete, or misleading statement in a submission, including an omission of a Scope, a Redirect Address, a subprocessor, or a data use, is a material breach. The Developer shall correct a submission promptly on discovering an error and shall notify the Company at support@aapawz.com.
Article 4: Review and Scope Grants
4.1 The Company reviews every production Application before approval and may re-review at any time: after a Scope change, after a security incident, after a material change to the Application, on a complaint pattern, or at random. The review period is ten (10) business days from a complete submission. An incomplete submission does not start the period; the Company shall state what is missing within three (3) business days.
4.2 Review applies each of the following criteria, and failure of any one criterion is a ground for denial: (a) Scope necessity: every requested Scope is justified by a visible feature; a Scope without a visible feature, or with a general justification, is denied; (b) Redirect handling: each Redirect Address satisfies Article 5; (c) Consent honesty: the consent presentation, listing assets, and description state in plain language what the Application accesses and why, without a pre-selected consent, a bundled consent that requires acceptance of every Scope to continue, or another deceptive presentation; (d) Data duties: compliance with the Data Use, Retention and Deletion and, where the Application uses an automated agent, with the Automated Access and Agent Disclosure; and (e) Security: the posture the Partner Security Requirements require, as demonstrated in the submission.
4.3 Approval is in the Company's discretion, exercised against the criteria in clause 4.2. Approval may be conditional: fewer Scopes than requested, a probationary period of ninety (90) days with enhanced monitoring, or a transaction-volume limit until first re-review. A condition stated in an approval is part of the approval; operation in violation of a condition is operation outside the approval.
4.4 A Grant conveys only the Scopes stated in the approval and authorized by the End User. The Company does not expand a Grant without a fresh consent procedure. The Application shall operate on the subset of Scopes an End User grants, or decline the authorization without penalty to the End User; failure on denial of an optional Scope is a review failure.
4.5 Denial shall state the reasons, the criterion relied on, and what change would alter the outcome. The Developer may apply again after remediation. A re-application that does not address the stated reasons may be denied without a full review.
Article 5: Redirect Addresses and Authorization Requests
5.1 A Redirect Address shall: (a) use a secure encrypted connection in Production; an unencrypted address is rejected; (b) match a registered address exactly, with no wildcard, no subdomain wildcard, and no prefix matching; (c) in the Sandbox only, use a local test address in the exact form the API Policies permit; and (d) contain no parameter that forwards the End User to an arbitrary further address.
5.2 A mismatch between the Redirect Address in an authorization request and a registered address fails the request; the Company does not fall back to another address.
5.3 Each authorization request shall carry a single-use state value with an expiry and a binding to the browser that began the procedure, in the manner the API Policies prescribe. A consumed or expired state value is rejected.
5.4 Consent is per Scope and informed. The consent presentation lists each Scope in plain language with the reason the Application states for it. The End User grants or denies; partial grants are supported.
Article 6: Tokens, Revocation, and Changes
6.1 Token lifetimes are as the API Policies state: an access token has a short lifetime, and a refresh token has an absolute lifetime of ninety (90) days and rotates on each use. Replay of a consumed refresh token is treated as token theft: the entire Grant is revoked and the Developer is notified, in accordance with the API Key Management and Rotation.
6.2 A token is bound to the Scopes granted at consent. A request for additional Scopes requires a fresh consent procedure. A voluntary narrowing of Scopes takes effect immediately and is recorded.
6.3 An End User may revoke an Application's access at any time from the End User's account settings. Revocation takes effect within sixty (60) seconds: access tokens cease to validate and refresh tokens end. The Developer shall cease use of a revoked token immediately on revocation and shall delete locally held tokens. Use of a revoked token after the sixty (60) second period is unauthorized access under the Scraping Prohibition.
6.4 On revocation, on termination of the Application, or on withdrawal of approval, the deletion duties of the Data Use, Retention and Deletion apply to data obtained through the Grant. The Company deletes the Grant's tokens. A record that authorization existed: who authorized which Scopes, and when: is retained in accordance with the Company's retention schedule; deletion covers End User data, not the fact of authorization.
6.5 An approved Application shall re-certify annually: Scopes remain justified, Redirect Addresses remain accurate, the data-flow description remains true, and the security posture continues to meet the Partner Security Requirements. A material change: a new Scope, a new Redirect Address, a new subprocessor, or an acquisition of the Developer: requires re-review before the change takes effect in Production. Deployment of a material change before re-review is a violation of this document.
Article 7: Fees
7.1 Fees, if any, for registration, review, or delegated access are governed by the API Monetization and Usage Fees Policy. A fee is payable under this document only if the fee is stated in that document.
Article 8: Liability
8.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.
8.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).
8.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.
8.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 9: Indemnification
9.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, including an End User who granted access; and (d) taxes for which the Developer is responsible under this document.
9.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.
9.3 Survival. This article survives the termination of this document.
Article 10: Enforcement and Appeals
10.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, including the registration submission and consent records.
10.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.
10.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 a deceptive consent presentation discovered after approval, to Scope abuse, to fraud, or to a violation that by its nature cannot be cured.
10.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 withdraw approval and revoke every token issued under the approval, within the sixty (60) second period in clause 6.3; (c) suspend or revoke a Credential; (d) suspend the Account or a program participation, in whole or in part; (e) terminate this document and the Account; and (f) exercise any other right or remedy available under this document or at law. Grounds for suspension or withdrawal include a deceptive consent presentation, Scope abuse, an unremedied security incident, and downgrade below Elevated Tier. Procedure is further governed by the Partner Suspension, Termination and Appeals.
10.5 Appeal. The Developer may appeal a measure under this article, and may appeal a denial under clause 4.5 as that clause and the Partner Suspension, Termination and Appeals provide, by written notice to legal@aapawz.com within thirty (30) days of the measure or denial, 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.
10.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 11: Term and Termination
11.1 Term. This document takes effect when the Developer submits a registration or first seeks delegated access, whichever occurs first, and continues until terminated under this article or until the Developer Agreement terminates, whichever occurs first.
11.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.
11.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 completed the deletion duties on termination.
11.4 Effect of termination. On termination: (a) approval ends and every Grant and token under it is revoked; (b) the Developer shall delete data obtained through a Grant in accordance with the Data Use, Retention and Deletion; (c) obligations that arose before termination survive until satisfied; and (d) 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.
11.5 Survival. The Definitions, Fees (for accrued amounts), Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions articles survive termination.
Article 12: Dispute Resolution
12.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 13: General Provisions
13.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 11 before the amendment takes effect.
13.2 Notices. Legal notices under this document shall be sent to legal@aapawz.com. Operational notices 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.
13.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.
13.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.
13.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.
13.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.
13.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.
13.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.