Governance

This guide is written for the integrator: how an integration stays in good standing: what the Platform measures, what happens when an account or an integration falls short, how certification works, and how to appeal. You do not write the Platform's policies, and your integration does not invent its own copy of them: it reads account standing from the API, surfaces it to the people who can act, and respects restrictions the moment they apply. The governing instruments are the Terms of Use, the Selling Terms of Service, the Developer Agreement, and the API Access Tiers.

The principle: apply the rule as written

When your integration needs a rule: the return window, a response deadline, a certification requirement: take it from the governing document or from the API's current response, never from a value remembered in a meeting and hardcoded into your system. Rules change; a hardcoded rule keeps enforcing yesterday's version and calls it compliance. Where a rule affects your users, show them the rule, the document behind it, and the deadline: an account holder who can see the requirement, the evidence, and the way back is a manageable situation; one who sees only "restricted" becomes a dispute.

Checking standing

Standing is the Platform's measure of an account, computed from the service levels in the Service Level Requirements: response times, fulfillment times, return handling: and from compliance with the instruments above. Governance Endpoints exposes standing and related records to accounts in the programs it serves.

• Query standing; do not compute it. The computation belongs to the Platform and is applied identically to every account. An integration that derives its own verdict will disagree with the Platform's at the worst moment (see Analytics on shared definitions).
• Check at the gates that matter: before listing new products, before a payout is expected, and on a schedule in between, so a change is discovered by your integration before it is discovered by a blocked action.
• Cache briefly. Standing changes when an account remediates; a long cache delays the recovery your user has earned. Minutes, not days.

Certification

Integrations that will operate at scale or touch sensitive flows are certified before they rely on them, under the Integration Certification Policy. In working terms, certification checks that the integration

1. Authenticates and handles keys as Authentication and Authorization requires.
2. Sends writes idempotently (Idempotency Keys) and verifies webhook signatures (Webhooks).
3. Respects rate limits (Rate Limit Headers) under load, including backing off rather than retrying into a 429.
4. Handles errors by code (Error Codes), keeps account data inside the account's scope, and deletes data it should no longer hold.

Prepare for certification by building to those standards from the start; an integration built to them certifies as a formality, and one built around them experiences certification as a rewrite. Keep the certified behavior in production: certification describes how the integration runs, not how it behaved during review.

When things go wrong: enforcement

Enforcement against an account follows the Seller Enforcement Policy; enforcement against an integration or partner follows the Developer Agreement and the Partner Suspension, Termination and Appeals policy. The shape is graduated: notice, warning, restriction, suspension, removal: with each step stating its trigger, its effect, and its exit. Your integration's duties at each step

• Notice and warning: surface the issue to the account holder with the evidence and the deadline. An integration that hides a warning from its own user has made the next step inevitable.
• Restriction: respect the limitation everywhere it applies: for example, no new listings, or payouts held (see Payments): in every flow your integration offers. A restriction honored in one screen and bypassed in another is not honored.
• Suspension: stop the suspended operations cleanly. In-flight orders still deserve fulfillment where the Platform permits it, because restricting an account must not strand its buyers.
• Removal: terminal and rare, and it is the Platform's decision, never an integration's. Your job is an orderly wind-down: stop calls, settle what can be settled, and delete the account's data on the schedule the Data Use, Retention and Deletion policy sets.

Buyer-seller disputes are the adjacent track: they run under the Dispute Resolution Policy, with defined response windows for the seller. Build those windows into your tooling as visible deadlines: a buyer who can see "the seller has a stated period to respond" waits; a buyer who sees nothing escalates elsewhere.

Appeals

An enforcement action can be appealed. Appeals on enforcement follow the Enforcement and Appeals Policy; appeals under the developer instruments follow the channel the Developer Agreement and Partner Suspension, Termination and Appeals provide, with notices to legal@aapawz.com where those instruments direct.

• File within the window the governing policy states, with the evidence it requires. Read the window and the evidence list from the current policy: do not hardcode either, because both are set in the policy and change with it.
• An appeal states what was decided, why it is said to be wrong, and what evidence supports that. "Please reconsider" without evidence is a delay, not an appeal.
• While an appeal is pending, the action stands unless the decision says otherwise; keep respecting restrictions in your integration until notified of a change.

Automated tooling under governance

If your integration includes automated or agent-driven features, the disclosure duties in AI Agents and MCP are part of standing: the feature operates only where its required disclosures and acknowledgements are in place, and incidents caused by automated behavior are recorded and reportable. An integration that enables an automated feature without its required acknowledgement is out of standing from the first action that feature takes.

What to build

• Account dashboards: standing, open issues with evidence and deadlines, and the appeal path: each item citing the document and section it comes from.
• Operational tooling: restrictions enforced at the action, not displayed as a banner the action ignores; standing checked before listing and payout flows.
• Buyer-facing flows: dispute stages and their timelines shown honestly, so the process is legible to the person waiting on it.

Standing is maintained the way it is lost: in small, visible steps. An integration that keeps its account holder informed, compliant, and able to appeal has done the whole of this guide.