Partner Support and Incident Escalation Policy
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers and Partners who seek support from the Company, all publishers who owe support to their Installers, and the Company in handling support and incidents.
Article 1: Introduction and Scope
1.1 This Policy states support obligations in both directions: what the Company owes Developers and Partners, and what a publisher owes the publisher's Installers. This Policy controls support obligations for its subjects. This Policy does not change the Vulnerability Disclosure Policy, under which a vulnerability report goes through the channel that Policy states, or the Breach Notification Requirements, whose notification periods control a breach.
1.2 All support requests to the Company under this Policy are sent to support@aapawz.com, except an appeal and a legal notice, which are sent to legal@aapawz.com as the governing document provides.
1.3 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 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, including a publisher.
2.5 Incident: a degradation of a Platform service that is causing harm at the time of the report: the interface is unreachable, webhook deliveries have stopped, or payments are not settling. An Incident is handled by an incident commander, on a clock, with status updates.
2.6 Installer: a person or business that installs or subscribes to a Developer's Application through the App Marketplace.
2.7 Platform: the websites, applications, and services the Company operates under the name All About Pawz, including aapawz.com.
2.8 Severity: the classification of an Incident or a support matter under Article 4, set by impact.
2.9 Ticket: a request in the support queue: a question, a report of a defect, or a request for guidance. A Ticket is handled in order within its priority.
Article 3: Support the Company Owes
3.1 Support is provided by tier. A Developer in the Sandbox receives documentation and community support on a best-effort basis. A Developer in the Standard tier receives support through the support channel in Article 1.2, with a response within two (2) business days. A Developer in the Elevated tier receives a dedicated incident channel in addition, with the response periods in Article 4.3.
3.2 A response means a person acknowledges the Ticket and triage begins; a response is not a resolution. A resolution target is communicated per Ticket or per Incident once triage establishes the scope. An acknowledgment that states the Incident number and the time of the next update is a response.
3.3 Company support covers: questions on documented interface behavior; reports of defects against the documented routes; investigation of webhook delivery: whether the Company sent the delivery and what the endpoint answered; authentication and session issues; and Incident handling under Article 5. Company support does not cover: debugging the Developer's own application code; custom development; recovery of data the Developer was required to retain under the Data Use, Retention and Deletion; and incident response for the Developer's own infrastructure.
3.4 Every channel through which a Developer reports files into the same queue, with the channel recorded. A report does not fail because the report arrived through a different channel than the one Article 5 prescribes for its Severity; the report is reclassified and handled, and the misdirection is addressed under Article 4.4.
Article 4: Severity
4.1 Severity is set by impact, not by the volume of the report. The Company may reclassify a report upward or downward with a written reason. A reclassification is not appealable during the Incident; the classification is addressed in the post-incident review.
4.2 The four Severities are (a) Severity 1: the Platform is down or data is at risk: the production interface is broadly unreachable or returning server errors across the seller routes; the payment webhook intake is failing so that completed checkout events never apply and orders remain unpaid in the Platform while payment has moved at the processor; an active data breach; or the payment record silently diverging from the processor's record. The Incident clock starts at detection, and detection delay is part of the post-incident review.
(b) Severity 2: a major function is impaired and a workaround exists: a bulk endpoint returning server errors while single-record reads function; support intake slow while another intake channel files normally; or webhook deliveries delayed but retrying successfully, as the Webhook Obligations govern.
(c) Severity 3: a defect with a limited reach: incorrect values displayed to Buyers by reason of a defective data job, correctable without data loss; a minor display defect; a documentation error; or one Seller's session behaving abnormally. A correction is issued with a notice to affected Sellers; no incident commander is assigned.
(d) Severity 4: questions and requests, including feature requests and Sandbox irregularities that do not reproduce. Severity 4 matters are answered in the queue on a best-effort basis.
4.3 The Company shall respond within the following periods. The Sandbox is best effort at every Severity.
| Severity | Elevated tier | Standard tier |
|---|---|---|
| Severity 1 | One (1) hour | One (1) business day |
| Severity 2 | Four (4) hours | Two (2) business days |
| Severity 3 | One (1) business day | Three (3) business days |
| Severity 4 | Best effort | Best effort |
4.4 A Developer shall report a Severity 1 and a Severity 2 matter through the incident channel (Elevated tier) or through the support channel at urgent priority (Standard tier): not through a general queue: and shall designate an incident contact who is reachable for the Incident's duration. Reachable means the contact answers within the response period in Article 4.3 for the Severity. Where the Company cannot reach the Developer's contact within one (1) hour on a Severity 1 matter, the Incident record states the Developer as unreachable and the Company proceeds on the Company's own judgment. Mislabeling an Incident as a low-priority Ticket to avoid the Incident process is a violation of this Policy; filing a routine question at Severity 1 to advance in the queue is equally a violation.
4.5 A missed response period is recorded in the Incident record. The remedy for a missed period is automatic escalation under Article 5.4 and a written explanation; a missed period does not create a claim for damages or a credit, unless the Developer's Elevated tier agreement states otherwise.
Article 5: Ownership and Escalation
5.1 The Company owns: an outage on the Platform side, including unreachable routes and an unavailable database; a breach on the Platform side, whose notification periods the Breach Notification Requirements state; a payment failure in the Company's payment path, including payout delay; and a webhook delivery failure originating on the Platform side. Where the Company owns the Incident, the Company assigns its own responders, names an incident commander for a Severity 1 Incident, and the Developer's duties are to stay reachable and to take no action that interferes with the response.
5.2 The Developer owns: defects in the Developer's Application; a failure of the Developer's webhook endpoint, including the endpoint's own errors, an expired certificate, and a firewall rule: automatic disablement of an unresponsive endpoint under the Webhook Obligations is not a Company Incident; the Developer's users being confused by the Developer's own interface; and the Developer's infrastructure. Where the Developer owns the matter, Company support answers questions on interface behavior and stops there, as Article 3.3 states.
5.3 Where ownership is genuinely unclear, the question is decided by evidence, promptly: whether the Company sent the webhook, and whether the endpoint answered successfully within five (5) seconds, are determined from the delivery record; whether the Seller's data is incorrect in the Company's own administrative view determines a data question in the Company's favor until the contrary is shown. The party holding the evidence shall produce the evidence within the response period in Article 4.3. An undertaking to look into a matter, without a timestamp, is not evidence.
5.4 Escalation proceeds in stages: the support queue; specialist review, for the Elevated tier or any Ticket reclassified to Severity 2; and engineering on-call, for Severity 1 and Severity 2 matters in the Elevated tier. A Severity 1 Incident has an incident commander who owns the clock, the status updates, and the decision on when the Incident is mitigated. Escalation is automatic on a missed response period; no party is required to ask twice.
5.5 Particular cases are resolved as follows. (a) A matter filed at Severity 1 that proves to be the Developer's own defect: an expired certificate, for example: is reclassified, the reason is documented, and the explanation is given to the Developer's incident contact. (b) Concurrent Incidents each receive a separate commander and a separate record; Incidents are not merged because the Incidents occurred on the same day. (c) A fix for a Severity 1 or Severity 2 Incident ships through the emergency path regardless of a deployment freeze; a Severity 3 fix waits for the ordinary release schedule.
Article 6: The Publisher's Duties to Installers
6.1 First-line support is the publisher's duty. Under the App Marketplace Terms, the publisher is the seller of the Application: responsible for functionality, support, and refunds under the publisher's own published terms. An Installer with a defective Application contacts the publisher, not the Company. The Company does not triage a third-party Application's defects, does not answer questions on how to use a third-party Application, and redirects such reports to the publisher's published support contact.
6.2 Every marketplace Application shall publish a support contact and shall meet the following response periods, measured from the Installer's report, applying the Severity definitions in Article 4.2 to the publisher's own Application: Severity 1 (the Application is down or is losing the Installer's data): four (4) hours; Severity 2 (a major feature broken, with a workaround): one (1) business day; Severity 3 (a minor defect): three (3) business days.
6.3 The Company steps into a dispute between a publisher and an Installer only for a Platform-side cause: the interface the Application depends on is down, in which case the matter is a Company Incident under Article 5.1 and the publisher is one of the affected Developers; or the publisher has ceased to respond and Installers are stranded. Slow support by a publisher is not a Company Incident; slow support is a listing-quality matter under Article 6.4.
6.4 A sustained failure to meet Article 6.2: three (3) violations in ninety (90) days: is a listing-quality violation under the App Listing Standards and is enforced through the Partner Suspension, Termination and Appeals. An Installer who cannot reach a publisher's published contact at all may report the fact to the Company at support@aapawz.com as a listing complaint; the Company verifies the report and counts the verified report under this Article.
Article 7: Status Communication During Incidents
7.1 The Company maintains a public status page stating the health of the interface, webhook delivery, and the dashboards, with an Incident history. The Developer shall subscribe to status notifications for the services the Developer depends on; the duty to track notices under the Deprecation and Breaking Changes Policy applies equally here: failure to see a properly published notice is not a defense.
7.2 A Severity 1 and a Severity 2 Incident is posted to the status page within thirty (30) minutes of confirmation, stating what is affected, the workaround if one exists, and the time of the next update. A Severity 1 Incident is updated at least every sixty (60) minutes until mitigated; a Severity 2 Incident at least every four (4) hours. Mitigation means the harm has stopped; full resolution and the post-incident report follow on their own schedule, and the status page states which stage applies.
7.3 A post-incident report for a Severity 1 Incident is published within five (5) business days, stating what happened, the impact window, the class of root cause, and the preventive actions with owners and dates. A Severity 2 Incident receives a written summary to affected Developers on request. The report names the failure accurately; a release that broke signature verification is reported as a release that broke signature verification.
7.4 A Developer whose integration caused or amplified an Incident owes the Developer's own post-incident review within five (5) business days: the root cause, the remediation applied, and the evidence that the means of failure is closed: what changed, what was tested, and what would detect a recurrence: the same standard the Breach Notification Requirements set for a breach. Silence between the Incident and the review is itself a violation of this Policy.
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 Policy, even if the party has been advised of the possibility of those damages. A missed support response period does not give rise to damages beyond the remedy in Article 4.5.
8.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).
8.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.
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 Policy, including a failure to support Installers under Article 6; (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.
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 Policy.
Article 10: Enforcement and Appeals
10.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 support records for the Developer's Installers.
10.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.
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 fraud, a safety risk, unlawful conduct, or 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) remove or suppress a listing or content for a listing-quality violation under Article 6.4; (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. A Company failure to meet a response period in Article 4.3 is recorded in the Incident record and escalated under Article 5.4, and repeated failures are addressed at renewal of a tier agreement; a response failure is not a violation by the Developer and is never a ground for a Measure against the Developer.
10.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.
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 Policy takes effect when the Developer is accepted into a developer or partner program and continues until terminated under this Article.
11.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.
11.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 Incident or investigation outstanding in which the Developer bears a duty.
11.4 Effect of termination. On termination: (a) the rights granted under this Policy end; (b) obligations that arose before termination: including a post-incident review owed under Article 7.4, support duties to Installers for a period the Developer served, 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.
11.5 Survival. The Definitions, 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 Policy, or to the relationship it governs, is governed by the Dispute Resolution Policy, which is incorporated into this Policy by reference.
Article 13: General Provisions
13.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 11 before the amendment takes effect.
13.2 Notices. Legal notices and appeals under this Policy shall be sent to legal@aapawz.com. Support requests, Incident reports, and all other operational 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.
13.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.
13.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.
13.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.
13.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.
13.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.
13.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.