Partner Security Requirements
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers and Partners whose applications store, process, or transmit Platform Data, including buyer personal data and seller business data.
Article 1: Introduction and Scope
1.1 This document states the minimum security requirements for Developer systems that store, process, or transmit Platform Data. Articles 3 through 7 bind every Developer. Article 8 binds Developers that handle buyer personal data. Article 9 binds high-volume Developers and Developers in the Elevated tier, as those tiers are stated in the API Access Tiers.
1.2 The Company's own safeguards for information the Company holds are governed by the Information Security Policy. Vulnerability reporting is governed by the Vulnerability Disclosure Policy, and notification of a Breach is governed by the Breach Notification Requirements; those documents control their subjects, and on an overlap the stricter rule applies.
1.3 If a provision of this document conflicts with the Terms of Use, this document controls for the subject it governs. If a provision of this document conflicts with the terms of a program in which the Developer participates, the program terms control for that program. Policies and help pages explain this document; they do not amend it, and in any conflict this document prevails.
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 Breach: unauthorized acquisition, access, use, or disclosure of Platform Data, or any compromise of a Developer system, credential, or integration that holds Platform Data, as further stated in the Breach Notification Requirements.
2.4 Company: All About Pawz, LLC, a Tennessee limited liability company.
2.5 Credential: an application programming interface key, token, password, signing secret, or other means of authentication issued to or held by the Developer.
2.6 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.7 Platform: the websites, applications, and services the Company operates under the name All About Pawz, including aapawz.com.
2.8 Platform Data: data obtained through the Platform, including data obtained through the application programming interface, webhooks, authorization grants, and the marketplace integration surface, and data derived from such data, including aggregates, enrichments, and cached copies. Deletion of a raw response while derived data is retained is not deletion of Platform Data.
Article 3: Transport and Network Security
3.1 The Developer shall use Transport Layer Security version 1.2 or higher on every connection the Application makes that carries Credentials, tokens, personal data, or order information, with no exception for a connection the Developer regards as internal that crosses a network boundary, and with no plaintext fallback. Installer-facing domains shall serve HTTPS exclusively and shall send HTTP Strict Transport Security headers.
3.2 The Developer shall not disable certificate validation in production code. A review finding of disabled certificate validation is an automatic security failure under the App Listing Standards.
3.3 A webhook receiver the Developer operates shall verify that a delivery originated with the Company, by signature verification on the signing secret, before the body of the delivery is processed for any effect, and shall process deliveries so that a redelivered event is never applied twice.
Article 4: Secrets Management
4.1 The Developer shall hold secrets in server-side environment configuration or a secret store and shall read secrets at runtime. Secrets shall not appear in source files, client software, published artifacts, or logs.
4.2 A credential that bypasses access controls entirely: one that can read and write without restriction: is the most sensitive secret in the Developer's estate. The Developer shall restrict such a credential to named server processes, shall never issue it to client software, and shall never commit it to a repository. A credential of that power found in client software is an automatic review failure under the App Listing Standards and cause for immediate suspension under Article 12.
4.3 No secret shall be hardcoded anywhere: not in source, not in committed configuration files, not in mobile application binaries, not in publicly shared collections of test requests, and not in error messages. Secrets used in build and deployment pipelines shall come from the pipeline's secret store, never from plaintext variables.
4.4 Credentials shall be rotatable without a code deployment: by environment or secret-store change only: and rotation shall actually be exercised; a key that has never been rotated since the Application launched is a review finding. A compromised or exposed Credential shall be rotated immediately, and the exposure shall be reported under the Breach Notification Requirements. Key management and rotation mechanics are governed by the API Key Management and Rotation.
Article 5: Session and Token Handling
5.1 Where the Developer interacts with Platform session flows, the Developer shall respect the properties of the Platform session credential: the Developer shall not attempt to read a session credential from client-side script, shall not transmit a session token to a third party, and shall not create a lookalike session credential capable of being confused with the Platform's authentication checks.
5.2 Authorization tokens shall be stored server-side, encrypted at rest, limited to the minimum grant the Application needs, and never logged. Refresh tokens shall be used only to obtain new access tokens; a refresh token shall not be sent to a browser, embedded in a uniform resource locator, or shared between applications.
5.3 The Developer shall honor the lifetimes the Company issues for tokens. The Developer shall not cache a token beyond its validity and shall not work around expiry by repeated re-authentication.
Article 6: Input Validation and Tenant Isolation
6.1 The Developer shall validate everything the Application sends to Platform routes: types, ranges, lengths, and formats: before the data leaves the Application. Platform validation is the last line of defense, not the Application's only one. Absence of input validation is an automatic review failure under the App Listing Standards.
6.2 A Developer system that stores Platform Data for multiple Installers shall segregate the data by tenant in storage, shall scope every query by tenant, and shall never trust a client-supplied tenant identifier. A request that identifies a tenant shall be checked against the authenticated identity's actual tenant, every time.
6.3 The Developer shall use parameterized queries or equivalent bindings throughout, and shall not use string-concatenated queries, unescaped interpolation into shell commands, or unescaped interpolation into template engines.
Article 7: Logging
7.1 The Developer shall log the security-relevant events: authentication successes and failures, key and token usage, data exports, administrative actions, and permission changes: each with a timestamp, in a tamper-evident store, retained for twelve (12) months.
7.2 Logs shall not contain secrets, tokens, passwords, full payment instrument numbers, or buyer personal data beyond what is strictly necessary for the event; an order identifier is permissible, and a buyer's full address in a log is not. Logging that records request bodies at a detailed level shall be off in production, or the bodies shall be redacted before the record is written.
7.3 Access to production logs is restricted to named staff with a business need, and access to logs is itself logged. A Developer that cannot state who read the Developer's production logs in the last ninety (90) days has a review finding.
Article 8: Developers Handling Buyer Personal Data
8.1 A Developer that stores buyer personal data shall: (a) segregate the data from other tenants' data under Article 6.2; (b) encrypt the data at rest with AES-256 or an equivalent standard, with keys managed in a key-management service rather than stored with the data; (c) encrypt backups to the same standard; (d) restrict production access to named staff with a documented business need; and (e) maintain an inventory of subprocessors with access to the data, and disclose the inventory to the Company on request within fifteen (15) days.
8.2 A Developer subject to this Article shall complete an annual self-assessment against this document and deliver it to the Company on request within thirty (30) days. The assessment shall be signed by a person with authority to bind the Developer. A false attestation is a material breach of this document and a conduct violation under the Partner Code of Conduct.
8.3 Within twelve (12) months of first holding more than ten thousand (10,000) buyer records, the Developer shall complete a SOC 2 Type I assessment, or an equivalent independent assessment, and share the report with the Company under a nondisclosure agreement. A SOC 2 Type II assessment is required for Developers in the Elevated tier. The ten thousand (10,000) record count is cumulative across tenants.
Article 9: Dependency and Patch Management
9.1 Dependencies shall be pinned with lockfiles, and builds shall be reproducible. A Developer that cannot rebuild the exact software under review from its lockfile has a review finding.
9.2 Vulnerability scanning shall run on every build or at least weekly against the dependency tree. Critical patches shall be applied within fourteen (14) days of release; patches for internet-facing components within seven (7) days; and a known-exploited vulnerability shall be patched on an emergency basis, measured in hours, not days.
9.3 Operating with a known unpatched critical vulnerability beyond the windows in Article 9.2 is a suspendable offense under Article 12. A plan to patch in a later development cycle is not a defense where the vulnerability is being exploited.
Article 10: Incident Readiness and Evidence
10.1 Every Developer shall maintain a named security contact, current in the developer portal, who is reachable for incident purposes. The contact shall reach a person with authority to make security decisions: to revoke keys, take systems offline, and authorize forensic investigation: within the notification windows the Breach Notification Requirements set. A contact that is unreachable, or that reaches a person who cannot act, is treated as no contact.
10.2 High-volume Developers and Developers in the Elevated tier shall additionally maintain a documented incident-response plan, tested at least annually, covering detection, containment, eradication, recovery, and notification under the Breach Notification Requirements.
10.3 The Company may require evidence of compliance with this document at any time, including the self-assessment under Article 8.2, attestation records, review findings, and audit records. The Developer shall produce the evidence within the period the Company's request states, which shall not be shorter than the periods stated in Articles 8.1(e) and 8.2 where those Articles apply. A suspected compromise of Platform Data triggers the Breach Notification Requirements immediately.
Article 11: Review Consequences
11.1 The following are automatic security failures on review, without a remediation window under the App Listing Standards: secrets or unrestricted credentials in client software or public artifacts; transmission of credentials or personal data without Transport Layer Security; secrets or buyer personal data in retained logs; and absence of input validation on Platform-bound writes.
11.2 The following findings carry a thirty (30) day remediation window, after which the Developer shall re-submit for security sign-off: dependency hygiene gaps, exceeded patch windows, a missing or unreachable incident contact, and an unsigned or stale self-assessment.
11.3 A security failure discovered in a listed Application after listing: through audit, incident, or report: is handled under Article 12. A critical finding, meaning active exposure of secrets or buyer data, results in immediate suspension pending remediation, and the listing does not return until security sign-off is earned again.
Article 12: Liability
12.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.
12.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).
12.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 owed for Orders, fees, chargebacks, or refunds under the Company's documents; or (d) liability that cannot be limited under applicable law.
12.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 13: Indemnification
13.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, services, listings, or 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 the Company's documents.
13.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.
13.3 Survival. This Article survives the termination of this document.
Article 14: Enforcement and Appeals
14.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.
14.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.
14.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 risk to the safety of a person or an animal, unlawful conduct, active exposure of secrets or buyer data, or a violation that by its nature cannot be cured.
14.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) remove or suppress a listing or content; (c) suspend the Developer's Credentials, Application, or program participation, in whole or in part, including immediate suspension for a critical security finding under Article 11.3 and for operation with a known unpatched critical vulnerability beyond the windows in Article 9.2; (d) terminate this document and the Account; and (e) exercise any other right or remedy available under this document or at law. Procedure for suspension, termination, and credential measures is governed by the Partner Suspension, Termination and Appeals.
14.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.
14.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 15: Term and Termination
15.1 Term. This document takes effect when the Developer is accepted into a developer or partner program and continues until terminated under this Article.
15.2 Termination by the Company. The Company may terminate this document and the Account 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.
15.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.
15.4 Effect of termination. On termination: (a) the rights granted under this document end; (b) obligations that arose before termination: including incident cooperation, 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.
15.5 Survival. The Definitions, Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions Articles survive termination.
Article 16: Dispute Resolution
16.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 17: General Provisions
17.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 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 15 before the amendment takes effect.
17.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.
17.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.
17.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.
17.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.
17.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.
17.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.
17.8 Interpretation. Headings are for convenience only. "Including" means "including without limitation." This document shall not be construed against a party as its drafter. The English-language text controls over any translation.