Give your team the API. Keep your keys.

One of my employees asked me for API access this week. He updates listings: titles, images, prices, inventory. Clicking through Seller Central for every change is slow.

My first instinct was to stall. I trust the guy, obviously. But "hand an employee the keys to the Amazon account" feels like handing over the business. So before I answered, I looked at how sellers usually do this. There are two common answers, and both are bad.

Bad answer #1: share your Seller Central login

One password opens everything: listings, but also deposit settings, tax information, and user permissions. There is no audit trail; everything they do looks like you did it. And when they leave, you change the password and then re-enter it on every device and tool it ever lived in.

Bad answer #2: share the API keys your own tools run on

If you already use software on your account, you have a set of API credentials somewhere. Handing those over is worse than the password. That one token is the whole account: every marketplace, every permission your setup ever needed, and no way to tell their calls from yours. Revoking it means rotating credentials that every tool you run depends on. The day they leave becomes the day your automations break.

The fallback: just say no

Also a real cost. Your employee keeps clicking through pages that software should be handling, and you keep paying for those hours.

The word "app" throws people off, so let's kill it early: nothing gets built, coded, or hosted. An "app" in Amazon's developer console is one registration entry whose only job is to mint credentials.

You create one app per person, named after them. Each app produces three strings of text. Those three strings are a keycard: software holding them can act on your account, within the permission boxes you ticked when you made the app.

LWA_CLIENT_ID=amzn1.application-oa2-client.xxxxxxxx
LWA_CLIENT_SECRET=amzn1.oa2-cs.v1.xxxxxxxx
REFRESH_TOKEN=Atzr|IwEBxxxxxxxxxxxxxxxx

Why this shape wins

• Amazon enforces the permission boxes on its side. A keycard with only listing permissions cannot call a finance endpoint, no matter what the software holding it tries.
• Each app gets its own rate limit. Their tools never slow down yours, and yours never slow theirs.
• Offboarding is one delete. Remove the app, their three strings go dead, and nothing else you run notices.

The app form shows a checklist of roles. Each box you tick is a set of doors the keycard can open. Fewer boxes, smaller blast radius. You can add a box later in Edit App if their job grows.

Here is the Sellers checklist in plain English. For a listings-and-operations person, the four marked ones are the set I'd start with.

• Skip Finance and Accounting unless their job is literally reconciling statements. It reads account and financial statements; it cannot change where your money goes. But there is no reason a listings person needs it.
• If a role shows up marked Restricted on your form (personal buyer data: addresses, tax documents), it needs separate Amazon approval and almost no employee job calls for it. Leave those alone.
• Pricing is a judgment call. If they manage prices, tick it. If not, don't; a wrong price goes live instantly with no confirmation step, which makes it the sharpest tool on this list.

This is the part that changed recently. Amazon publishes an official connector that plugs its API into an AI assistant. The Claude desktop app runs it out of the box; your employee needs their own Claude account (a paid plan, Pro is enough). Once it's connected, they work in plain English: "change the second bullet on this listing," "what's in stock?", "prep the FBA shipment." The assistant makes the API calls.

Day one, they paste this into their assistant and follow along:

In the Claude desktop app, the config file the assistant will point them to lives under Settings, then Developer, then Edit Config, and the block they type the strings into looks like this:

"amazon": {
  "command": "npx",
  "args": ["-y", "-p", "@amazon-sp-api-release/sp-api-dev-mcp",
           "sp-api-dev-assistant-mcp-server"],
  "env": {
    "SP_API_CLIENT_ID":     "their client ID",
    "SP_API_CLIENT_SECRET": "their secret",
    "SP_API_REFRESH_TOKEN": "their refresh token",
    "SP_API_REGION":        "na"
  }
}

If your employee lives in ChatGPT or Gemini instead, the connector needs a developer-grade setup there; the Claude desktop app is the plug-and-play path. First launch downloads the connector, so give it a few minutes. When "call getMarketplaceParticipations" comes back listing your marketplaces, they are in.

My real worry was money. So before my employees got their strings, I pulled the full API catalog on my own account: 54 categories of endpoints. Not one of them can add or change bank accounts, deposit methods, tax settings, account settings, or user permissions.

"They can change listings but can't touch the money" is not a rule you configure and hope holds. The doors are not there. No permission box you tick creates them.

The rest of the safety model

• Cost: zero. Amazon doesn't bill for API calls. The only quota is speed (calls per second), counted per app, so nobody's tools slow anybody else's.
• If the strings leak (stolen laptop, pasted somewhere public): they tell you the same day. Amazon expects leaked credentials reported within 24 hours, and replacing them takes minutes: new secret from the console, new refresh token from Authorize.
• When they leave: delete their app. The three strings die that minute. Your tools, your other employees' apps, nothing else notices.
• Some settings have no API at all. A handful of Seller Central pages are UI-only. For those, the human lane is the one you already know: invite them as a Seller Central user with their own login, scoped per section. The app is the software lane; user permissions are the clicking lane. They complement each other.

When you send the strings, send the rules with them. Here is the note for your team; take it word for word.

Questions that come up

• What does this cost? Nothing. No API fees, no per-call charges, no subscription. The only investment is the ten minutes per person.
• Can I do this for three people? Ten? Yes. One app each, named after each person. Separate keycards, separate rate lanes, separate off-switches.
• What if they lose the refresh token? Run Authorize again and send the new one. Nothing breaks in between.
• Do they still need a Seller Central login? For clicking around the UI, yes, and that is a separate Seller Central user invite with its own scoped login. The keycard covers what software does on their behalf.
• What about PPC? Different system. The Ads API has its own authorization flow and its own console. If their job grows into ads, treat that as its own decision.