.png)
Amazon Selling Partner API Integration Guide
Connect Amazon marketplace, order, catalog, inventory, fulfillment, finance, report, feed, and notification capabilities with enterprise systems through authenticated REST workflows.
Amazon Selling Partner API integration options at a glance
Amazon Selling Partner API is primarily a versioned collection of REST APIs for orders, listings, catalog items, inventory, fulfillment, finance, reports, feeds, and notifications. Applications authenticate with Login with Amazon, AWS Signature Version 4, application roles, and, where required, Restricted Data Tokens. Amazon also supports selected event notifications through configured destinations, while reports and feeds provide asynchronous document-based processing. Martini can consume signed REST endpoints, receive supported notification deliveries, submit and retrieve reports or feeds, parse documented documents, and orchestrate scheduled or event-driven synchronization with enterprise applications and databases.
| Integration point | Supported by Amazon Selling Partner API? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Orders, Order Items, Listings Items, Catalog Items, Product Pricing, Inventory Summaries, Finances, Fulfillment, Sellers, Notifications, and Tokens operations. | Martini can consume versioned REST endpoints, construct signed requests, handle pagination, transform JSON, and orchestrate downstream writes. |
| Webhooks / outbound callbacks | Limited | Selected Amazon SP-API event notifications delivered through configured destinations such as Amazon SQS or Amazon EventBridge. | Martini can receive supported notification deliveries through an exposed API or webhook-oriented workflow, then retrieve current resource details from SP-API. |
| Bulk / async / batch APIs | Yes | Reports and feeds use asynchronous request, status, document, and processing-result flows; other bulk capabilities vary by API. | Martini can submit operations, persist identifiers, poll with bounded intervals, retrieve results, and route processing errors. |
| File / document exchange | Yes | Report and feed documents may contain CSV, tab-separated, JSON, or other documented formats and may require decompression or decryption. | Martini can download or upload documents, apply custom processing where needed, parse files, validate results, and store metadata. |
| Authentication | Yes | Login with Amazon authorization, LWA access tokens, AWS Signature Version 4, application roles, and Restricted Data Tokens for permitted restricted operations. | Martini can store credentials and tokens in secure configuration, obtain or refresh authorization, construct required headers, and apply signing logic. |
| Incremental synchronization | Yes | Order time windows, status filters, reports, notifications, continuation tokens, timestamps, and persisted marketplace checkpoints support incremental processing. | Martini workflows can persist checkpoints, continuation tokens, operation identifiers, and seller-marketplace scope between runs. |
| SDKs | Limited | Amazon publishes models and developer resources, while community or generated SDKs may be used outside Martini. | A Martini workflow can call documented HTTP endpoints without an SDK; custom JVM-compatible logic can support signing or document processing when required. |
| Database access | No | Amazon does not expose seller or vendor database access as an SP-API integration mechanism. | Martini should use documented APIs, reports, feeds, notifications, and supported destinations, then write permitted data to an enterprise database. |
How Amazon Selling Partner API exposes data and business events
Amazon SP-API REST APIs
Amazon Selling Partner API is primarily a collection of versioned REST APIs covering orders, catalog, listings, inventory, fulfillment, finance, reports, feeds, notifications, sellers, and tokens. Access varies by seller or vendor authorization, marketplace, application role, and API version.
Martini implementation pattern
Martini implementation pattern: a workflow obtains or refreshes authorization, builds the regional endpoint and Amazon headers, signs the request with AWS Signature Version 4, calls the selected operation, handles pagination or continuation tokens, and maps the response into a target model.
Implementation sequence
Amazon Notifications API
Amazon supports notifications for selected SP-API events through configured destinations such as Amazon SQS or Amazon EventBridge. Notification coverage is event-specific and is not a universal webhook for every Amazon object or state transition.
Martini implementation pattern
Martini implementation pattern: receive a supported notification through an exposed API or webhook-oriented workflow, validate and record the delivery, then call SP-API to retrieve the current order, listing, catalog, or other resource data. Scheduled reconciliation complements event processing where coverage is incomplete.
Implementation sequence
Amazon Reports and Feeds
Reports and feeds provide asynchronous document-based processing. A report or feed is submitted, processed by Amazon, associated with a document or result, and then downloaded or retrieved for parsing and validation.
Martini implementation pattern
Martini implementation pattern: submit the report or feed request, persist its identifier and scope, poll at controlled intervals, retrieve the resulting document, apply required decompression or decryption, parse the documented format, and route processing errors separately from transient API failures.
Implementation sequence
Incremental Synchronization
Amazon supports incremental processing through order time windows and status filters, reports, notification events, continuation tokens, timestamps, and persisted identifiers. The appropriate method depends on the resource and API version.
Martini implementation pattern
Martini implementation pattern: maintain a checkpoint for each seller and marketplace, retrieve the next page or time window, process data idempotently, and advance the checkpoint only after the target write succeeds. A scheduled reconciliation workflow can detect missed notifications or incomplete runs.
Implementation sequence
Common Amazon Selling Partner API integration patterns
Pattern 1: Sync Amazon orders to an ERP
When to use this pattern
Use this pattern when Amazon orders must become sales orders, fulfillment work, or accounting inputs in an ERP. It combines incremental retrieval with Order Items lookup, restricted-data controls, identifier correlation, and duplicate protection.
Integration direction
Example Mapping
| Amazon Selling Partner API Field | Canonical Field | Target Field |
|---|---|---|
| AmazonOrderId | externalOrderId | externalId |
| PurchaseDate | orderDate | tranDate |
| OrderStatus | orderStatus | status |
| OrderItems.OrderItemId | externalLineId | line.externalId |
Martini implementation pattern
A scheduled Martini workflow queries Orders by marketplace and time window, follows pagination, retrieves Order Items, and maps orders, taxes, shipping, and fulfillment status to the ERP. It stores the last successful checkpoint and Amazon identifiers, applies restricted-data rules, and routes authorization, validation, and transient API failures through differentiated retry paths.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- idempotency
- error handling
Pattern 2: Synchronize Amazon inventory and listings
When to use this pattern
Use this pattern when seller SKUs, available quantities, listing status, and marketplace-specific product information must remain aligned between Amazon and an inventory or commerce platform.
Integration direction
Example Mapping
| Amazon Selling Partner API Field | Canonical Field | Target Field |
|---|---|---|
| SellerSKU | sku | sku |
| MarketplaceId | marketplaceId | channelId |
| Quantity | availableQuantity | inventoryQuantity |
| ListingStatus | listingStatus | status |
Martini implementation pattern
Martini retrieves Inventory Summaries and Listings Items, applies safety-stock and fulfillment-channel rules, and maps the result to the target platform. Supported updates can be sent through Listings Items operations or feeds; the workflow polls feed processing, captures validation errors, and avoids repeating successful inventory changes.
Martini capabilities used
- workflow orchestration
- REST API consumption
- mapping and transformation
- conditional routing
- feed processing
- retry and exception handling
Pattern 3: Load Amazon reports into a data warehouse
When to use this pattern
Use this pattern for settlement, inventory, order, listing, or operational reporting when the required report type is available to the authorized application.
Integration direction
Example Mapping
| Amazon Selling Partner API Field | Canonical Field | Target Field |
|---|---|---|
| ReportId | sourceOperationId | report_id |
| ReportDocumentId | sourceDocumentId | document_id |
| AmazonOrderId | orderId | amazon_order_id |
| SettlementId | settlementId | settlement_id |
Martini implementation pattern
A scheduled workflow requests a report, persists its identifier, polls until completion, retrieves and processes the document, and loads normalized data into Snowflake. Martini can validate expected columns, retain source metadata, quarantine malformed rows, and retry only transient API or storage failures.
Martini capabilities used
- scheduler triggers
- asynchronous orchestration
- file and document processing
- JSON and tabular data handling
- data validation
- database integration
- monitoring
Pattern 4: Process Amazon notifications with reconciliation
When to use this pattern
Use this pattern when selected Amazon events should trigger near-real-time processing while a scheduled reconciliation process protects against missed, duplicated, or incomplete notification deliveries.
Integration direction
Example Mapping
| Amazon Selling Partner API Field | Canonical Field | Target Field |
|---|---|---|
| NotificationId | eventId | correlation_id |
| NotificationType | eventType | event_type |
| SellerId | sellerId | seller_id |
| EventTime | occurredAt | opened_at |
Martini implementation pattern
Martini receives supported notification deliveries, validates and records the event, retrieves current SP-API resource details, and updates the target system or creates an operational exception. A scheduled workflow reconciles recent orders, listings, or feeds so event coverage gaps do not permanently lose business state.
Martini capabilities used
- webhook-oriented workflows
- API exposure
- REST API consumption
- event deduplication
- business rules
- scheduled reconciliation
- operational error handling
Applications commonly integrated with Amazon Selling Partner API
Amazon Selling Partner API commonly participates in commerce, ERP, fulfillment, accounting, analytics, and operational workflows. The following are typical enterprise architecture targets; exact data access depends on authorization, marketplace scope, and Amazon data-protection requirements.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Synchronize products, inventory, prices, and orders between a direct-to-consumer storefront and Amazon marketplaces. | Shopify → Martini → Amazon Selling Partner API | Use scheduled or event-oriented workflows to normalize Shopify products and inventory for Amazon operations, while retrieving Amazon Orders and Order Items for downstream commerce processing. Apply SKU, marketplace, safety-stock, and duplicate-order rules before writing results. |
| NetSuite | Consolidate Amazon orders, fulfillment status, inventory, fees, and settlement-related information in an ERP. | Amazon Selling Partner API → Martini → NetSuite | Retrieve Orders, Order Items, Inventory Summaries, and permitted Financial Events; map them to NetSuite sales orders, fulfillment, inventory, and accounting structures. Persist Amazon identifiers and checkpoints so retries remain idempotent. |
| Salesforce | Provide sales and service teams with marketplace order, seller-operation, and exception visibility subject to Amazon data restrictions. | Amazon Selling Partner API → Martini → Salesforce | Use a Martini workflow to retrieve permitted Amazon data, apply restricted-data controls, and map orders or operational exceptions to Salesforce objects. Route authorization and validation failures to an exception workflow rather than retrying them indefinitely. |
| Microsoft Dynamics 365 | Synchronize Amazon sales, inventory, fulfillment, and finance data with ERP and supply-chain processes. | Amazon Selling Partner API → Martini → Microsoft Dynamics 365 | Orchestrate marketplace-specific reads and updates, normalize seller SKUs and marketplace IDs, and map Amazon order and inventory data into Dynamics 365. Use per-marketplace checkpoints, throttling controls, and reconciliation workflows. |
| ShipStation | Send Amazon orders for shipping and returns processing and make tracking or shipment status available to operational systems. | Amazon Selling Partner API → Martini → ShipStation | Retrieve Orders and Order Items, validate fulfillment-channel rules, and create ShipStation shipments. Process returned tracking or fulfillment updates through a separate workflow and correlate all activity with Amazon order identifiers. |
| QuickBooks Online | Transfer permitted order, fee, payout, or settlement summaries into accounting workflows. | Amazon Selling Partner API → Martini → QuickBooks Online | Use reports or Financial Events to create normalized accounting summaries, apply period and fee-classification rules, and write approved results to QuickBooks Online. Preserve source report and operation identifiers for reconciliation. |
| Snowflake | Centralize Amazon reports, order data, inventory data, and financial events for analytics and reconciliation. | Amazon Selling Partner API → Martini → Snowflake | Schedule report requests, poll processing status, retrieve and parse report documents, validate schemas, and load normalized rows into Snowflake. Store report metadata and processing checkpoints alongside the data load. |
| ServiceNow | Create operational incidents or fulfillment exceptions when Amazon feeds, listings, orders, or processing workflows fail. | Amazon Selling Partner API → Martini → ServiceNow | Route permanent feed errors, authorization failures, and repeated synchronization exceptions from Martini workflows to ServiceNow with marketplace, seller, operation, and correlation identifiers. |
How to build a Amazon Selling Partner API integration in Martini
Objective
Configure Amazon seller or vendor authorization, marketplace scope, regional endpoint, LWA credentials, AWS signing values, application roles, and any Restricted Data Token process.
Instructions in Martini
- Store LWA, AWS, seller, marketplace, and signing configuration as secure environment values or secrets.
- Confirm that the authorized application has the roles required for the selected SP-API operations.
- Keep seller and marketplace configuration separate when one workflow serves multiple scopes.
Objective
Select a scheduled, notification-driven, or API-driven entry point based on the Amazon resource and the required timeliness.
Instructions in Martini
- Use a scheduler for incremental Orders, Inventory Summaries, reports, or reconciliation.
- Use a notification-oriented workflow only for supported Amazon event types.
- Expose a controlled Martini API when another application must initiate a report or synchronization job.
Objective
Call the relevant Amazon REST resource or submit an asynchronous report or feed operation while preserving identifiers and scope.
Instructions in Martini
- Construct and sign the SP-API request with the required access token and headers.
- Follow continuation tokens and persist operation identifiers.
- Poll reports and feeds with bounded, rate-aware intervals.
Objective
Coordinate calls, pagination, asynchronous status checks, document retrieval, and downstream processing as a durable Martini workflow.
Instructions in Martini
- Separate transient API failures from permanent authorization or validation failures.
- Correlate every operation with seller, marketplace, Amazon identifier, and workflow run context.
- Use conditional branches for restricted data, feed errors, and incomplete results.
Objective
Convert Amazon Orders, Order Items, listings, inventory, reports, or notifications into a canonical model and target-specific structure.
Instructions in Martini
- Map stable Amazon identifiers, marketplace IDs, SKUs, dates, quantities, and monetary values explicitly.
- Parse CSV, tab-separated, JSON, compressed, or encrypted report and feed documents when required.
- Validate required fields and route malformed rows or schema mismatches to an exception path.
Objective
Apply marketplace, fulfillment-channel, safety-stock, privacy, accounting, and duplicate-prevention rules before writing to target systems.
Instructions in Martini
- Use idempotency keys based on Amazon order, item, report, feed, SKU, or notification identifiers.
- Avoid logging restricted personal data or sensitive document contents.
- Advance synchronization checkpoints only after successful target processing.
Common Amazon Selling Partner API data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Orders | Retrieve customer orders, status, marketplace, fulfillment channel, shipping information, and order dates. | ERP, commerce platforms, fulfillment applications, finance systems, and data warehouses. | Martini retrieves orders incrementally, follows continuation tokens, applies restricted-data controls, maps stable identifiers, and enforces idempotent writes. |
| Order Items | Provide products, quantities, prices, promotions, tax, and item-level order details. | ERP, fulfillment, accounting, commerce, and analytics applications. | Martini retrieves items after identifying orders, normalizes monetary and quantity fields, validates SKU or product references, and correlates them to the parent Order. |
| Listings Items | Represent seller listings identified by SKU, including attributes, status, and issues. | Inventory platforms, commerce applications, product systems, and operational queues. | Martini maps SKU, marketplace, status, and issue data, applies listing validation rules, and can submit supported updates or feed operations. |
| Catalog Items | Represent Amazon catalog products identified by ASIN or other product identifiers. | Product information systems, commerce platforms, inventory systems, and data warehouses. | Martini retrieves catalog data, maps ASIN and product attributes to a canonical model, and handles marketplace-specific differences. |
| Inventory Summaries | Provide seller inventory quantities across marketplaces and fulfillment channels. | ERP, inventory management, commerce platforms, fulfillment systems, and analytics platforms. | Martini applies safety-stock and fulfillment-channel rules, maps seller SKUs and marketplace IDs, and persists synchronization checkpoints. |
| Reports | Support asynchronous extraction of settlement, inventory, order, listing, and operational data where an authorized report type exists. | Data warehouses, databases, ERP, finance applications, and file stores. | Martini requests reports, polls status, retrieves documents, decrypts or decompresses when required, parses content, validates schemas, and records audit metadata. |
Authentication and security considerations
Authentication and authorization
Amazon Selling Partner API generally combines Login with Amazon authorization, LWA access tokens, AWS Signature Version 4 request signing, application roles, and seller or vendor authorization. Restricted operations may additionally require a Restricted Data Token.
Martini can keep client credentials, refresh tokens, AWS credentials, signing configuration, seller identifiers, and marketplace settings in secure environment configuration or secrets. Workflows should request only the permissions and data required for the business process.
Data protection
- Control access to restricted order and customer data.
- Avoid writing sensitive fields or downloaded report contents to general logs.
- Keep seller, marketplace, authorization, and checkpoint scope isolated.
- Use HTTPS and the Amazon-required request headers and signing process.
Operational considerations for Amazon Selling Partner API integrations
Rate limits and retries
SP-API usage plans and throttling are operation-specific. Inspect throttling responses and headers, use exponential backoff with jitter, reduce unnecessary polling, and queue high-volume work.
Pagination and checkpoints
Persist continuation tokens, timestamps, seller scope, marketplace IDs, and the last successful target write. Do not treat an empty page as completion unless the relevant API contract supports that interpretation.
Reports and feeds
Record request identifiers, processing status, document identifiers, download status, parsing status, and result details. Documents may be compressed, encrypted, or tabular rather than ordinary JSON.
Reliability and change management
- Use stable Amazon identifiers for idempotency and duplicate protection.
- Retry transient throttling and service failures, but route permanent validation and authorization failures to exception handling.
- Keep endpoint versions and report types configurable.
- Test marketplace-specific behavior and monitor schema or API-version changes.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than individual API calls
Amazon integrations often combine signed REST requests, pagination, restricted-data authorization, asynchronous reports or feeds, document processing, notifications, and downstream writes. Martini represents that behavior as maintainable workflows rather than isolated scripts.
Centralize transformation and control
Martini provides reusable mappings, validation, business rules, checkpoints, idempotency, retries, and exception paths. The same patterns can serve multiple sellers, marketplaces, and target applications without duplicating integration logic.
Expose reusable integration assets
Martini can consume Amazon API definitions and endpoints, expose controlled APIs for internal consumers, and combine scheduled and event-oriented processing. This supports enterprise governance while retaining custom logic where signing or document processing requires it.
Frequently asked questions
Amazon Selling Partner API can be integrated through its versioned REST APIs for orders, catalog, listings, inventory, fulfillment, finance, reports, feeds, notifications, and seller operations. Reports and feeds support asynchronous document processing, while selected notifications can be delivered through configured Amazon destinations.
Yes. Martini can integrate with Amazon Selling Partner API by consuming its authenticated REST endpoints, submitting and retrieving report or feed documents, receiving supported notification deliveries, and orchestrating synchronization with enterprise applications and databases.
No. A dedicated Amazon Selling Partner API connector is not required. Martini can use Amazon's native REST APIs, authentication and signing requirements, reports, feeds, and supported notification mechanisms.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Amazon Selling Partner API. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Amazon, infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are the primary method for current integrations. Use reports and feeds for asynchronous or bulk document processing, and use the Notifications API for selected event types where configured. GraphQL, SOAP, and direct database access are not identified as SP-API integration methods in the supplied research.
Amazon supports notifications for selected SP-API events through configured destinations such as Amazon SQS or Amazon EventBridge. This is not a universal webhook for every order or marketplace change, so a scheduled reconciliation workflow may be needed alongside notification processing.
Synchronization can use order time windows, status filters, reports, notification-triggered detail retrieval, continuation tokens, and persisted timestamps or identifiers. Martini can maintain independent checkpoints for sellers and marketplaces, apply idempotency, and advance checkpoints only after successful target writes.
Martini can map Amazon JSON and report or feed documents into canonical and target-specific models, apply validation and business rules, and distinguish throttling or temporary service failures from permanent authorization and data errors. It can also expose a controlled REST API façade for initiating workflows or retrieving processing status.
Related Martini documentation
Martini APIs
Workflows
Connect Amazon Selling Partner API with Martini
Use Martini to build governed workflows for Amazon orders, inventory, listings, reports, feeds, notifications, and enterprise data synchronization.