API Monetization and Usage Fees Policy
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers on a paid tier and every Developer account that incurs overage or usage-based charges.
Article 1: Introduction and Scope
1.1 This Policy governs what use of the application programming interface costs: how usage is metered, how tiers map to prices, how overage is billed, how invoices are issued and disputed, and what happens when payment fails. This Policy controls application programming interface fees; on a conflict with the API Access Tiers as to money, this Policy controls. Revenue share is governed by the Partner Revenue Share Policy, not by this Policy.
1.2 Sandbox usage is free. Fees begin at the Standard tier. Nothing in this Policy permits a charge for Sandbox calls, and an invoice line that references Sandbox usage is void on its face.
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 Company: All About Pawz, LLC, a Tennessee limited liability company.
2.3 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.4 Overage: usage beyond the monthly quota of the Developer's tier, billed under Article 5.
2.5 Platform: the websites, applications, and services the Company operates under the name All About Pawz, including aapawz.com.
2.6 Rate Card: the Company's published schedule of tier fees, overage rates, data-volume rates, and artificial intelligence rates for the tiers, in the version in effect for the period invoiced.
Article 3: Metering
3.1 Usage is metered in three dimensions, and each dimension is billed independently. An account may owe a tier fee, call Overage, and artificial intelligence charges in the same month, and each appears as its own invoice line.
3.2 Calls. Each request to a billable endpoint counts as one call, attributed to the credential that made it. Calls are aggregated per account across all credentials. A webhook delivery to a Developer endpoint is not counted against the Developer's quota, as the API Rate Limits and Quotas provides: the Company pushing data to the Developer is not the Developer calling the Company. A failed call the Company rejects before routing: an authentication failure or a malformed request: is not billed. A call that reaches the interface and returns an application-level error is billed, because the call consumed Platform resources.
3.3 Data volume. Data volume is billable where the Rate Card includes it: response payload volume for designated high-volume endpoints, measured at the response boundary, and inbound payload volume for bulk-write endpoints. The Rate Card names the endpoints where data volume applies; an endpoint not named is call-metered only.
3.4 Artificial intelligence compute. Calls to artificial intelligence endpoints are metered by invocation and by model consumption. Metering captures the invocation count, the input and output token counts, and the model invoked, because the cost to the Company of a call differs materially by model and the Rate Card prices models differently. The Rate Card publishes a rate per model per one thousand (1,000) tokens.
3.5 Metering is performed by the Company, and the Company's metering records are the record of account for billing, subject to the dispute procedure in Article 8. The Developer shall maintain the Developer's own call records; a Developer in the Elevated tier is required to do so, and every Developer is encouraged to do so, because a metering dispute is decided on the evidence of both parties under Article 8.
Article 4: Tier Fees and the Rate Card
4.1 Each paid tier carries a monthly fee stated in the Rate Card, billed in advance. The fee buys the tier's monthly quota, as the API Rate Limits and Quotas states the quotas, and the tier's support level, as the Partner Support and Incident Escalation Policy states it. A fee is payable under this Policy only if the fee is stated in the Rate Card. No other charge of any kind is payable, and the Company shall not impose a fee the Rate Card does not state.
4.2 The Rate Card is the single source for amounts: tier fees, overage rates per one thousand (1,000) calls, data-volume rates per gigabyte, artificial intelligence rates per model per one thousand (1,000) tokens, and any annual-prepayment discount. The Rate Card is versioned; every invoice cites the Rate Card version under which the invoice was computed; and a superseded version remains available for the life of any dispute window touching it.
4.3 A change to a fee or rate requires sixty (60) days' written notice and takes effect at the first billing cycle that begins after the notice period. The Developer may downgrade before a change takes effect and is never charged a new rate for a period that began before the change took effect. An increase applied without the sixty (60) days' notice is void as to the Developer; the earlier rate governs until proper notice has run.
4.4 Annual prepayment, where offered, carries the discount the Rate Card publishes. A prepaid amount is non-refundable except on a termination caused by the Company. On a downgrade during a prepaid term, the unused prepaid balance converts to account credit, not cash.
Article 5: Overage
5.1 Usage beyond the monthly quota is billed per one thousand (1,000) calls, or a fractional unit of one thousand (1,000) calls: one thousand and one (1,001) calls is two units. Overage accrues from one hundred percent (100%) of quota whether or not the Developer received the notices in Article 5.2; the notices are a courtesy, not a condition of billing.
5.2 The Company shall notify the Developer at eighty percent (80%) and at one hundred percent (100%) of quota, through the developer portal and the account's notification email address. The notice at one hundred percent (100%) states the current overage rate and a projection at the current rate of use, so the Developer can decide whether to upgrade, to reduce use, or to accept the Overage.
5.3 Sustained Overage above two hundred percent (200%) of quota for three (3) consecutive months requires a tier-upgrade discussion. The Company may require the upgrade: at two hundred percent (200%) sustained, the Developer is on the wrong tier and the Overage is no longer priced as an exception. Refusal of a required upgrade after thirty (30) days' notice is cause for limiting use to the quota under the API Rate Limits and Quotas.
5.4 Artificial intelligence usage has no separate quota: artificial intelligence usage is billed at the per-model rates from the first token. The notices in Article 5.2 apply to call quotas; for artificial intelligence spend, the developer portal shows a running monthly total, with a Developer-configurable alert threshold.
5.5 By way of illustration, on expressly hypothetical rates that are not the Company's pricing: a Developer on a hypothetical Standard tier with a tier fee of $49 per month, a quota of five million (5,000,000) calls, an overage rate of $0.40 per one thousand (1,000) calls, and an artificial intelligence rate of $2.00 per one thousand (1,000) tokens on a standard model, with usage in one month of 5,412,000 calls, no billable data volume, and 380,000 tokens, is invoiced: tier fee $49.00; call Overage of 412,000 calls, being 412 units at $0.40, totaling $164.80; and artificial intelligence charges of 380 units at $2.00, totaling $760.00: an invoice total of $973.80, on the payment terms in Article 6.2. The illustration shows the shape of an invoice: each dimension is its own line, Overage is computed on the excess only, and the Rate Card version is cited.
Article 6: Invoicing and Payment
6.1 Invoices issue monthly, within five (5) business days of month-end, with usage detail by credential and endpoint class: calls per endpoint class, data volume per metered endpoint, and artificial intelligence invocations per model with token counts. An invoice that cannot be reconciled to its usage detail is defective, and the payment period does not run on a defective invoice until the invoice is corrected.
6.2 Payment terms are net fifteen (15) days from the invoice date. Payment is made by a method the billing portal supports. The Developer shall keep a valid payment method on file for a paid tier. A failed automatic payment is retried and noticed to the Developer; the non-payment periods in Article 7 run from the original due date, not from a retry.
6.3 An account on annual prepayment is invoiced once per term for the tier fee, with monthly Overage invoices as incurred. Overage on a prepaid account follows Article 5 and the net fifteen (15) day terms in Article 6.2.
6.4 Quotas reset on the calendar month; unused quota does not roll over. An upgrade during a month grants the new tier's quota pro rata for the remaining days. A downgrade during a month keeps the higher quota until month-end, and the lower fee starts with the next cycle.
Article 7: Non-Payment
7.1 The non-payment sequence is fixed and cumulative: (a) at fifteen (15) days past due, written notice to the account's billing contact, stating the amount, the invoice, and the date by which payment cures the default; (b) at thirty (30) days past due, production access is suspended and the account is downgraded to Sandbox-only access until the balance is cured: Sandbox access continues so that the Developer's integration remains maintained during the cure period; and (c) at sixty (60) days past due, the account is terminated under the Partner Suspension, Termination and Appeals, with the data-deletion duties of the Data Use, Retention and Deletion: deletion within thirty (30) days and certification within forty-five (45) days. Termination at sixty (60) days ends Sandbox access as well.
7.2 An amount sixty (60) days past due may be sent to collections, and the Developer bears the reasonable costs of collection.
7.3 An amount disputed under Article 8 is excluded from the sequence in Article 7.1 while the dispute is open: but only the disputed portion. An undisputed amount follows Article 7.1 on its own clock.
Article 8: Fee and Metering Disputes
8.1 A billing dispute shall be filed within thirty (30) days of the invoice date. The dispute names the invoice, the contested lines, and the Developer's computed figure. The undisputed portion shall be paid on time; a dispute over an Overage line does not excuse the tier fee.
8.2 The Company shall respond within fifteen (15) business days: by a corrected invoice with a credit or an additional charge, or by a written explanation with the metering records relied on identified. A credit applies to the next invoice; an additional charge carries its own fifteen (15) day payment period from the correction date.
8.3 A metering dispute is decided on evidence. The Developer shall produce: (a) the Developer's own request records for the disputed period, with timestamps, endpoint paths, and the credential used; (b) the specific calls or time windows contested and the Developer's count for each; and (c) any request identifiers the Company returned, where the Company issues them. A dispute without records is not a filed dispute; the Company shall request the records once and shall close the matter if the records do not arrive within fifteen (15) days.
8.4 The Company shall produce: (a) the metering records for the account and period: counts per credential and per endpoint class, with timestamps; (b) the metering method in use and any known metering defect in that method for the period; and (c) the reconciliation showing how the invoice total was derived from the metering records.
8.5 A known metering defect is credited automatically: if the metering method double-counted a class of requests during a window, every affected account is credited without filing a dispute. The Company publishes metering incident notices in the developer portal; a Developer that was affected and was not credited automatically may file under Article 8.1 with the incident notice as evidence.
8.6 Where the two parties' evidence genuinely conflicts and neither party's records are defective, the contested window is resolved in favor of the Developer's records: the party asserting a charge bears the burden of proving it, and unexplained metering output does not meet that burden. The resolution applies per disputed window, not to the whole invoice.
8.7 Circumvention of metering: spreading load across credentials, accounts, or applications to evade a quota or Overage: is prohibited under the API Rate Limits and Quotas and is a conduct violation under the Partner Code of Conduct, not a billing dispute. A metering dispute is for an honest disagreement about counts; evasion is fraud.
Article 9: Liability
9.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.
9.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).
9.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, including fees and Overage owed under this Policy; or (d) liability that cannot be limited under applicable law.
9.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 10: Indemnification
10.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.
10.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.
10.3 Survival. This Article survives the termination of this Policy.
Article 11: Enforcement and Appeals
11.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 the Developer's own call records under Article 3.5.
11.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.
11.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. The periods in Article 7.1 are the cure periods for non-payment. No cure period applies to fraud, including metering circumvention under Article 8.7, a safety risk, unlawful conduct, or a violation that by its nature cannot be cured.
11.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) downgrade the account to Sandbox-only access or suspend the Developer's credentials, in whole or in part; (c) terminate this Policy and the Account; and (d) exercise any other right or remedy available under this Policy or at law. Downgrade and termination follow the Partner Suspension, Termination and Appeals.
11.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.
11.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 12: Term and Termination
12.1 Term. This Policy takes effect when the Developer first takes a paid tier or first incurs Overage and continues until terminated under this Article.
12.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.
12.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 balance outstanding, no Order outstanding, and no investigation outstanding.
12.4 Effect of termination. On termination: (a) the rights granted under this Policy end; (b) obligations that arose before termination: including payment of accrued fees and Overage, record-keeping, and indemnification obligations: survive until satisfied; and (c) the Company shall disburse amounts owed to the Developer, 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.
12.5 Survival. The Definitions, fees for accrued amounts, Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions Articles survive termination.
Article 13: Dispute Resolution
13.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 14: General Provisions
14.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 fees or obligations takes effect thirty (30) days after notice, subject to the sixty (60) day notice Article 4.3 requires for a change to a fee or rate stated in the Rate Card; 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 12 before the amendment takes effect.
14.2 Notices. Legal notices under this Policy shall be sent to legal@aapawz.com. Operational notices, billing communications, 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.
14.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.
14.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.
14.5 Entire agreement. This Policy, together with the documents it incorporates by reference and the Rate Card, 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.
14.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.
14.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.
14.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.