Solution Providers

Solution providers are independent companies that build products on the All About Pawz API for many accounts at once: catalog tooling, inventory and order sync, repricing advice, shipping tools, analytics dashboards, marketing automation. One provider does the integration work once, and every account it serves benefits. This guide states what providers build, how a provider is approved, and the obligations that come from holding many accounts' access at once. Provider participation is governed by the Solution Provider Program; access is issued by the Company after review and is not self-service.

What providers build

The categories that matter

• Catalog tooling: bulk editors, feed managers, duplicate resolvers: under the discipline in Catalog and Feeds and Bulk Data.
• Pricing tools: analysis and recommendations. A pricing tool advises; the price of record is set through the pricing resource by the account's own decision (Pricing).
• Inventory and order sync: warehouse and ERP connectors working to the signals in Inventory and Orders.
• Fulfillment tooling: label and tracking workflows built on Fulfillment.
• Customer communication: review requests and post-purchase messaging, within the Platform's messaging and consent rules (Systems Integrations).
• Analytics: account-facing dashboards built on the definitions in Analytics.
• Automated assistants: built under the registration and disclosure contract in AI Agents and MCP.

A product that moves money, writes catalog data, or contacts customers faces the highest review bar. Those are the capabilities where a careless provider does the most damage per account connected.

Becoming a provider

1. Apply with the product described, the scopes it needs, the data it touches, and the accounts it is meant to serve. Write to support@aapawz.com.
2. Review runs on three axes
   • Technical: does the product implement the API contract: idempotency on writes (Idempotency Keys), webhook signature verification (Webhooks), rate-limit discipline (Rate Limit Headers), error handling by code (Error Codes)?
   • Security: credential custody, per-account separation, data retention, and incident response, as Security and Compliance requires.
   • Commercial: does the product serve the accounts it connects, on terms those accounts understand: pricing that is transparent, and no use of connected accounts' data beyond providing the service?
3. Approval grants a provider identity, its authorized scopes, and a directory listing with the capabilities that were actually verified: not the ones the application hoped for.

The review is neither a formality nor an obstacle course. It exists because accounts trust the provider directory, and that trust is the program's product.

Serving many accounts: the separation obligations

A provider holds many accounts' access in one system, and the separation between those accounts is absolute. These obligations bind from the first connected account

1. One account's data never appears in another's context: not in screens, not in exports, and not in "benchmarks" or aggregates, unless the accounts contributing data opted in knowingly and the aggregate cannot be reverse-engineered back to an account.
2. Keep each account's authorization separate. Each account's access is granted for that account and used only for that account (Authentication and Authorization). Never use one account's grant to reach another's data: not for a comparison, not for a quick check.
3. Scope per account, recorded per account. Store what each account authorized, when, and for what, so any action your product took can be attributed to the authorization that permitted it.
4. When an account disconnects, delete its data on the schedule the Data Use, Retention and Deletion policy sets: from your database, your caches, your exports, and your analytics. Deleting from the application while keeping the warehouse copy is not deletion. Build the deletion path when you build the storage.
5. Core Concepts applies per account: pagination, idempotency, and rate limits are per key; a provider's aggregate traffic is managed as the sum of its accounts' fair use, not as a pool to be spent on the loudest account.

Provider responsibilities

• Uptime and support are yours. If your sync goes down, your accounts' prices and stock go stale, and that is your incident to run and your status to communicate. The Platform's availability does not cover your product's.
• Monitor your own signals. Track error rates per account, rate-budget consumption, and webhook delivery health. The Platform exposes the signals; the alerting is your product's job.
• Disclose incidents promptly. A breach or data-integrity failure affecting connected accounts is reported to the Company and to affected accounts quickly and completely, under the Breach Notification Requirements. Concealment is always worse than the incident.
• Follow the money discipline in Payments where your product touches payments: idempotent writes, complete audit trails, no parallel money logic.
• Stay inside your approved scopes. A material change in what your product does: new data, new actions, new account types: is a new review, requested in advance, not a discovery the Platform makes later.

The directory and standing

Approved providers are listed with their verified capabilities, pricing, and support terms. The listing is earned continuously: account ratings, incident history, and scope hygiene feed its standing, and providers that let security lapse or support deteriorate lose placement and, ultimately, approval: under the enforcement and appeals framework in Governance and the Partner Suspension, Termination and Appeals policy. Accounts choose providers from the directory trusting that the Platform vetted them. Build as if your listing depends on that trust being accurate, because it does.

Questions about the provider program: support@aapawz.com.