Integration Certification Policy
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers seeking or holding Certified Integration status for an Application built on the Platform's seller application programming interface.
Article 1: Introduction and Scope
1.1 This Policy governs certification of an integration: the criteria an Application shall meet, the testing the Developer shall perform and evidence, the review the Company conducts, the term of certified status, and the suspension and revocation of that status. Certification is a condition of the Certified tier benefit set stated in the API Access Tiers, and of any program that states certification as a condition.
1.2 Certification states that one Application passed the test suite for a stated set of categories at a stated time. Certification is not a license, is not an endorsement of the Developer or of the Developer's business, and is not a warranty by the Company of the Application. Certification grants no route, data, or limit beyond the Developer's tier. A Developer shall not represent certification as an endorsement, and the badge rules in Article 8 state the only permitted representation.
1.3 Certification is granted per category. The categories follow the surfaces of the seller interface: orders, products, returns, shipping, support, and read-only. An Application certified for orders and products is not certified for returns until the returns checks are passed. The badge shall name the certified categories; claiming a category not passed is deceptive conduct under the Partner Code of Conduct.
1.4 Certification does not change what the interface permits an Application to do. Access controls bind a certified Application to the Seller whose identity the Application acts for, on every request, exactly as they bind an uncertified Application.
1.5 If a provision of this Policy conflicts with the Terms of Use, this Policy controls for the subject it governs. The Developer Brand and Trademark Use Policy controls the visual form of the certification mark; this Policy controls whether the mark may be claimed. If a provision of this Policy conflicts with the terms of a program in which the Developer participates, the program terms control for that program.
Article 2: Definitions
2.1 Account: the account a person or business establishes with the Company to use the Platform.
2.2 Application: a software application, integration, or service the Developer offers through the Platform or the App Marketplace.
2.3 Certified Integration: an Application that has passed the category test suite under Article 4 and holds current certified status under Article 7.
2.4 Company: All About Pawz, LLC, a Tennessee limited liability company.
2.5 Developer: a person or business the Company has accepted to build on the Platform's application programming interface or to participate in a partner program.
2.6 Platform: the websites, applications, and services the Company operates under the name All About Pawz, including aapawz.com.
Article 3: The Certification Criteria
3.1 Session authentication. The Application shall handle session authentication as the Company issues it: (a) one session per Seller identity: sessions are never shared, pooled, or transferred between Sellers; (b) the session credential is stored server-side, encrypted at rest, and never placed in client software or logs, as the Partner Security Requirements require; (c) on an authentication failure response, the Application re-authenticates once, retries once, and then surfaces the failure; and (d) a session expiry during a job resumes the job from the last acknowledged record rather than restarting the job.
3.2 Tenant and Seller scoping. Every call shall stay inside the authorized tenant and the bound Seller. On startup, the Application shall confirm the identity it acts for against the Company's record of that identity, and shall refuse to run on a mismatch.
3.3 Idempotent writes. The Developer owns duplicate-safety for writes: (a) no blind retry of a submission: a network failure after a submission is followed by a reconciliation read before any resubmission; (b) a duplicate-safe design, with Developer-generated idempotency tokens held on the Developer's side and retries bounded with backoff; and (c) bulk operations verify the counts the Platform returns instead of assuming success.
3.4 Rate behavior. On a rate-limit response, the Application shall honor the retry interval the Platform states and shall retry with exponential backoff and variation, never with an immediate repeated retry. Sustained rate-limit responses above five percent (5%) of traffic over twenty-four (24) hours are evidence of a defective integration under the API Rate Limits and Quotas and are a certification failure. Certification accepts code evidence plus observed behavior, from records showing the Application stays inside the tier's rolling sixty (60) second windows.
3.5 Webhook signature verification. The Application's endpoints shall: (a) verify the signature on every inbound delivery, computed over the raw body of the delivery, reject a timestamp older than five (5) minutes, and never process an unverified payload; (b) for any payment-processor receiving endpoint the Developer operates, verify the delivery against the processor's signature on the raw, unparsed body, answer an invalid signature with a rejection, and reject a delivery where the signature or the secret is missing in production: an unverified fallback reachable in production code is an automatic certification failure; and (c) process a redelivered event exactly once, by detecting duplication on the event identifier. An endpoint shall answer a delivery within five (5) seconds.
3.6 Data duties. The Application shall request only the data classes its category needs, as the Data Use, Retention and Deletion governs. The Developer shall publish a retention statement: what is kept, how long, and when the data is deleted. On termination, the deletion and certification periods in that Policy and in the Partner Suspension, Termination and Appeals apply.
3.7 Security baseline. The Application shall meet the Partner Security Requirements: encryption in transit at Transport Layer Security version 1.2 or higher; AES-256 or equivalent encryption at rest for credentials and personal data; no hardcoded secrets in source, client software, or published artifacts; and logging of authentication events, key usage, data exports, and administrative actions, with timestamps, retained twelve (12) months. A Developer handling buyer personal data shall additionally meet the segregation and subprocessor-inventory duties in that document. A known unpatched critical vulnerability past the patch windows in that document is an automatic certification failure.
Article 4: The Self-Test Plan
4.1 Before submission, the Developer shall run every check in this Article for each category claimed. The evidence for each check is a dated record: request, response, and conclusion: which the Company's reviewers re-run on a sample.
4.2 Authentication checks. (a) A call with no session credential returns an authentication failure, and the Application treats the failure as: re-authenticate once, retry once, then surface the error. (b) A call with a tampered or expired credential returns the same failure, and the recovery shows the loop guard in code. (c) A design review shows one session per Seller, never pooled, shared, or transferred, with a test showing one Seller's job cannot retrieve another Seller's session. (d) A session expired during synchronization shows the job re-authenticating and resuming from the last acknowledged record.
4.3 Scoping checks. (a) With one Seller's session, a request for an order belonging to another Seller returns no access to that Seller's data, and no field of the other Seller's data is disclosed. (b) A bulk submission mixing the Application's own order identifiers with another Seller's leaves the other Seller's records untouched, and the returned count reflects only the Application's own records. (c) On startup, the Application confirms its acting identity and halts before any data call on a mismatch.
4.4 Idempotency checks. (a) The same submission made twice does not apply twice; the second call reports no change and the final state is identical. (b) After a simulated network failure following a submission, the retry path reconciles by reading before resubmitting, and resubmits only where the write is confirmed absent. (c) A follow-up on an existing support matter appends to the existing record rather than opening a duplicate.
4.5 Rate checks. (a) On a simulated rate-limit response, the Application reads the stated retry interval, waits the full interval, and retries with exponential backoff and variation, with no immediate second retry. (b) Records of the heaviest realistic workload, run for twenty-four (24) hours or shown from equivalent records, keep rate-limit responses below five percent (5%) of traffic, and name the tier whose limits the workload targets. (c) Bulk endpoints are used in preference to per-record loops, and every polling interval is documented with its justification.
4.6 Webhook checks. (a) A test delivery is verified by signature over the raw body with a timestamp inside five (5) minutes; a tampered body and an expired timestamp are rejected, and an unverified payload is never processed. (b) A payment-processor endpoint shows signature verification on the raw body, a rejection on an invalid signature, and rejection where the signature or secret is missing in production, with the handler code showing no unverified fallback in the production path. (c) The same event delivered twice is processed exactly once. (d) Acknowledgment time is measured at five (5) seconds or less.
4.7 Data and security checks. (a) Every data class requested is listed against the category's need, and any unjustified class is removed. (b) The retention statement is published. (c) Encryption in transit and at rest is shown. (d) The repository and published artifacts are searched for hardcoded secrets, and the clean result and the secret-management method in use are shown. (e) The audit record shows authentication events, key usage, data exports, and administrative actions, with timestamps and twelve (12) month retention.
4.8 Reviewers probe edge cases, including: a session expiring between a reconciliation read and a resubmission; a Seller profile unlinked during an operation, to which the Platform answers with an authorization failure and at which the Application shall stop and alert rather than retry; a webhook redelivery arriving after the Application already acted; and a category the Application calls but never tested, which is an automatic failure under Article 1.3.
Article 5: Submission
5.1 A submission is one Application, one category set, and one packet containing: (a) the Application's identity and the Developer account; (b) the categories claimed; (c) an architecture description and data-flow description showing every Platform call, every stored data class, and every webhook endpoint; (d) the session and authentication handling description under Article 3.1; (e) the self-test record for every check in Article 4, marked pass or fail, with evidence; (f) the security self-assessment under the Partner Security Requirements; (g) the retention statement under the Data Use, Retention and Deletion; and (h) a named incident contact reachable during Platform incidents, as the Partner Support and Incident Escalation Policy provides.
5.2 A failure recorded in the self-test record is not disqualifying: a documented failure with a remediation plan is weighed more favorably than a claimed pass. A claimed pass the reviewers cannot reproduce is treated as a failed submission.
Article 6: Review
6.1 Review combines automated and human passes. The automated pass replays the webhook and authentication checks against the submission's endpoints where reachable, examines the submitted webhook-handler and retry code, and verifies that badge-claim language in the Application's materials matches the categories submitted. In the human pass, a reviewer tests the architecture description against the self-test record, re-runs a sample of the checks, and probes the edge cases in Article 4.8.
6.2 The Company shall complete review within fifteen (15) business days of a complete submission, including a live demonstration where the reviewer observes the checks in Article 4 run. An incomplete submission is returned with a list of what is missing; the fifteen (15) business day period starts when the complete packet is received.
Article 7: Pass, Failure, and Term
7.1 A pass requires every mandatory check to pass for each claimed category: authentication, scoping, idempotency, rate behavior, webhooks, data duties, and security. An advisory finding shall be acknowledged in writing with a remediation date; an unacknowledged advisory finding blocks the pass.
7.2 The following are automatic failures without cure, with resubmission permitted after ninety (90) days: a scoping check showing cross-Seller or cross-tenant data access; a hardcoded Platform credential in submitted materials; an unverified webhook fallback reachable in the production path; and a falsified self-test record.
7.3 An ordinary failure carries thirty (30) days to remediate and resubmit, addressing every finding in writing. Two failures within twelve (12) months impose a six (6) month wait before the next submission.
7.4 A pass grants certified status for twelve (12) months from the grant date.
Article 8: The Certification Mark
8.1 A Certified Integration may display the certification mark in the exact form issued: "Pawz Shop Certified Integration," with the certified categories and the grant year. The mark links to the Application's directory listing.
8.2 The mark is a statement of test status and nothing more. The mark shall not be combined with "official," "endorsed by," "partner of," or any language suggesting the Company built, warrants, or recommends the Application. Absence of certification is equally not a statement by the Company about an Application: an uncertified Application is untested under this Policy, not condemned by it. The visual form of the mark is governed by the Developer Brand and Trademark Use Policy.
8.3 The mark shall come down within five (5) business days of suspension, revocation, downgrade, or expiry of certified status. Display of an unearned or expired mark is deceptive conduct under the Partner Code of Conduct and a listing violation under the App Listing Standards.
Article 9: Re-Certification
9.1 Re-certification is required: (a) every twelve (12) months: status lapses automatically at expiry; (b) when a Breaking Change under the Deprecation and Breaking Changes Policy affects any route the integration calls: certified Developers receive notice of a category-relevant Breaking Change thirty (30) days before the general announcement where feasible, and re-certification shall complete before the earlier element's sunset date; and (c) when the Developer makes a material architecture change, including new data classes handled, a new authentication model, new hosting or subprocessors, or a new category of Platform routes called.
9.2 Re-certification is a review of the change: the checks in Article 4 affected by the change, plus the scoping and webhook checks in full every time. Scoping and signature verification are never waived as unchanged.
9.3 An emergency change under the Deprecation and Breaking Changes Policy compresses the re-certification window to the notice period for that change. An integration that cannot re-certify in time is suspended from the affected category until re-certification completes.
Article 10: Suspension and Revocation of Certified Status
10.1 Certified status is suspended for: (a) sustained health failures: error rates above the category standard for thirty (30) days trigger a remediation notice, and sixty (60) days without remediation suspends status; (b) an unresolved security finding past the remediation window in the Partner Security Requirements; (c) a data-duty violation under the Data Use, Retention and Deletion; and (d) failure to re-certify under Article 9.
10.2 On suspension, the mark and the directory listing are removed within five (5) business days. The Developer retains portal access to remediate and to appeal under Article 13.
10.3 Revocation of certified status for cause follows the Partner Suspension, Termination and Appeals: a ten (10) day cure for a remediable violation, and immediate action without cure for conduct on the immediate track stated in that Policy. Decertification ends the right to display the mark under Article 8.3 and ends any program benefit conditioned on certification; decertification alone does not terminate the Developer's account, which only a measure under that Policy effects.
Article 11: Liability
11.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 Policy, even if the party has been advised of the possibility of those damages.
11.2 Cap. To the fullest extent permitted by law, the Company's total liability arising out of or relating to this Policy shall not exceed the greater of (a) the amounts the Developer paid to the Company under this Policy in the twelve months before the event giving rise to the claim, or (b) one hundred dollars ($100).
11.3 Carve-outs. This Article does not limit (a) a party's indemnification obligations under this Policy; (b) liability for fraud or willful misconduct; (c) amounts owed for Orders, fees, chargebacks, or refunds under the Company's documents; or (d) liability that cannot be limited under applicable law.
11.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 12: Indemnification
12.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 Policy; (b) the Developer's Applications, services, listings, or content, including a claim that certification warranted the Application; (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 the Company's documents.
12.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.
12.3 Survival. This Article survives the termination of this Policy.
Article 13: Enforcement and Appeals
13.1 Investigation. The Company may investigate any suspected violation of this Policy. The Developer shall cooperate with an investigation and shall produce the records this Policy requires the Developer to keep, including the self-test record and the integration health records for the Application.
13.2 Notice. If the Company determines that the Developer has violated this Policy, 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.
13.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 fraud, a falsified self-test record, a safety risk, unlawful conduct, or a violation that by its nature cannot be cured.
13.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 certified status under Article 10; (c) remove or suppress a listing or content; (d) suspend the Developer's credentials or program participation, in whole or in part; (e) terminate this Policy and the Account; and (f) exercise any other right or remedy available under this Policy or at law. Procedure for suspension, termination, and credential measures is governed by the Partner Suspension, Termination and Appeals.
13.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.
13.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 14: Term and Termination
14.1 Term. This Policy takes effect when the Developer first seeks certification and continues until terminated under this Article. Certified status itself runs for the term stated in Article 7.4.
14.2 Termination by the Company. The Company may terminate this Policy and the Account on thirty (30) days' written notice for any reason, and immediately on written notice if the Developer materially breaches this Policy, engages in fraud, or becomes ineligible to participate.
14.3 Termination by the Developer. The Developer may terminate this Policy on thirty (30) days' written notice to support@aapawz.com, provided the Developer has no investigation outstanding. Withdrawal from certification ends the right to display the mark on the effective date of withdrawal.
14.4 Effect of termination. On termination: (a) the rights granted under this Policy end, including display of the mark; (b) obligations that arose before termination: including record-keeping and indemnification obligations: survive until satisfied; and (c) the Company shall disburse amounts owed, less amounts the Company may set off under the Company's documents, within thirty (30) days, except amounts held in connection with an open investigation or dispute.
14.5 Survival. The Definitions, Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions Articles survive termination.
Article 15: Dispute Resolution
15.1 Any dispute arising out of or relating to this Policy, or to the relationship it governs, is governed by the Dispute Resolution Policy, which is incorporated into this Policy by reference.
Article 16: General Provisions
16.1 Amendments. The Company may amend this Policy by posting the amended Policy 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 obligations takes effect thirty (30) days after notice; other amendments take effect on posting. Continued participation 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 14 before the amendment takes effect.
16.2 Notices. Legal notices under this Policy 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.
16.3 Governing law. This Policy 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 Policy shall be brought in the state or federal courts located in Shelby County, Tennessee, and the parties consent to personal jurisdiction there.
16.4 Severability. If any provision of this Policy is held unenforceable, the provision shall be enforced to the fullest extent permitted, and the remaining provisions continue in full effect.
16.5 Entire agreement. This Policy, 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.
16.6 Assignment. The Developer shall not assign this Policy 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 Policy to an affiliate or in connection with a sale of all or part of its business, on notice to the Developer.
16.7 Waiver. A waiver of any provision of this Policy is effective only in writing and only for the instance stated. No waiver is a waiver of any other provision or instance.
16.8 Interpretation. Headings are for convenience only. "Including" means "including without limitation." This Policy shall not be construed against a party as its drafter. The English-language text controls over any translation.