Amazon Ads API

Most of the Amazon Ads API is unremarkable. Authenticate, list profiles, read campaigns, pull a report. The work gets hard on either side of that: getting credentials that function at all means moving through several separate Amazon systems in the right order, and once you are in, anything worth building runs on a schedule against live spend. That is where throttling, timezones and missing primitives start costing money rather than time.

The jobs I get called into are rarely "how do I call this endpoint". They are 429 storms in production, a dayparting schedule that turned out to be several hours off, and daily numbers being asked hourly questions.

What actually goes wrong here

• Access is scattered, not difficult. The LWA security profile, the Ads API application and the approval that links them sit in different systems, and the order you do them in matters.
• Throttling is per endpoint, not global. There is no one account-wide rate to stay under; each endpoint has its own bucket, and a 429 is usually a verdict on your retry code.
• The only scheduler raises bids. Sponsored Products schedule bid rules can push bids up at set hours; lowering them, pausing, or reacting to the hour's numbers is a job you run yourself.
• Hourly data is a different pipeline. You do not get it by polling the Reports API harder. Marketing Stream pushes it to you instead.
• The writes are unattended and real. An hourly job with a bug in it spends money for hours before anyone looks.

Which guide to open

Start at the beginning if you have no credentials yet. The Direct Advertiser access walkthrough runs from creating an LWA security profile through the application, the approval email, the return URL and the auth-code exchange, ending on a Profiles call that proves the setup works. The approval email is flagged as a warning rather than a step, and it is the one to read before you click anything.

Once you are calling the API in volume, read how the per-endpoint token buckets actually behave. It covers what the response headers tell you before you retry, the retry pattern that turns one 429 into a storm, why async v3 reporting beats polling everything, and why asking for a higher limit is almost never the fix.

Data granularity is the next fork, and it is worth settling first. Marketing Stream and Marketing Cloud get mixed up constantly because they sound like the same product, but they solve opposite problems: one pushes hourly ad data into AWS infrastructure you own, for acting now; the other is for asking what happened, after the fact. Most teams doing this seriously end up running both. If the answer is Marketing Stream, the full Firehose setup is the long one: the delivery stream, both IAM roles, the subscription call, and what the hourly files look like once they start landing in S3.

With hourly data in hand, dayparting becomes buildable. Building the clock yourself covers the shape that holds up, why timezones are the actual hard part, the guardrails that stop an unattended writer doing damage, and the question worth asking first: whether your account has enough data to justify dayparting at all.

If you would rather ask questions of the account than write scripts against it, connecting Claude to the Ads and Seller Central MCP servers works through a local proxy today, while the built-in connector flow fails on an unknown-scope error. It also measures what the connection costs you, and how to cut that.

These are write-ups of client builds, not readings of the documentation. The gotchas are in them because they cost me time first. If you would rather not build it in-house, the consulting side of this is the same work, done for you.