Sandbox Acceptable Use Policy
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers building and testing against the Sandbox environment.
Article 1: Introduction and Scope
1.1 This Policy governs use of the Sandbox: what the Sandbox is for, what data may enter it, the conduct rules that apply inside it, and the path from Sandbox work to production access. This Policy controls Sandbox use; on a conflict with the Developer Agreement as to the Sandbox, this Policy controls.
1.2 The Sandbox is a functionally complete, data-isolated copy of the Platform surface: the same interface routes, the same webhook mechanics, the same integration contracts: operating against synthetic data, inside its own tenant boundary, with no path to production data or production money. The Sandbox exists for four purposes: development, integration testing, certification under the Integration Certification Policy, and application review under the OAuth App Registration and Review and the App Listing Standards. The Sandbox is not a second production environment, not a staging area for real traffic, and not a free tier for serving users.
1.3 Isolation is structural. Sandbox credentials are rejected by production routes, and production tenant identifiers resolve to nothing inside the Sandbox. A Developer holding both sets of credentials shall treat the two environments as separate in all respects.
1.4 Every new Developer starts in the Sandbox, as the API Access Tiers provide. Production access requires approval at the Standard tier after identity verification and use-case review. Conduct in the Sandbox: rate discipline, data hygiene, and respect for boundaries: is evidence in the production review.
1.5 If a provision of this Policy conflicts with the Terms of Use, this Policy controls for the subject it governs. 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. Policies and help pages explain this Policy; they do not amend it, and in any conflict this Policy 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 builds or offers through the Platform or the App Marketplace.
2.3 Company: All About Pawz, LLC, a Tennessee limited liability company.
2.4 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.5 Platform: the websites, applications, and services the Company operates under the name All About Pawz, including aapawz.com.
2.6 Sandbox: the Company's data-isolated test environment described in Article 1.2.
2.7 Test Data: synthetic data, including the fixtures the Company provides and data a Developer creates inside the Sandbox for testing, that identifies no real person and settles no real transaction.
Article 3: Test Data Only
3.1 Only Test Data may enter the Sandbox. The Developer shall not load into the Sandbox: real buyer personal information; real payment instruments; real Seller credentials; production database copies; or real records of any kind, including a small number of real records introduced to make testing realistic. The Company provides synthetic fixtures: fictitious buyers, sellers, and orders in realistic forms: and the Developer shall use them.
3.2 Sandbox payment flows run in the payment processor's test mode only. The Developer shall not make a real charge, a real payout, or a connection to a real bank account through the Sandbox. Validation of a production money path occurs in production under the production review, not by introducing a live credential into the Sandbox.
3.3 Data loaded into the Sandbox in breach of Article 3.1 does not acquire a lesser status by being in the Sandbox. Real personal data wrongly loaded into the Sandbox is governed in full by the Data Use, Retention and Deletion, and a compromise of such data is governed in full by the Breach Notification Requirements.
3.4 A Developer that discovers another tenant's data inside the Developer's Sandbox workspace: fixture leakage or cross-tenant test data: shall report the discovery under the Vulnerability Disclosure Policy and shall delete the data. Retention, exploration, or use of such data is a violation of the Scraping Prohibition even though the data is synthetic.
Article 4: Resets and Retention of Sandbox Data
4.1 Data a Developer places in the Sandbox is test data with no durability commitment. The Company may reset, wipe, or regenerate Sandbox data at any time, without notice and without liability, including on a schedule, on a fixture refresh, or as an emergency measure after abuse. Loss of Sandbox data is a fact of the program and is not a support matter.
4.2 The Developer shall keep the Developer's own copies of test scenarios and setup scripts. An integration that cannot be re-established from the Developer's own materials after a reset has not been built to the standard this Policy assumes.
4.3 An inactive Sandbox workspace is wiped after ninety (90) days without interface activity, and a full fixture refresh may accompany any Platform release. The Company gives notice of an inactivity wipe to the Developer contact on file fourteen (14) days before the wipe. Data that is Test Data never becomes subject to the production deletion-certification duties in the Data Use, Retention and Deletion; data wrongly loaded that is real personal data is governed by Article 3.3.
Article 5: Load and Conduct Rules
5.1 Sandbox rate limits apply as specified in the API Rate Limits and Quotas: sixty (60) requests per minute, within a monthly Sandbox quota of one hundred thousand (100,000) calls. The limits exist so that one Developer's testing does not become every Developer's outage.
5.2 Load and stress testing require the Company's prior written approval. A request shall be made at least ten (10) business days in advance and shall state the expected volumes, the duration, and the endpoints under test. An approved load test runs in a scheduled window with Company monitoring. Unapproved load testing is treated as a denial-of-service attempt, which the Vulnerability Disclosure Policy excludes from authorized research entirely.
5.3 Automated scanning of the Developer's own integration is permitted within the limits in Article 5.1, as the Vulnerability Disclosure Policy provides. Scanning beyond the Developer's own surfaces, or at rates that degrade the shared environment, is not authorized for the excess traffic.
5.4 Vulnerability research in the Sandbox follows the bounds of the Vulnerability Disclosure Policy exactly. The Sandbox is the proper place to test a suspected vulnerability against the Developer's own account; the Sandbox is not permission to probe another Developer's Sandbox workspace. Tenant isolation applies between Sandbox workspaces with the same force as in production.
Article 6: Prohibited Uses
6.1 The following are prohibited in the Sandbox, without exception: (a) serving production traffic from Sandbox credentials or endpoints, because the Sandbox is not a free production tier; (b) seeding production data into the Sandbox, including an export described as anonymized that can be re-identified; (c) phishing tests, social-engineering tests, or any deception directed at real users, including a test of a notification flow directed at real recipients: the flow is tested against fixtures; (d) cryptocurrency mining or any computing use unrelated to integration development; (e) use of the Sandbox to evade production rate limits, quotas, or fees, including shaping traffic across environments to avoid billing under the API Monetization and Usage Fees Policy; (f) operating a public-facing service on Sandbox credentials, including demonstrations for the Developer's own customers; and (g) testing credential-stuffing, password-spraying, or session attacks against any account the Developer does not own.
6.2 Conduct that is plainly abusive: origination of spam, hosting of malicious software, and command-and-control use: is prohibited without need of a specific clause. Conduct that ends a Developer relationship in production ends Sandbox access, ordinarily faster, because no legitimate production need weighs against the measure.
Article 7: Promotion to Production
7.1 Promotion is a gate, not a gradient. Sandbox work becomes production-capable only through: (a) passing certification where the integration class requires it, under the Integration Certification Policy, or application review where listing requires it, under the OAuth App Registration and Review and the App Listing Standards; (b) approval at the Standard tier under the API Access Tiers, with identity verified and the use case reviewed; (c) issuance of production keys under the API Key Management and Rotation; and (d) re-registration of webhook endpoints for production under the Webhook Obligations: Sandbox subscriptions do not carry over, and production payload versions are set per subscription at registration.
7.2 Configuration does not move with promotion. The Developer shall re-verify in production: granted scopes, including fresh end-user consent where a scope is enlarged; redirect addresses; webhook signing secrets; and the data-retention statement required by the Data Use, Retention and Deletion.
7.3 The production review may impose conditions drawn from Sandbox behavior, including tighter rate limits for an integration that exceeded Sandbox limits, additional logging for an integration that handled fixtures carelessly, and delayed approval for an integration with abuse findings. Sandbox usage records are evidence in the review.
7.4 The Company may move a Developer to Sandbox-only access as an enforcement action under the API Access Tiers or for non-payment under the API Monetization and Usage Fees Policy. Reinstatement to production follows the procedure in the Partner Suspension, Termination and Appeals, not a new application.
Article 8: Particular Cases
8.1 Where synthetic fixtures cannot represent a production scenario the Developer must handle, the Developer shall request a fixture extension through support@aapawz.com: not a production data exception. The Company maintains the fixture set as a continuing obligation; repeated gaps in one area are a Company defect, not a ground for a Developer exception.
8.2 Where a team shares one Sandbox workspace, the workspace owner is responsible for every key issued under the workspace. Responsibility for a contractor's act rests with the owner as against the Company; allocation of that responsibility within the team is the team's matter.
8.3 Where certification under the Integration Certification Policy requires re-testing after a Platform change, the Sandbox fixtures are versioned alongside the change under the Deprecation and Breaking Changes Policy.
8.4 A security incident confined to the Sandbox: synthetic data only, with no production involvement: is handled under the Vulnerability Disclosure Policy, not under the twenty-four (24) hour breach rule in the Breach Notification Requirements, because no personal data was at risk. The moment the Developer cannot be certain the incident stayed inside the Sandbox, the Breach Notification Requirements apply in full. Uncertainty resolves toward notification.
Article 9: Isolation Failures
9.1 An isolation failure is the Company's responsibility. If a Developer demonstrates that Sandbox credentials reached production data, or production credentials reached Sandbox data, through no misconfiguration of the Developer's own, the Company treats the event as a Company security incident: immediate containment, notice to affected Developers, and remediation on the timelines in the Vulnerability Disclosure Policy. A Developer that reports an isolation failure in good faith is protected under the safe harbor in that Policy.
Article 10: Liability
10.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. Loss of Sandbox data on a reset under Article 4.1 is not a liability of the Company.
10.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).
10.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.
10.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 11: Indemnification
11.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; (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.
11.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.
11.3 Survival. This Article survives the termination of this Policy.
Article 12: Enforcement and Appeals
12.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.
12.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.
12.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 safety risk, unlawful conduct, or a violation that by its nature cannot be cured.
12.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 Sandbox access, as the least measure that stops the misuse: production access is unaffected by a Sandbox-only suspension unless the conduct indicates production risk, in which case the Company may act on both; (c) suspend the Developer's credentials or program participation, in whole or in part; (d) terminate this Policy and the Account; and (e) exercise any other right or remedy available under this Policy or at law. Procedure is governed by the Partner Suspension, Termination and Appeals.
12.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.
12.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 13: Term and Termination
13.1 Term. This Policy takes effect when the Developer is granted Sandbox access and continues until terminated under this Article.
13.2 Termination by the Company. The Company may terminate this Policy and Sandbox access 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.
13.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.
13.4 Effect of termination. On termination: (a) Sandbox access and Sandbox credentials end; (b) Sandbox data is deleted without the certification duties that apply to production data, except data governed by Article 3.3; and (c) obligations that arose before termination: including indemnification obligations: survive until satisfied.
13.5 Survival. The Definitions, Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions Articles survive termination.
Article 14: Dispute Resolution
14.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 15: General Provisions
15.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 use of the Sandbox 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 13 before the amendment takes effect.
15.2 Notices. Legal notices under this Policy shall be sent to legal@aapawz.com. Operational notices, fixture requests under Article 8.1, 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.
15.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.
15.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.
15.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.
15.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.
15.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.
15.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.