Deprecation and Breaking Changes Policy
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers building integrations against the Platform's application programming interface, webhooks, software development kits, and data formats, and to the Company in making changes to them.
Article 1: Introduction and Scope
1.1 This Policy governs changes to the application programming interface, webhooks, software development kits, and data formats of the Platform. The Policy binds both parties: the Company owes the notice periods, version support, and migration support stated in Articles 3 through 5, and the Developer owes the tracking and migration duties stated in Article 6.
1.2 This Policy controls all change communication for the subjects it governs. On a conflict with the change right stated in the Developer Agreement, the notice periods in this Policy control.
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 Breaking Change: a change that can cause a conforming integration to fail, including removing an endpoint or a field; changing a field's type, format, or meaning; tightening validation so that previously accepted input is rejected; changing authentication requirements; altering a webhook payload structure; or changing behavior the documentation promised. If a Developer that followed the documentation could see the Developer's integration break, the change is breaking.
2.3 Company: All About Pawz, LLC, a Tennessee limited liability company.
2.4 Deprecation: the marking of an element as superseded while the element continues to function. A Deprecation is a commitment: the element functions until the published removal date, and removal follows the notice tiers in Article 3. A deprecated element that stops working before its removal date is a breach of this Policy by the Company, not a migration failure by the Developer.
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 Non-Breaking Change: a purely additive change: a new endpoint, a new optional field, a new webhook event type, or a new enumeration value added alongside existing values. A Non-Breaking Change requires no notice; a material addition is announced in the changelog.
2.7 Platform: the websites, applications, and services the Company operates under the name All About Pawz, including aapawz.com.
2.8 Sunset Date: the published date on which a deprecated element or version is removed.
Article 3: Notice Tiers
3.1 Tier 1: twelve (12) months. The Company shall give twelve (12) months' notice, from announcement to removal, for: removing an endpoint; removing a field; changing a field's type or meaning; changing authentication; sunsetting an application programming interface version; and removing a webhook event type.
3.2 Tier 2: six (6) months. The Company shall give six (6) months' notice before removal begins for: deprecating an element that keeps functioning under Article 2.4; restructuring a webhook payload where the Developer must opt in to the new payload version, as governed by the Webhook Obligations; and major-version transitions of a software development kit, as governed by the SDK License Terms.
3.3 Tier 3: three (3) months. The Company shall give three (3) months' notice for a behavior change with a limited reach that the documentation did not reserve, including tightened validation, altered defaults, changed pagination meaning, and a reduced rate limit beyond a documented warning. That a change still returns a success response does not make the change non-breaking.
3.4 Emergency changes. Where an active security vulnerability, a legal compulsion, or a data-integrity emergency requires it, the Company may act immediately and shall publish a retrospective notice within seven (7) days, documenting what changed, why delay would have caused harm, and what Developers shall do. Emergency action is the exception; a pattern of emergencies is a breach of this Policy by the Company.
3.5 Borderline cases are settled as follows. Changing the human-readable text of an error message is non-breaking; changing an error code that Developers are instructed to branch on is breaking. Tightening a rate limit is non-breaking only if the documented limits already warned that the limit could tighten; otherwise the tightening is a Tier 3 behavior change. Returning fields in a different order is non-breaking; an integration shall not depend on the order of fields in a response.
3.6 Form of notice. Every change is published in the versioned changelog with what changed, why, the migration path, the announcement date, and the removal date. A deprecated element in a live response carries a deprecation indicator and the Sunset Date. Tier 1 and Tier 2 announcements are additionally sent to affected Developers by email and by developer-portal notice. A changelog entry without a removal date is not notice.
Article 4: Classification of Changes
4.1 Breaking Changes include: (a) removal of a field from any response or webhook payload; (b) a type change, including a string becoming an integer, a timestamp changing format, or a field that permitted an empty value ceasing to permit one; (c) a meaning change, where a field keeps its name and type but means something different, including an enumeration value that reorders existing meanings; (d) an authentication change, including a new required credential, a retired grant type, or an altered session lifetime; (e) a behavior change, where an endpoint that accepted an input now rejects it or a documented default changes; and (f) a webhook payload restructuring that breaks signature verification or parsing.
4.2 Non-Breaking Changes include: (a) new endpoints, new optional fields, and new event types; (b) new enumeration values added without reordering; (c) performance changes within documented timeouts; (d) additional validation that rejects only input the documentation already forbade; and (e) correction of a defect where the prior behavior contradicted the documentation: with the qualification that if Developers widely depended on the defective behavior, the Company treats the correction as a Tier 3 change.
4.3 Webhook payloads are versioned per subscription under the Webhook Obligations. A payload version upgrade requires the Developer's opt-in, except under Article 3.4. The Company shall not move a subscription to a new payload shape without the Developer's action; a subscription holds the version it was created against until the Developer moves it.
Article 5: Version Support and Sunset
5.1 The application programming interface is versioned. A new version never force-migrates an existing integration: versions coexist for at least the Tier 1 notice period, and an earlier version is removed only through the sunset procedure in Article 5.2. An integration held on an earlier version keeps working on that version until that version's published Sunset Date, regardless of what a later version introduces.
5.2 The sunset procedure is: (a) announcement with the removal date, published under Article 3.6; (b) deprecation indicators on the earlier version's responses from announcement; (c) a migration guide published at announcement, not at removal; and (d) at the removal date, removal of the version, under which requests to the removed version return a "410 Gone" response with a machine-readable pointer to the migration guide. The earlier version functions in full until the Sunset Date; there is no stage at which the version functions in part.
5.3 A migration guide is the Company's obligation for every Tier 1 and Tier 2 change, published at announcement. A complete guide contains: the earlier and later request and response forms side by side; the field mapping; the behavioral differences; a checklist for the Developer's own testing; and a contact for migration questions. A changelog entry that directs Developers to a new version without this content does not satisfy the obligation.
5.4 By way of illustration of Articles 3 through 5: removal of a field from an orders response is a Tier 1 change. At announcement, the changelog states the field, the route, the reason, the replacement form with a complete example, the migration guide, the announcement date, and a removal date exactly twelve (12) months later, and notice is sent to every Developer whose keys called the route in the last ninety (90) days. During the notice period both the deprecated field and its replacement are returned, with deprecation indicators. At month nine, a reminder is sent to Developers still reading the deprecated field, naming the Application and the removal date. At month twelve the field is removed; requests do not fail for the removal, because field removal affects parsing, not routing. The migration guide remains published for a further twelve (12) months.
Article 6: The Developer's Duties
6.1 The Developer shall subscribe to the changelog and to status notifications, as the Partner Support and Incident Escalation Policy provides. Failure to see a notice is not a defense where notice was properly published under Article 3.6: the Company's duty is to publish correctly; the Developer's duty is to read.
6.2 The Developer shall migrate off a deprecated element before its Sunset Date. After the Sunset Date, a request to a removed endpoint returns a "410 Gone" response and a removed field is simply absent. Neither event is a Company incident, and neither is reported as one.
6.3 An Application held on a sunset version functions until the Sunset Date and not beyond. Operation past end-of-life is at the Developer's risk: the Company may disable an end-of-life version, and no grace traffic is owed. Holding a version buys stability during the notice period; holding a version does not buy continued operation after it.
6.4 Failure to migrate carries no penalty beyond the technical consequence. Late migration is not a violation of the Partner Suspension, Termination and Appeals, is not a ground for a tier change, and is not held against the Developer in any review. The Company's remedy for an unmigrated integration is removal of the element at the Sunset Date, not punishment.
Article 7: Company Shortfalls
7.1 Failure by the Company to give the notice an Article requires extends the element's life by the shortfall automatically: a Tier 1 removal announced with only nine (9) months' notice is extended by three (3) months, without any application by a Developer. The Company shall publish the corrected removal date within fourteen (14) days of discovering the shortfall.
7.2 A Developer harmed by an early removal: an integration broken before the published date: is entitled to restoration of the element until the corrected date and to a written account of what went wrong. Repeated shortfalls are cause for escalation under the Partner Support and Incident Escalation 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.
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; (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.
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; (c) suspend the Developer's credentials, Application, 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 for suspension, termination, and credential measures is governed by the Partner Suspension, Termination and Appeals.
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 investigation outstanding.
11.4 Effect of termination. On termination: (a) the rights granted under this Policy end; (b) obligations that arose before termination: including a migration duty for a change announced before termination with a Sunset Date after it, 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 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 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 of change under Article 3 are given as Article 3.6 provides. 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.