> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/sources/category/ecommerce/amazon-seller-central/best-practices.md).

# Best Practices

## Recommended setup

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Match your SP-API region to your account</strong></td><td>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.</td></tr><tr><td><strong>Start with Orders and a short date range</strong></td><td>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.</td></tr><tr><td><strong>Separate core entities from report entities</strong></td><td>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.</td></tr></tbody></table>

## Data refresh and scheduling

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Don't over-schedule Orders</strong></td><td>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.</td></tr><tr><td><strong>Give report entities a longer schedule</strong></td><td>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.</td></tr><tr><td><strong>Vendor forecasting reports don't need frequent refreshing</strong></td><td>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.</td></tr></tbody></table>

## Performance optimization

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Join Orders with Order items</strong></td><td>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.</td></tr><tr><td><strong>Use ledger summary instead of ledger detail when possible</strong></td><td>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.</td></tr><tr><td><strong>Keep incremental windows narrow on scheduled runs</strong></td><td>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.</td></tr></tbody></table>

## Dashboard accuracy

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Reconcile against completed settlement periods</strong></td><td>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.</td></tr><tr><td><strong>Respect the V2 settlement report's 90-day limit</strong></td><td>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.</td></tr><tr><td><strong>Remember Orders reflects updates, not just new orders</strong></td><td>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.</td></tr></tbody></table>

## Common pitfalls

{% hint style="danger" %}
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.
{% endhint %}

{% columns %}
{% column %}

### 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
  {% endcolumn %}

{% column %}

### 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
  {% endcolumn %}
  {% endcolumns %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.coupler.io/sources/category/ecommerce/amazon-seller-central/best-practices.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
