Commerce integration guide
Amazon Seller Central + UbiGrowth workflows
Amazon Seller Central is Amazon's seller platform, owning listings, orders, and marketplace performance data. This guide covers the records that matter, how the connection should be scoped, and what the first bounded workflow should be.
Introduction
Make Amazon Seller Central part of the workflow, not another silo.
Validate connector availability for your workspace
This guide covers how a team designs a commerce workflow around Amazon Seller Central with UbiGrowth: which records stay authoritative, how the connection should be scoped, what the first bounded workflow should be, and how to tell whether it worked.
The records that matter are Order, Listing, FBA Inventory, Shipment, Settlement Report, Feed, and A-to-z Claim. Amazon identifies products by ASIN and your stock by SKU, and the mapping between them is per-marketplace. The same SKU across marketplaces is separate inventory with separate listings.
Amazon Seller Central is not currently on UbiVibe's verified connector list. This page is an implementation design reference: use it to specify the workflow, then validate whether the connection is available and correctly scoped for your workspace before you make it a dependency. The verified UbiVibe connections today are Salesforce, HubSpot, Gmail, Google Drive, Slack, and GitHub.
Grow is the usual destination for this connection, because the value shows up as outreach, reply handling, scheduling, and pipeline execution against the connected records.
Why teams evaluate this connection
Integrations create value when they remove operating friction.
The first design decision is not which API endpoint to call; it is which system owns the record, what event should trigger work, who owns the exception path, and what successful completion means.
Commerce platforms generate a continuous stream of events, and most merchants use almost none of it. Amazon Seller Central records what was ordered and by whom, but the follow-up, retention, and service work that should follow from that record usually happens in a different tool with a different view of the customer.
The result is that the same customer is treated as new by marketing, as an order number by fulfilment, and as an unknown by support, which is exactly the experience that erodes repeat purchase rates.
You're likely here because
- Order data and customer follow-up live in separate tools
- Support answers order questions without order context
- Lifecycle campaigns run against stale exported segments
Record model
What a Amazon Seller Central integration actually reads and writes.
Integration design starts from the objects the system really exposes, not from a generic connector diagram. These are Amazon Seller Central's.
Identity and matching
Amazon identifies products by ASIN and your stock by SKU, and the mapping between them is per-marketplace. The same SKU across marketplaces is separate inventory with separate listings.
Start here
Read Settlement Reports and reconcile fees against orders, since per-order profitability is not visible anywhere in the order data itself.
What this will not do
It will not surface the customer. Amazon owns the buyer relationship; the integration operates on inventory, fulfilment, and settlement.
The constraint to plan around
Selling Partner API access is rate-limited per operation and most reporting is asynchronous — you request a report, poll for it, then download. Designs that expect synchronous reads do not work.
Build notes
What you actually have to reason about in Amazon Seller Central.
The fields that carry meaning, how the connection authenticates, and whether the event surface can be trusted. This is the part that decides whether the integration works in month three.
| Field | Why it matters |
|---|---|
| ASIN vs SKU | Amazon's product identity versus yours, mapped per marketplace |
| marketplace id | the same SKU across marketplaces is separate inventory and separate listings |
| settlement report fees | the only place per-order profitability becomes visible |
| fulfillment channel | FBA versus merchant-fulfilled, with entirely different operational models |
| order status | including pending, where buyer details are deliberately withheld |
Authentication
Selling Partner API with LWA credentials and an IAM role, plus restricted data tokens for personally identifiable information. The onboarding is genuinely involved and is a project rather than a configuration step.
Events and delivery
Notifications are available through SQS or EventBridge. Most reporting is asynchronous: request a report, poll for readiness, then download — synchronous designs simply do not work here.
Workflow
How the Amazon Seller Central workflow runs.
The operating sequence, from reading the source system through to the result landing back where it belongs.
Step 01
Read order and customer state
Connected Amazon Seller Central data provides the real order, customer, and fulfilment state rather than a periodic export.
Step 02
Resolve the customer
The customer is matched across order, marketing, and support systems using a defined rule, including the ambiguous case.
Step 03
Trigger from a real event
Follow-up is driven by an actual order or fulfilment event, so the message matches the customer experience.
Step 04
Run the lifecycle action
Post-purchase, exception, or repeat-purchase follow-up runs with the product and timing context attached, under review while it is being proven.
Design decisions
The commerce decisions this connection forces.
Each of these has to be settled before the Amazon Seller Central workflow is allowed to write anything.
Step 01
Resolve the customer across channels
Decide how a customer in Amazon Seller Central is matched to the same person in marketing, support, and any other channel, including what happens when the match is ambiguous.
Step 02
Treat order state as the trigger
Follow-up should be driven by real order and fulfilment state rather than by a periodic export, otherwise the message and the customer experience diverge.
Implementation path
How to implement the Amazon Seller Central workflow.
- 01
Decide which records Amazon Seller Central owns and which the workflow may act on, starting read-only.
- 02
Define the customer identity match across order, marketing, and support systems before enabling any follow-up.
- 03
Pick one lifecycle moment — post-purchase, fulfilment exception, or repeat-purchase timing — and instrument only that.
- 04
Once settlement reconciliation works, add per-SKU profitability so assortment decisions use margin after fees rather than revenue.
Governance
Controls that matter.
Control 01
Order, refund, and fulfilment changes require explicit authorization rather than automated convenience.
Control 02
Customer messaging honours consent, preference, and channel rules.
Control 03
Payment and personal data stay in the systems that already govern them, at scoped access.
Failure modes
How a Amazon Seller Central integration breaks in production.
Not generic integration advice. These follow from how this system actually behaves, which is why they look nothing like the list on the next guide over.
Symptom 01
A feed reports as submitted and nothing changes.
Cause
Processing errors appear in a separate result document, not in the submission response.
Fix
Always retrieve and parse the processing report; the submission response proves nothing.
Symptom 02
Listings are suppressed after an update.
Cause
A feed contained invalid data that Amazon accepted and then rejected downstream.
Fix
Validate before submission and monitor listing status after, not just feed status.
Symptom 03
Reports are requested and never arrive.
Cause
Report generation is asynchronous and the polling gave up too early.
Fix
Poll with backoff over a realistic window; some reports take considerable time.
What changes at scale
Rate limits are per operation with a token-bucket model, and most reporting is asynchronous. The architecture must be queue-based rather than request-response.
Examples
What a working Amazon Seller Central workflow looks like.
Bounded scenarios rather than a feature list. Each one can be verified against work the team already does.
Marketplace operations
With Amazon Seller Central connected, follow-up runs against real order and customer state rather than a segment exported last month.
Post-purchase lifecycle
A specific order event in Amazon Seller Central triggers follow-up with the product and timing context attached, instead of a generic scheduled campaign.
Limitations and considerations
What to validate before you depend on this.
- Selling Partner API access is rate-limited per operation and most reporting is asynchronous — you request a report, poll for it, then download. Designs that expect synchronous reads do not work.
- Feed submissions change listings and inventory across a marketplace, processed asynchronously with errors surfacing in a separate result document. A bad feed can suppress listings, and the failure is not in the submission response.
- When customer relationship management is the goal. Amazon owns the buyer relationship, and the integration operates on inventory, fulfilment, and settlement.
- Marketplace and platform policies constrain what can be automated around Amazon Seller Central, particularly for customer contact; check the rules before designing the workflow.
- Order, refund, and fulfilment writes carry direct customer and financial consequences and need explicit authorization.
FAQ
Amazon Seller Central integration questions.
What records does a Amazon Seller Central integration actually work with?
The primary records are Order, Listing, FBA Inventory, Shipment, Settlement Report, Feed, and A-to-z Claim. Amazon identifies products by ASIN and your stock by SKU, and the mapping between them is per-marketplace. The same SKU across marketplaces is separate inventory with separate listings.
What should the first Amazon Seller Central workflow be?
Read Settlement Reports and reconcile fees against orders, since per-order profitability is not visible anywhere in the order data itself.
What will a Amazon Seller Central integration not do?
It will not surface the customer. Amazon owns the buyer relationship; the integration operates on inventory, fulfilment, and settlement.
What is the main constraint to plan around?
Selling Partner API access is rate-limited per operation and most reporting is asynchronous — you request a report, poll for it, then download. Designs that expect synchronous reads do not work.
What changes about a Amazon Seller Central integration at scale?
Rate limits are per operation with a token-bucket model, and most reporting is asynchronous. The architecture must be queue-based rather than request-response.
How does authentication work for Amazon Seller Central?
Selling Partner API with LWA credentials and an IAM role, plus restricted data tokens for personally identifiable information. The onboarding is genuinely involved and is a project rather than a configuration step.
Does Amazon Seller Central support webhooks, and can they be trusted?
Notifications are available through SQS or EventBridge. Most reporting is asynchronous: request a report, poll for readiness, then download — synchronous designs simply do not work here.
What is the risk of writing to Amazon Seller Central?
Feed submissions change listings and inventory across a marketplace, processed asynchronously with errors surfacing in a separate result document. A bad feed can suppress listings, and the failure is not in the submission response.
When is connecting Amazon Seller Central the wrong call?
When customer relationship management is the goal. Amazon owns the buyer relationship, and the integration operates on inventory, fulfilment, and settlement.
What should a Amazon Seller Central integration automate first?
Start with one bounded workflow that removes a measurable handoff, duplicate-entry step, reporting delay, or follow-up gap. Expand only after the first workflow is reliable.
Does UbiGrowth require Amazon Seller Central to be replaced?
No. The operating model is designed around connecting to systems that should remain authoritative and building workflows around them rather than forcing a wholesale replacement.
Is connector availability identical for every workspace?
No. Availability can depend on provider configuration, authentication, scopes, workspace setup, and deployment state. Validate the required connection before treating it as an operational dependency.
Can follow-up be triggered by Amazon Seller Central order events?
Yes, and it should be. Follow-up driven by real order and fulfilment state is materially more accurate than a periodic exported segment.
Can the workflow change orders or issue refunds?
Those actions carry direct customer and financial consequences and require explicit human authorization rather than automated convenience.
How is the same customer recognised across channels?
Through an identity match rule you define, including what happens when a match is ambiguous. Resolution is rarely perfect, so design for the ambiguous case.
How this access is governed
What ARIA is allowed to do in Amazon Seller Central, and who decides.
Connecting Amazon Seller Central is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.
Required permissions
ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.
What it can reach
Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.
What it can do
Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.
Credential handling
Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.
Action logging
Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.
Approval and revocation
Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.
Start with ARIA
Ask ARIA to run this integration.
Describe the outcome you need across this system. ARIA works out the scopes, data, and actions the job requires, and operates inside the access you grant — which you can change or revoke.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Turn the integration into a working business outcome.
Start with ARIA to describe the outcome, then continue into the product path that fits the workflow. Connector availability and required scopes should be validated for the specific workspace before production use.