Best Practices

Recommended setup

Match your SP-API region to your account

Select North America, Europe, or Far East based on where your Seller Central account is actually registered. Picking the wrong region means no marketplaces will load, even with valid authorization.

Start with Orders and a short date range

Confirm your connection with the Orders entity and a 7-day window before adding report-based entities or widening your date range — this isolates connection issues from report-processing issues.

Separate core entities from report entities

Orders, Order items, and financial events sync directly from the API and are best refreshed often. Report entities (inventory, fees, settlements, listings) go through Amazon's async report pipeline and are slower — put them in their own data flow with a longer schedule.

Data refresh and scheduling

Don't over-schedule Orders

Amazon rate-limits the Orders endpoint tightly. Scheduling it every few minutes won't get you fresher data — it'll just queue up against the same quota. Hourly or a few times a day is usually sufficient for order status tracking.

Give report entities a longer schedule

Because reports are generated asynchronously by Amazon, a daily or weekly schedule is typically enough — running them more frequently doesn't speed up Amazon's own processing time.

Vendor forecasting reports don't need frequent refreshing

These always return Amazon's current forecast snapshot rather than a date-filtered history, so refreshing them more than once a day adds no new information.

Performance optimization

Join Orders with Order items

Amazon exposes these as two separate entities. Pull both and use Coupler.io's Join transformation on order ID to get a single line-item-level view instead of cross-referencing two tables manually.

Use ledger summary instead of ledger detail when possible

Ledger summary view data rolls up balances over a period; ledger detail view data returns every line. If you only need period totals, the summary report is faster to sync and lighter to process downstream.

Keep incremental windows narrow on scheduled runs

For Orders and Order items, set a date range that covers just the period since your last run rather than re-pulling your full history each time — this reduces both sync time and the chance of hitting rate limits.

Dashboard accuracy

Reconcile against completed settlement periods

Compare the V2 settlement report or ledger reports against a settlement period that has already closed, not one still in progress — in-progress periods will keep changing as Amazon posts more events.

Respect the V2 settlement report's 90-day limit

This report only accepts a start date within the last 90 days. For older settlement history, use ledger detail or ledger summary view data instead.

Remember Orders reflects updates, not just new orders

Re-running a date range on Orders or Order items will include any order updated in that window, including status changes on older orders. If you're building a "new orders per day" dashboard, filter downstream on the order's purchase date rather than assuming every synced row is a new order.

Common pitfalls

Don't schedule the Orders or Order items entity to run every few minutes across multiple data flows — Amazon's rate limit is shared across your account, so concurrent syncs will slow each other down rather than speeding up delivery.

Do

• Match your SP-API region to where your Seller Central account is registered
• Keep report entities in a separate, less-frequent schedule from Orders and Order items
• Reconcile settlement and ledger data against completed periods only

Don't

• Set a start date beyond 90 days for the V2 settlement report — it will fail
• Expect Vendor forecasting reports to reflect Seller Central marketplace data
• Assume every row from an Orders re-sync is a new order — it may be an update to an existing one