SP-API stands for Selling Partner API: the interface through which Amazon lets an external program read from and write to your Seller Central account. It replaced MWS and changed rather more than the name. From the Odoo side, the API itself is the easy part — HTTP requests with JSON. What decides whether the integration survives a November is three things you will not find in one endpoint's documentation: how it is authorised, how many calls you are allowed, and which data arrives late by design.
The authorisation is signed in Seller Central, not in Odoo
The flow is always the same: an application exists, registered under a developer profile, and you as the seller authorise it from your own account. That authorisation yields a long-lived refresh token which Odoo stores; with it, Odoo requests an access token that lasts about an hour, whenever it needs one. If somebody asks for your Seller Central password to «set it up», something is wrong: nobody needs your password for this. And if you revoke the authorisation, the integration stops dead — which is exactly what should happen.
Buyer data goes through a separate door
Buyer name, address and phone are personal data and Amazon treats them as such: they do not come back in the normal order response. You must request a restricted token for that specific call, and permission to do so is granted by role, not by default. The practical consequence in Odoo: orders can be importing perfectly while deliveries cannot be dispatched because the address is missing. That is not a connector bug; it is an approval you do not have.
Call limits are a budget, not a speed
Every SP-API operation has its own limit, and it behaves like a bucket that refills at a fixed rate and tolerates a short burst above it. While there is credit you go fast; when it runs out, Amazon answers 429 and you wait. That reads directly into Odoo: you cannot walk 4,000 references calling one at a time «because it is simpler». You group, you respect the rate-limit header the API itself returns, and you retry with growing backoff. And the manual sync and the scheduled job must share the same brake, because the budget belongs to the account, not to each process.
Reports versus live calls: why your stock is always behind
The SP-API gives you data in two ways. One is the direct call: you ask for orders since a date and it answers immediately. The other is the report system, which is asynchronous: you request a report, Amazon builds it when it can, you poll until it is ready, then you download a compressed file. FBA inventory and settlements travel that way. So the stock you see in Odoo is the stock of the last download, not of this second, and no cron frequency fixes that. The right answer is not to call more often: it is to publish with a safety buffer and accept the lag.
The SP-API sandbox returns fixed responses prepared by Amazon. It is good for checking that you sign requests correctly, and little else: all its operations share one rate limit, so it does not reproduce each operation's production limit, it will not hand you a pending order without an address, and it will not make you renew a token half-way through a long sync. A connector that is green in sandbox is not tested. We wrote about it in green tests, production failure.
The errors that only show up in production
They are always the same, and none of them shows up on day one. Pending orders that arrive with no amounts and no address and must be re-read later. Pagination: the first page lands and the rest is lost if nobody follows the continuation token. Date windows miscalculated by timezone, leaving a gap of orders right at the day boundary. Tokens expiring mid-way through a long sync and needing renewal in flight. And the wrong region: the application is global but the seller account is not, and asking the North America endpoint for German orders does not answer «wrong region» — it answers «Access to requested resource is denied». It looks like a permissions problem, so people regenerate credentials that were fine while the fault sits in the URL.
Where this has to live inside Odoo
A call to Amazon cannot hang off a delivery validation. If the API is slow the user stares at a spinner, and if it fails the work is lost. These calls belong in a scheduled action or a job queue, with retries, a log of what was requested and what Amazon answered, and idempotent operations: repeating a sync must not create the order twice. That log is what later lets you argue with Amazon support using data instead of impressions. The same pattern applied to missing orders is in why Amazon orders do not import into Odoo.
When you do not need to build anything
If you sell on a single marketplace, with few references, and all you need is orders coming in, the Amazon connector shipped with Odoo Enterprise may be enough. It is worth trying before paying for anything. The conversation changes when there are several countries with their own taxes, stock shared with other channels, settlements to reconcile or shipping confirmations with a deadline. That is where our Amazon connector for Odoo does the work: SP-API with rate control, reports, FBA and FBM, on Odoo 17, 18 and 19, and Odoo 20 the day it ships.
Frequently asked questions
Do I need an Amazon developer account to use the SP-API?
The application has to be registered under a developer profile, but you are the one who authorises it from your own Seller Central. The authorisation is yours and you can revoke it whenever you want.
Can Amazon stock be queried in real time?
Not in the way people imagine. Inventory comes mostly by report, which is asynchronous, so there is always a lag of minutes. That is why a safety buffer matters more than sync frequency.
What happens if Amazon returns 429 in the middle of a peak?
Nothing serious if the integration retries with growing backoff and queues what is pending. It is serious if the process dies and nobody notices until orders are missing: that is why logging and alerting matter as much as the call itself.
Useful links inside FlexigoTech
What we do about this
Is your SP-API integration failing and you cannot tell where?
Tell us which marketplaces you sell on, whether you use FBA, FBM or both, and the exact error you see in the log. We will check whether it is authorisation, rate limits or a badly calculated date window. Write to comercial@flexigobe.com or book a call.