AI Agents and MCP

This guide covers automated and agent-driven integrations: software that calls the API without a person initiating each call: scheduled sync agents, monitoring and repricing assistants, support-desk automation, and AI agents that converse with buyers or act on an account's instructions. Automated access is governed by the Automated Access and Agent Disclosure policy and the Developer Agreement. The foundational rule is simple: a machine client is a client. It uses the same issued keys, the same access tiers, the same rate limits, and the same idempotency rules as any integration in this guide set: plus the registration, scoping, and liability duties this guide adds.

Registering an automated client

Before an automated client calls the API in production, register it with the Company

1. Name the client and its owner. Every automated client has an identified human or organizational owner inside the account: the person answerable for what it does. Anonymous automation is not permitted.
2. Declare its purpose and its actions. State what the client does, which resources it reads, and which writes it makes, in the same terms you would declare any integration's scope (Getting Started).
3. Receive its own key. Automated clients hold their own credentials, separate from keys used interactively, so their traffic is identifiable in logs, metered separately, and revocable without breaking anything else (Authentication and Authorization).
4. Keep the registration current. A material change: new resources, new write actions, a new operator of the client: is a registration update made in advance. Registrations are reviewed on a cadence, and clients that no longer operate as registered are suspended.

An unregistered automated client calling the API is treated as unauthorized access, because functionally that is what it is. Connections made through agent protocols (including MCP-style tool connections) are registered the same way: a defined scope, an owner, and credentials issued for that connection.

Least-privilege scoping

Automated clients run unattended, which is exactly why their scope must be the narrowest that does the declared job

• Read only what the task reads. A stock-monitoring agent gets inventory reads: not orders, not payments, not buyer details.
• Write only what the task writes. A repricing assistant that recommends prices needs no write access at all until a human approves the recommendation; where it does write, it writes prices and nothing else (Pricing).
• Separate duties across clients. One omnibus agent holding every scope your account owns is a single point of compromise and of confusion. Register several narrow clients instead.
• Time-box elevated access. Where a task temporarily needs broader scope, request it for the task's duration and surrender it when the task ends.
• No credential sharing between clients. Each client holds its own key; a shared key makes metering, attribution, and revocation meaningless.

Operating rules for machine clients

1. Rate discipline applies in full. Limits and headers are specified in Rate Limit Headers. An agent that polls aggressively is indistinguishable from an abusive client and is treated as one; subscribe to Webhooks instead of polling where events exist.
2. Writes are idempotent, always. Every automated write carries an Idempotency-Key (Idempotency Keys). An agent that retries a non-idempotent write will eventually double-apply it: a double refund, a double order action: and "the agent retried" is not a defense.
3. Irreversible actions need a human gate. Placing refunds, changing prices beyond declared bounds, cancelling orders, or messaging buyers at scale require either confirmation by the account holder or a pre-authorized policy with explicit bounds (for example, "reorder this supply when stock falls below five, up to a stated amount per month"). The bounds are part of the registration.
4. Disclosure where the agent meets people. Where an automated client communicates with buyers or other people, it identifies itself as automated, states what it can and cannot do, and never impersonates a human: not a support representative, not a seller, not a professional of any kind. Automated Access and Agent Disclosure states the disclosure standard; Governance explains how disclosure failures affect standing.
5. Honest uncertainty. An agent acting on Platform data reads the data; it does not invent prices, availability, order states, or policy. Where the data does not answer, the agent says so or hands off to a human.
6. Data minimization. An automated client retains only what its declared task requires, for only as long as the task requires it (Data Use, Retention and Deletion). Conversations and working data from one account are never used to serve another account, and never leave the account's scope (Franchise Integrations states the same boundary for locations).

Liability: the account holder answers for its agents

Actions an automated client takes under an account's key are the account's actions. The account holder is responsible for what its registered clients do: the writes they make, the messages they send, the data they read: to the same extent as if its own staff had done them through the Seller Center. Three consequences follow, and they should shape how you deploy

• You cannot delegate accountability. "Our vendor's agent did it" allocates blame between you and your vendor; it does not move the account's responsibility to the Platform. Choose agent software as you would choose an employee with system access.
• Incidents caused by your agents are your incidents to report. If an automated client acts outside its registered scope, corrupts data, or contacts people improperly, notify the Company promptly (Security and Compliance; Breach Notification Requirements where data is exposed) and suspend the client while you investigate.
• Keep the logs that prove what happened. Record, per client: what it was asked to do, what it did, which calls it made, and under what authorization. When an action is disputed, the log is the account's evidence: and its absence is also evidence.

Failure handling

• Runaway behavior: call volume far above the registered pattern, writes outside the declared rhythm: your own monitoring should trip first. Build a stop control that revokes or disables the client's key without a deploy, and rehearse it.
• Scope rejection (403): the client attempted something outside its registration. Treat it as a design or configuration defect and stop the client until it is understood; never respond by requesting blanket scope "to unblock it."
• Hallucinated or stale data driving actions: an agent that acted on invented or cached-past-expiry facts: suspend the write path, keep the read path for diagnosis, and review what the agent may act on without a fresh read.

What good looks like

Each automated client is registered, narrowly scoped, separately keyed, idempotent in every write, disclosed wherever it meets people, and stoppable in one action by a named owner who answers for it. Automation earns its place on this platform the same way any integration does: by being identifiable, measurable, and revocable: and by never surprising the account that owns it.

Questions about registering an automated client: support@aapawz.com.