.png)
SPS Commerce Integration Guide
Connect SPS Commerce retail supply-chain and EDI processes with enterprise systems through REST APIs, OAuth 2.0, and configured business-document exchange.
SPS Commerce integration options at a glance
SPS Commerce integrations primarily use documented REST APIs for fulfillment and supply-chain operations, including Orders, Shipments, Invoices, Products, and Inventory. Its broader platform also supports electronic business-document exchange, although the exact document format and transport depend on the customer’s product and trading-partner configuration. API access generally uses OAuth 2.0 bearer tokens. A universal webhook model, bulk API, GraphQL API, or SOAP API was not confirmed, so scheduled polling with pagination and incremental filters may be required. Martini can manage secrets, authenticate requests, orchestrate workflows, transform data, process files where an applicable exchange is available, and expose APIs for connected systems.
| Integration point | Supported by SPS Commerce? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | SPS Commerce documents REST-based fulfillment and supply-chain APIs for Orders, Shipments, Invoices, Products, and Inventory. Exact resources depend on the provisioned API product and tenant. | Martini can consume SPS Commerce REST endpoints from workflows, manage request configuration, transform responses, and route results to enterprise applications. |
| OAuth 2.0 authentication | Yes | API access generally uses client credentials and bearer tokens issued by the SPS Commerce authorization service. Scopes, token URLs, and permissions depend on the tenant and product. | Martini can store client credentials and token settings as environment-specific secrets, obtain or refresh tokens, and attach bearer authentication to API requests. |
| EDI and managed business-document exchange | Yes | SPS Commerce supports electronic trading-partner document exchange for supply-chain transactions. The exact documents, formats, and transport are customer- and partner-specific. | Martini can orchestrate supported API or file exchanges, transform document structures, apply partner-specific rules, and coordinate downstream processing when the transport is available. |
| File and attachment exchange | Limited | Business documents may be represented as structured API resources, EDI transactions, or files. A universal SPS Commerce attachment API or transport was not confirmed. | Martini can process files through an available supported exchange endpoint or transport, but the SPS Commerce-specific file connection and document model must be confirmed first. |
| Webhooks and outbound callbacks | Not confirmed | A general webhook model for all Order, Shipment, Invoice, Product, or Inventory changes was not confirmed. Selected callbacks may depend on the provisioned SPS Commerce service. | Martini can expose an API endpoint for documented callbacks, or use scheduled workflows and incremental polling when notifications are unavailable. |
| Bulk, asynchronous, or batch APIs | Not confirmed | Bulk or asynchronous behavior may differ by SPS Commerce API product and tenant and was not confirmed as universal. | Martini can batch workflow processing, paginate responses, checkpoint progress, and apply retries around documented endpoints without assuming a native bulk API. |
| Scheduled synchronization | Not applicable | Scheduled polling may be required when event notifications are unavailable or limited. Polling should use documented incremental filters, cursors, or status criteria where available. | Martini can trigger workflows on a schedule, retrieve pages of changes, persist checkpoints, and reconcile late or corrected documents. |
How SPS Commerce exposes data and business events
SPS Commerce REST APIs
SPS Commerce provides REST-based developer resources for fulfillment and supply-chain integrations. Depending on the provisioned product, REST operations may cover Orders, Shipments, Invoices, Products, and Inventory, with resource names, fields, filters, and permissions varying by tenant.
Martini implementation pattern
Martini uses a workflow to obtain an OAuth 2.0 bearer token, call the relevant SPS Commerce endpoint, paginate or filter the response, and transform the result for an ERP, commerce, warehouse, or marketplace application. For outbound transactions, Martini validates and maps the source payload before submitting it and storing the returned transaction or correlation identifier.
Implementation sequence
EDI and managed document exchange
SPS Commerce supports electronic exchange of supply-chain business documents, including order, shipment, and invoice processes. The exact document standards, transport, and customer configuration must be confirmed rather than assumed.
Martini implementation pattern
Where the customer has an available file or managed-exchange endpoint, Martini can coordinate document movement, parse or generate the applicable payload, apply partner-specific mappings, and invoke downstream APIs or applications. Martini should treat the configured transport and document contract as implementation inputs.
Implementation sequence
Selected callbacks or notifications
A universal SPS Commerce webhook capability was not confirmed. Some provisioned services may support callbacks or notifications for selected events, but event coverage must be verified for the customer’s product and tenant.
Martini implementation pattern
If SPS Commerce documents a callback for the required event, Martini exposes a secured API endpoint that validates the request and starts a workflow. If no callback is available, the equivalent workflow uses scheduled polling, pagination, and incremental filters rather than assuming real-time delivery.
Implementation sequence
Common SPS Commerce integration patterns
Pattern 1: Sync SPS Commerce Orders to an ERP
When to use this pattern
Use this pattern when retailer or supplier Orders must be created in an ERP or order-management application. Scheduled retrieval is appropriate when callbacks are not available, while documented incremental filters or status criteria reduce repeated processing.
Integration direction
Example Mapping
| SPS Commerce Field | Canonical Field | Target Field |
|---|---|---|
| Order identifier | sourceOrderId | externalId |
| Trading-partner identifier | partnerId | customerOrVendorId |
| Line SKU and quantity | lines[].itemCode and lines[].quantity | items[].sku and items[].quantity |
| Requested date | requestedDate | shipDate |
Martini implementation pattern
A scheduled Martini workflow retrieves paginated Orders, validates partner and item data, maps them to the ERP order model, and applies an idempotency key based on the SPS Commerce order identifier and version. Transient API failures are retried with backoff, while invalid documents are routed to an exception process without creating a partial order.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Send fulfillment Shipments to SPS Commerce
When to use this pattern
Use this pattern when an ERP or warehouse application needs to send retailer-facing shipment confirmations through SPS Commerce. It supports carrier, tracking, package, and item-quantity transformation before submission.
Integration direction
Example Mapping
| SPS Commerce Field | Canonical Field | Target Field |
|---|---|---|
| Shipment identifier | shipmentId | shipmentReference |
| Carrier code | carrierCode | carrier |
| Tracking number | trackingNumber | trackingDetails.number |
| Shipped item quantity | lines[].shippedQuantity | items[].quantity |
Martini implementation pattern
Martini receives shipment data through an API or scheduled retrieval, validates quantities against the source order where available, maps carrier and tracking values to the SPS Commerce structure, and submits the transaction. The workflow records the source and destination identifiers so retries do not create duplicate shipment confirmations.
Martini capabilities used
- APIs
- workflow orchestration
- data mapping
- validation
- idempotency
- error handling
Pattern 3: Process SPS Commerce Invoices
When to use this pattern
Use this pattern when invoices exchanged through SPS Commerce must be posted to an accounting or ERP system after fulfillment. It is useful for centralizing duplicate detection, reconciliation, and trading-partner validation.
Integration direction
Example Mapping
| SPS Commerce Field | Canonical Field | Target Field |
|---|---|---|
| Invoice number | invoiceNumber | invoiceNumber |
| Order reference | sourceOrderId | orderReference |
| Invoice line amount | lines[].amount | lines[].lineAmount |
| Tax amount | taxAmount | taxAmount |
Martini implementation pattern
A Martini workflow retrieves or receives Invoices, validates references and amounts, maps the document into Oracle Fusion Cloud Applications, and checks the invoice number and source transaction before creation. Authentication failures, schema errors, and trading-partner rejections are handled separately so accepted and rejected documents remain reconcilable.
Martini capabilities used
- API consumption
- data mapping
- business rules
- validation
- error handling
- monitoring
Pattern 4: Synchronize Products and Inventory
When to use this pattern
Use this pattern when product catalog and availability data must be synchronized between SPS Commerce, a commerce application, and an ERP or marketplace. It can use scheduled incremental processing when real-time notifications are not confirmed.
Integration direction
Example Mapping
| SPS Commerce Field | Canonical Field | Target Field |
|---|---|---|
| SKU | itemCode | sku |
| Location identifier | locationId | location |
| Available quantity | availableQuantity | available |
| Unit of measure | unitOfMeasure | uom |
Martini implementation pattern
Martini retrieves or accepts changed Products and Inventory, normalizes SKUs, locations, units, and availability rules, then sends the transformed data to SPS Commerce or a connected commerce system. The workflow persists a checkpoint, handles pagination, and rejects ambiguous item mappings rather than publishing inaccurate availability.
Martini capabilities used
- scheduled workflows
- API consumption
- data transformation
- mapping
- checkpointing
- business rules
Applications commonly integrated with SPS Commerce
SPS Commerce commonly sits between retail trading-partner processes and supplier, marketplace, ERP, commerce, and fulfillment applications. The exact exchange method and object coverage depend on the customer’s SPS Commerce product, API entitlement, trading-partner configuration, and downstream application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| NetSuite | Synchronize orders, fulfillment, invoices, products, and inventory between an ERP and SPS Commerce trading-partner processes. | SPS Commerce → Martini → NetSuite | Martini retrieves or receives SPS Commerce business data, maps trading-partner identifiers and document fields into NetSuite structures, applies validation and idempotency rules, and routes rejected transactions for review. |
| SAP S/4HANA | Connect enterprise order, inventory, shipment, and invoice processes with retailer-facing SPS Commerce transactions. | SAP S/4HANA → Martini → SPS Commerce | A Martini workflow accepts fulfillment or master-data changes from SAP, transforms units, identifiers, and line structures, submits the applicable SPS Commerce API or exchange payload, and records transaction outcomes for reconciliation. |
| Microsoft Dynamics 365 | Exchange order, shipment, invoice, item, and inventory data between Dynamics applications and SPS Commerce. | SPS Commerce → Martini → Microsoft Dynamics 365 | Martini uses scheduled API retrieval or an inbound API, normalizes SPS Commerce documents, maps them to Dynamics entities, and separates authentication, validation, transport, and business-rule failures. |
| Shopify | Connect online-store orders and product or inventory information with retail fulfillment and trading-partner processes. | Shopify → Martini → SPS Commerce | Martini receives or retrieves Shopify changes, enriches them with trading-partner and SKU mappings, transforms them into SPS Commerce-compatible structures, and applies duplicate protection before submission. |
| Salesforce | Synchronize customer-facing order or account processes with fulfillment and supply-chain transactions managed through SPS Commerce. | Salesforce → Martini → SPS Commerce | Martini orchestrates Salesforce API calls and SPS Commerce REST requests, using a canonical order or account model and routing incomplete partner, SKU, or address data to an exception workflow. |
| Amazon Seller Central | Coordinate marketplace orders, shipment confirmations, product information, and inventory with broader retail operations. | Amazon Seller Central → Martini → SPS Commerce | A Martini workflow normalizes marketplace order and fulfillment data, maps identifiers and quantities to SPS Commerce structures, submits the applicable transaction, and retries transient failures without duplicating documents. |
| Walmart Marketplace | Exchange marketplace order, inventory, shipment, and item data while retaining SPS Commerce as part of the supply-chain integration layer. | Walmart Marketplace → Martini → SPS Commerce | Martini coordinates marketplace and SPS Commerce API interactions, applies retailer-specific code and unit mappings, checkpoints paginated synchronization, and exposes operational errors for replay. |
| Oracle Fusion Cloud Applications | Connect ERP order-management, inventory, procurement, and receivables processes to SPS Commerce documents. | Oracle Fusion Cloud Applications → Martini → SPS Commerce | Martini maps Oracle order, fulfillment, and receivables data to SPS Commerce documents, validates trading-partner requirements, and records source identifiers and acceptance results for reconciliation. |
How to build a SPS Commerce integration in Martini
Objective
Establish the SPS Commerce API and trading-partner configuration without embedding credentials in workflow payloads or source code.
Instructions in Martini
- Confirm the SPS Commerce API product, tenant, endpoints, scopes, and trading-partner permissions.
- Store OAuth 2.0 client credentials, token settings, API URLs, and partner configuration in environment-specific secrets.
- Use Martini API configuration and authentication settings for the outbound requests.
Objective
Select an event or schedule based on the capabilities confirmed for the customer’s SPS Commerce service.
Instructions in Martini
- Use a documented callback only when the required SPS Commerce event is confirmed.
- Otherwise configure a scheduled workflow for incremental polling.
- Define the polling interval, status or modified-date filters, and checkpoint strategy.
Objective
Obtain the authoritative SPS Commerce object or business document before applying downstream logic.
Instructions in Martini
- Obtain or refresh the OAuth 2.0 bearer token.
- Call the relevant Orders, Shipments, Invoices, Products, or Inventory endpoint.
- Process pagination and continuation information without skipping or repeating pages.
- Retrieve the current resource after a callback or notification when applicable.
Objective
Coordinate validation, transformation, target calls, acknowledgements, and reconciliation in one maintainable integration flow.
Instructions in Martini
- Separate transport, authentication, schema, trading-partner, and business-rule failures.
- Use reusable workflow logic for common token, pagination, logging, and error paths.
- Apply partner-specific rules without assuming one mapping works for every retailer or supplier.
Objective
Convert SPS Commerce structures into the canonical and target application models required by the business process.
Instructions in Martini
- Map identifiers, SKUs, quantities, units, addresses, dates, carrier values, and document references.
- Parse structured documents or supported files when the customer’s exchange method requires it.
- Validate required fields and enumerations before submitting or creating downstream objects.
Objective
Protect downstream systems from duplicates, incomplete documents, and invalid trading-partner data.
Instructions in Martini
- Use stable document identifiers, references, and versions as idempotency keys.
- Distinguish new documents, updates, cancellations, retransmissions, and corrections.
- Route failed documents to an exception or review process with enough context for replay.
Common SPS Commerce data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Orders | Purchase orders or sales-order transactions exchanged between retailers, suppliers, and other trading partners. | NetSuite, SAP S/4HANA, Microsoft Dynamics 365, Shopify, Amazon Seller Central | Martini retrieves or receives Orders, validates trading-partner identifiers, SKUs, quantities, addresses, and dates, then maps them into a canonical order model with idempotency controls. |
| Shipments | Shipment confirmations, shipment details, carrier information, tracking data, and fulfillment status. | SAP S/4HANA, NetSuite, Microsoft Dynamics 365, Walmart Marketplace | Martini maps package, quantity, carrier, tracking, and date fields, submits or publishes the resulting transaction, and separates duplicate or validation failures from transient transport errors. |
| Invoices | Invoices exchanged after fulfillment or shipment processing between trading partners. | NetSuite, Oracle Fusion Cloud Applications, SAP S/4HANA, Microsoft Dynamics 365 | Martini transforms invoice headers, references, line items, taxes, and amounts, checks source identifiers before creation, and routes rejected or unreconciled invoices for review. |
| Products | Product, item, SKU, catalog, and trading-partner item information. | Shopify, Amazon Seller Central, Walmart Marketplace, NetSuite | Martini normalizes SKU identifiers, descriptions, units, status values, and partner-specific codes before synchronizing changed Products or publishing them to downstream systems. |
| Inventory | Available, committed, or location-specific inventory quantities used for fulfillment and commerce availability. | Shopify, Amazon Seller Central, Walmart Marketplace, SAP S/4HANA | Martini maps locations, quantities, units of measure, and availability rules, uses incremental synchronization where documented, and checkpoints large result sets. |
Authentication and security considerations
OAuth 2.0 access
SPS Commerce API access is generally based on OAuth 2.0 client credentials and bearer tokens. Exact token URLs, scopes, token lifetimes, and permission names depend on the SPS Commerce product and tenant.
Environment-specific secrets
Martini can store SPS Commerce client credentials, token settings, API URLs, and trading-partner configuration as protected environment-specific secrets. Credentials should not be placed in workflow payloads or logs.
Inbound API protection
If a documented SPS Commerce callback is available, the Martini API endpoint should be restricted and inbound requests validated before a workflow is started. Separate development, test, and production configurations should be used where supported.
Operational considerations for SPS Commerce integrations
Throttling and pagination
Confirm request limits for the specific SPS Commerce API and tenant. Use documented page, cursor, or continuation-token behavior and persist progress so retries do not skip or repeatedly process data.
Retries and idempotency
Use controlled exponential backoff for transient 429 and 5xx responses. Avoid retrying permanent validation or trading-partner failures, and use stable document identifiers, references, and versions to prevent duplicate Orders, Shipments, or Invoices.
Partner-specific rules
Retailers and suppliers may impose different identifiers, code lists, units of measure, required fields, and validation rules. Keep partner-specific mappings configurable and reconcile submitted documents with accepted or rejected outcomes.
Schema and testing
Monitor SPS Commerce API versions and document requirements. Test representative Orders, Shipments, Invoices, Products, and Inventory data, including corrections, retransmissions, missing fields, and late-arriving documents.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond point-to-point calls
Martini coordinates authentication, API calls, document exchange, validation, mapping, business rules, target writes, and reconciliation in workflows rather than scattering logic across scripts and application-specific integrations.
Reusable integration assets
Common token handling, pagination, error paths, partner mappings, and idempotency logic can be organized into reusable Martini workflows and services while preserving the option for custom logic when required.
Operational control
Martini provides a structured place to manage schedules, retries, checkpoints, exception routing, logging, and environment-specific configuration. This helps teams maintain integrations as SPS Commerce APIs and trading-partner requirements evolve.
Frequently asked questions
SPS Commerce can be integrated through its documented REST APIs for fulfillment and supply-chain processes, OAuth 2.0 authentication, and configured electronic business-document or file exchange. The exact objects, transports, and trading-partner requirements depend on the provisioned SPS Commerce product and tenant.
Yes. Martini can integrate with SPS Commerce by consuming its REST APIs, authenticating with OAuth 2.0, processing supported business-document or file exchanges, and using scheduled workflows when event notifications are unavailable. No native Martini SPS Commerce connector is confirmed in the supplied documentation.
No. A dedicated SPS Commerce connector is not required. Martini can use SPS Commerce’s confirmed REST APIs, OAuth 2.0 authentication, and applicable customer-specific document or file-exchange mechanisms, while exposing APIs for connected systems.
Lonti does not charge an additional per-connector or per-vendor fee to integrate SPS Commerce. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from SPS Commerce, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are the primary method to investigate for current fulfillment and supply-chain integrations. OAuth 2.0 is generally used for API authentication, while EDI or managed business-document exchange may apply depending on the customer configuration. GraphQL and SOAP APIs were not confirmed for new SPS Commerce integrations.
A general webhook model covering all Orders, Shipments, Invoices, Products, and Inventory changes was not confirmed. Selected callbacks may be available for particular SPS Commerce services, but this must be verified. Martini can receive a documented callback or use scheduled polling with pagination and incremental filters.
Synchronization can retrieve or submit Orders, Shipments, Invoices, Products, and Inventory through documented REST endpoints or configured document exchange. Martini can use schedules, incremental filters, pagination, checkpoints, canonical mappings, and reconciliation identifiers to manage recurring synchronization.
Martini can map SPS Commerce fields into canonical and target schemas, apply trading-partner validation and business rules, and separate authentication, transport, schema, and business failures. Stable document identifiers, references, and versions can provide idempotency, while transient failures can use controlled retries and backoff.
Related Martini documentation
API Integration
Workflows
Connect SPS Commerce with your enterprise systems
Use Martini to orchestrate SPS Commerce APIs and configured business-document exchanges across ERP, commerce, warehouse, marketplace, and finance processes.