Webhook Obligations
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers who subscribe to or receive Platform event notifications.
Article 1: Introduction and Scope
1.1 This document governs event notifications the Company delivers to a Developer endpoint: subscription, endpoint security, signature verification, acknowledgement, retry, and handling of event data. The duties in this document are stated as obligations of the Developer as a receiver.
1.2 If a provision of this document conflicts with the Terms of Use, this document controls for its subject. If a provision of this document conflicts with the Developer Agreement, the Developer Agreement controls, except that this document controls for webhook delivery and receipt. Policies and help pages explain this document; they do not amend it.
Article 2: Definitions
2.1 In this document, terms defined in the Developer Agreement have the same meaning, and Delivery: a transmission of an Event to a Subscription endpoint, including a redelivery of the same Event.
Event: a notice of a Platform occurrence of a subscribed type, carrying the event identifier, the event type, the time, and the minimum fields the event type requires.
Subscription: a registration of an endpoint for one or more Event types for one Application, with a signing secret issued for that Subscription.
Article 3: Subscriptions
3.1 A Subscription is created per Application and per Event type and carries its own signing secret, issued at subscription time and governed by the API Key Management and Rotation for storage and rotation. The Developer shall subscribe only to the Event types the Application requires. The Company may narrow an over-broad Subscription in the same manner as an over-scoped Credential under the API Key Management and Rotation.
3.2 Event data received under a Subscription is Platform data for purposes of the Data Use, Retention and Deletion and shall be handled under that document: used only for the Application's stated function, retained only as that document permits, and deleted as that document requires.
Article 4: Delivery Terms
4.1 The Company signs each Delivery with the Subscription's signing secret over the exact content delivered, and includes the signing time with the Delivery, in the manner the API Policies prescribe. The signature covers the content as sent.
4.2 An endpoint shall use a secure encrypted connection with a valid certificate. The Company rejects a Subscription with an unencrypted endpoint at creation, and treats a lapsed certificate as an endpoint failure under clause 4.4.
4.3 An endpoint shall acknowledge receipt within five (5) seconds with a success response. A timeout beyond five (5) seconds, an error response, a connection refusal, or a name-resolution failure is a failed Delivery. The five (5) second period is for acknowledgement only, not for processing; the receiver procedure in Article 5 states the required order of operations.
4.4 A failed Delivery is retried up to eight (8) times with increasing intervals and variation over a twenty-four (24) hour period, at approximately one (1) minute, five (5) minutes, twenty-five (25) minutes, two (2) hours, six (6) hours, twelve (12) hours, eighteen (18) hours, and twenty-four (24) hours after the initial attempt. After the eighth failure the Event is set aside for manual replay through the developer portal and retained for thirty (30) days. The Developer shall design the endpoint and the recovery procedure around this schedule and shall not request a custom schedule for a Subscription.
4.5 The Company delivers Events for a Subscription in the order the Events occurred, on a best-efforts basis, and guarantees no stronger ordering. A receiver may receive a later Event before a retried earlier Event and may receive the same Event twice. Article 5 states the receiver duties that address ordering and duplication.
4.6 An endpoint that fails fifty (50) consecutive Deliveries, or that fails every Delivery for seven (7) consecutive days, is disabled automatically. Disablement does not delete the Subscription, its secret, or its set-aside Events. Re-enabling requires the Developer to correct the endpoint and to pass a verification Delivery the Company sends on demand. The Company gives notice at the first failure, at ten (10) consecutive failures, and at disablement; notice does not transfer the monitoring duty in clause 5.5 to the Company.
Article 5: Receiver Duties
5.1 Acknowledge first, process after. The Developer shall operate the endpoint so that it verifies the Delivery, records the raw Event, returns a success response within the period in clause 4.3, and only then processes the Event in a separate operation. An endpoint that performs extended processing inside the receipt operation and thereby exceeds the acknowledgement period is treated as a failed endpoint.
5.2 Verify every Delivery. The Developer shall, for every Delivery: (a) compute the signature over the raw content received, using the Subscription secret, and compare the result with the signature supplied, using a comparison that does not disclose the secret through timing; (b) reject a Delivery whose signing time differs from the receiver's time by more than five (5) minutes, as protection against replay of a captured Delivery; and (c) refuse to process a Delivery that fails verification. Processing an unverified payload is prohibited, including where the content appears correct. The Developer shall keep a verification record for each Delivery, stating the Event identifier, the verification outcome, and the disposition, in the same manner as the Company's receipt records.
5.3 Idempotency. The Developer shall handle redelivery without duplicate effect. The Developer shall deduplicate on the Event identifier, shall keep a record of processed Event identifiers for thirty (30) days, and shall acknowledge a duplicate Delivery without reprocessing it.
5.4 Out-of-order Events. The Developer shall design state changes to tolerate out-of-order arrival. An update Event that arrives before the creation Event for the same object shall be applied against a current read of state, or held until the creation Event arrives, and shall not corrupt the local record. Arrival out of order is not, without more, a defect of the Company.
5.5 Monitoring and repair. The Developer shall monitor the failure count of each endpoint the Developer operates and shall repair a failing endpoint within two (2) business days of the first failure notice. The disablement thresholds in clause 4.6 are a backstop, not a repair schedule.
5.6 Prohibited receiver conduct. The Developer shall not: (a) expose an endpoint that performs an effect on an unauthenticated request: signature verification is the authentication for a Delivery; (b) act on a payload that failed verification; (c) record a full payload containing personal data in an unprotected log store; or (d) use receipt of an Event as the sole basis for a movement of money without a confirming read through the API.
Article 6: Payloads and Changes
6.1 An Event payload carries the minimum data for the Event type: the Event identifier, the Event type, the time, the tenant and object identifiers, and the fields that changed. A receiver that requires the full object shall obtain it through the API, and that Call counts under the API Rate Limits and Quotas and is subject to the Data Use, Retention and Deletion. A Delivery itself does not count against the Developer's quota under the API Rate Limits and Quotas.
6.2 The Event catalog and payload forms are published in the API reference. Changes follow the Deprecation and Breaking Changes Policy: an addition of a field or an Event type is made with notice and does not break an existing receiver; a removal, a type change, or a change of meaning follows the timetable in that document. A receiver shall ignore an unknown field rather than reject a payload that contains it.
Article 7: Liability
7.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.
7.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).
7.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 the Developer owes for Orders, fees, chargebacks, or refunds under this document; or (d) liability that cannot be limited under applicable law.
7.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 8: Indemnification
8.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, including processing of an unverified Delivery; (b) the Developer's Applications and 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 this document.
8.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.
8.3 Survival. This article survives the termination of this document.
Article 9: Enforcement and Appeals
9.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, including verification records under clause 5.2.
9.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. Automatic disablement under clause 4.6 is a protective measure and ends when the endpoint passes verification.
9.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, to deliberate misuse of Event data, or to a violation that by its nature cannot be cured.
9.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 disable a Subscription or an endpoint; (c) suspend or revoke a Credential; (d) suspend the Account or a program participation, in whole or in part; (e) terminate this document and the Account; and (f) exercise any other right or remedy available under this document or at law. Misuse of Event data is governed additionally by the Data Use, Retention and Deletion and the Scraping Prohibition, as applicable. Procedure is further governed by the Partner Suspension, Termination and Appeals.
9.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.
9.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 10: Term and Termination
10.1 Term. This document takes effect when the Developer creates a Subscription or first receives a Delivery, whichever occurs first, and continues until terminated under this article or until the Developer Agreement terminates, whichever occurs first.
10.2 Termination by the Company. The Company may terminate this document 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.
10.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 and has deleted every Subscription.
10.4 Effect of termination. On termination: (a) every Subscription ends and its signing secret is revoked; (b) Event data held by the Developer remains subject to the Data Use, Retention and Deletion; (c) obligations that arose before termination survive until satisfied; and (d) the Company shall pay amounts owed, less amounts the Company may set off under this document, within thirty (30) days, except amounts held in connection with an open investigation or dispute.
10.5 Survival. The Definitions, Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions articles survive termination.
Article 11: Dispute Resolution
11.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 12: General Provisions
12.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 fees or 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 10 before the amendment takes effect.
12.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. DMCA notices are given as provided in the DMCA and Copyright Policy, to the designated agent at legal@aapawz.com.
12.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.
12.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.
12.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.
12.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.
12.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.
12.8 Interpretation. Headings are for convenience only. "Including" means "including without limitation." This document shall not be construed against a party on the ground that the party prepared it. The English-language text controls over any translation.