.png)
ShipStation Integration Guide
Integrate ShipStation with enterprise systems through REST APIs, API-key or OAuth 2.0 authentication, selected webhook notifications, and scheduled synchronization.
ShipStation integration options at a glance
ShipStation’s primary integration mechanism is its REST API, which supports orders, shipments, products, stores, warehouses, carriers, rates, and labels. API-key authentication is commonly used for direct account access, while OAuth 2.0 supports approved application scenarios; earlier API versions may use an API key and secret with Basic Authentication. ShipStation also provides webhook-style notifications for selected order and shipment events, plus some batch or asynchronous shipping operations and label-document retrieval. Martini can consume these APIs, receive callbacks, orchestrate scheduled reconciliation, map payloads, persist synchronization state, and expose a normalized REST API to other systems.
| Integration point | Supported by ShipStation? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | ShipStation REST APIs manage or retrieve Orders, Shipments, Products, Stores, Warehouses, Carriers, rates, labels, and related shipping resources. | Martini can consume ShipStation REST endpoints from workflows, paginate through collections, transform responses, and expose a normalized REST API to other applications. |
| Webhooks / outbound callbacks | Limited | ShipStation provides webhook-style notifications for selected order and shipment lifecycle events, but not universal coverage of every object or field change. | Martini can expose an API endpoint to receive callbacks, validate and normalize notifications, launch asynchronous workflows, and use polling for reconciliation. |
| Authentication | Yes | ShipStation supports API-key authentication and OAuth 2.0 for supported application scenarios. Earlier API versions may use an API key and secret with Basic Authentication. | Martini can apply request headers, Basic Authentication, or OAuth access tokens and store credentials in environment-specific secrets. |
| Bulk / asynchronous / batch APIs | Limited | Some batch or asynchronous operations are available for shipping and label workflows, with exact operations varying by API version. | Martini can orchestrate batch requests, track responses, and apply version-specific validation and retry behavior. |
| File / label document APIs | Limited | Shipping labels and related documents can be retrieved in formats such as PDF, PNG, or ZPL, depending on the API operation and requested format. | Martini can retrieve label URLs or document content, transform or route files, and apply access, expiration, and downstream-format controls. |
| Incremental synchronization | Yes | Orders, shipments, and other collections can be synchronized using date filters, identifiers, pagination, and webhook notifications where supported. | Martini can persist timestamps or cursors, use overlap windows, reconcile missed events, and maintain cross-system identifiers. |
| SDKs | Not confirmed | ShipStation provides API documentation and developer resources, but SDK availability should be verified for the selected API version. | Martini does not require an SDK because workflows can call the REST endpoints directly. |
| Database access | No | No public ShipStation database access is confirmed for normal integrations. | Martini can persist normalized data, synchronization state, correlation identifiers, and idempotency keys in a supported external SQL database. |
How ShipStation exposes data and business events
ShipStation REST APIs
ShipStation REST APIs are the principal integration mechanism for Orders, Shipments, Products, Stores, Warehouses, Carriers, rates, labels, and related shipping resources. Collections may require pagination and supported date or identifier filters.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to ShipStation, calls the required endpoint, follows pagination, validates the response, maps the vendor payload to a canonical model, and writes the result to the target application or state store.
Implementation sequence
ShipStation webhooks
ShipStation supports webhook-style notifications for selected order and shipment lifecycle events. Coverage is event-specific and does not provide a universal notification for every object or field change.
Martini implementation pattern
Martini implementation pattern: a Martini API receives the callback, validates the request, acknowledges it quickly, and starts an asynchronous workflow. The workflow can retrieve the current Order or Shipment from ShipStation so the notification acts as a trigger rather than the sole source of truth.
Implementation sequence
ShipStation batch operations
ShipStation provides some batch or asynchronous operations, particularly around shipping labels and shipment processing. The exact operations depend on the selected API version and should be confirmed before implementation.
Martini implementation pattern
Martini implementation pattern: a workflow groups eligible requests, calls the supported batch operation, tracks the response, and handles partial success or asynchronous completion according to the endpoint contract.
Implementation sequence
ShipStation label documents
ShipStation shipping APIs can provide label documents or URLs in formats such as PDF, PNG, or ZPL. This is document retrieval rather than a general-purpose attachment repository.
Martini implementation pattern
Martini implementation pattern: an API or workflow receives a label request, applies carrier, service, package, warehouse, and idempotency rules, calls ShipStation, and returns or stores the resulting label representation for the downstream system.
Implementation sequence
ShipStation authentication
ShipStation authentication varies by API generation and application scenario. API keys are commonly used for direct access, OAuth 2.0 supports approved application scenarios, and earlier API versions may use an API key and secret with Basic Authentication.
Martini implementation pattern
Martini implementation pattern: credentials or OAuth tokens are stored in environment-specific secrets and applied by the REST API configuration or workflow. Access permissions should be limited to the ShipStation account and application requirements.
Implementation sequence
Common ShipStation integration patterns
Pattern 1: Synchronize orders and fulfillment
When to use this pattern
Use this pattern when ShipStation Orders must be synchronized with an ERP, commerce platform, or order-management application. Scheduled retrieval provides completeness, while supported notifications can reduce processing latency.
Integration direction
Example Mapping
| ShipStation Field | Canonical Field | Target Field |
|---|---|---|
| orderId | externalOrderId | externalId |
| orderStatus | fulfillmentStatus | status |
| items | orderLines | itemList |
| shipTo | shippingAddress | shipAddress |
Martini implementation pattern
A scheduled Martini workflow retrieves Orders with date filters and pagination, maps the payload to a canonical order model, applies store and fulfillment rules, and writes new or changed orders to the target. It stores ShipStation identifiers and a synchronization cursor, uses overlap windows, and retries transient failures without creating duplicate orders.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data mapping
- business rules
- SQL state persistence
- error handling
Pattern 2: Process shipment and tracking updates
When to use this pattern
Use this pattern when downstream systems need current carrier, tracking, delivery, or shipment status information. ShipStation webhook notifications can initiate near-real-time processing, with REST retrieval used to obtain authoritative details.
Integration direction
Example Mapping
| ShipStation Field | Canonical Field | Target Field |
|---|---|---|
| shipmentId | externalShipmentId | shipmentReference |
| trackingNumber | trackingNumber | trackingNumber |
| carrierCode | carrier | carrier |
| shipmentStatus | fulfillmentStatus | status |
Martini implementation pattern
A Martini API receives the selected ShipStation event and starts a workflow after validation. The workflow retrieves the Shipment when necessary, maps tracking information to Salesforce, checks the correlation identifier before updating, and routes missing or conflicting records to an exception path. Scheduled reconciliation covers missed notifications.
Martini capabilities used
- API exposure
- webhook consumption
- workflow orchestration
- data enrichment
- idempotency
- error routing
Pattern 3: Orchestrate shipping labels
When to use this pattern
Use this pattern when an internal application needs a controlled shipping interface for rates, carrier selection, label creation, or label retrieval. It centralizes operational rules and reduces direct point-to-point dependencies on ShipStation.
Integration direction
Example Mapping
| ShipStation Field | Canonical Field | Target Field |
|---|---|---|
| orderId | fulfillmentReference | orderKey |
| shipTo | destinationAddress | shipTo |
| weight | packageWeight | weight |
| serviceCode | shippingService | serviceCode |
Martini implementation pattern
A Martini REST API accepts a normalized label request. A workflow checks whether a shipment or label already exists, applies destination, service-level, package, warehouse, and cost rules, calls the relevant ShipStation APIs, and returns or stores the label document. Timeouts are reconciled before any retry that could purchase another label.
Martini capabilities used
- REST API exposure
- workflow orchestration
- data transformation
- business rules
- idempotency checks
- file and document handling
- retry control
Pattern 4: Reconcile shipments and exceptions
When to use this pattern
Use this pattern when webhook coverage is insufficient or operational teams need to identify unshipped orders, tracking mismatches, failed labels, and fulfillment exceptions.
Integration direction
Example Mapping
| ShipStation Field | Canonical Field | Target Field |
|---|---|---|
| orderId | orderReference | order_id |
| shipmentId | shipmentReference | shipment_id |
| trackingNumber | trackingReference | tracking_number |
| shipDate | fulfillmentTimestamp | shipped_at |
Martini implementation pattern
A scheduled Martini workflow retrieves ShipStation Orders and Shipments, compares them with normalized state in a supported SQL database, and applies business thresholds for unresolved fulfillment. Normal matches update state, while mismatches are routed for review. Cursors, hashes, and correlation identifiers make reruns safe and support auditability.
Martini capabilities used
- scheduled workflows
- REST API consumption
- SQL database access
- data comparison
- business rules
- exception routing
- monitoring and logging
Applications commonly integrated with ShipStation
ShipStation can be integrated with commerce channels, enterprise applications, and customer-facing systems to coordinate orders, fulfillment, tracking, labels, and delivery updates. The exact flow depends on the account configuration, selected ShipStation API version, and the data model of each adjacent application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Import Shopify orders into ShipStation and return fulfillment and tracking updates to the store. | Shopify → Martini → ShipStation | Martini can consume Shopify and ShipStation APIs, map order and fulfillment models, and use scheduled workflows or supported event notifications to reconcile tracking identifiers and statuses. |
| NetSuite | Synchronize orders, fulfillment status, tracking numbers, shipping costs, and related ERP processes. | NetSuite → Martini → ShipStation | A Martini workflow can coordinate NetSuite and ShipStation API calls, persist cross-system identifiers, apply carrier and warehouse rules, and retry transient failures without duplicating fulfillment operations. |
| Salesforce | Make shipment and delivery status available to sales, service, and customer records. | ShipStation → Martini → Salesforce | Martini can receive or poll ShipStation shipment data, enrich it when necessary, map tracking and delivery fields to Salesforce objects, and route validation failures for review. |
| Amazon Seller Central | Import marketplace orders and return shipment and tracking updates to the marketplace workflow. | Amazon Seller Central → Martini → ShipStation | Martini can orchestrate order retrieval and fulfillment updates across the APIs available to the account, using correlation identifiers and scheduled reconciliation to handle delayed or missed notifications. |
| eBay | Import eBay orders and synchronize fulfillment and shipment tracking information. | eBay → Martini → ShipStation | A Martini workflow can normalize marketplace orders, call ShipStation REST endpoints, and publish tracking changes back to eBay while applying idempotency and retry rules. |
| WooCommerce | Import web-store orders and return fulfillment or tracking status. | WooCommerce → Martini → ShipStation | Martini can connect the WooCommerce and ShipStation APIs, transform line items and addresses, and run scheduled or event-driven workflows for fulfillment synchronization. |
| BigCommerce | Synchronize store orders, shipping status, and tracking information. | BigCommerce → Martini → ShipStation | Martini can map BigCommerce orders to ShipStation Orders, process shipment updates, and use external state storage to reconcile changes and avoid duplicate updates. |
| Zendesk | Provide shipment and tracking information to support agents handling delivery inquiries. | ShipStation → Martini → Zendesk | Martini can retrieve ShipStation shipment details, transform carrier and tracking data, and update Zendesk tickets or customer context through Zendesk APIs. |
How to build a ShipStation integration in Martini
Objective
Confirm the ShipStation API generation and authorization model, then configure the connection without embedding credentials in workflow logic.
Instructions in Martini
- Select the applicable ShipStation REST API and account authorization model
- Store API keys, secrets, or OAuth values in Martini secrets
- Configure the required headers or authorization token
- Validate account permissions with a controlled request
Objective
Select an event-driven, scheduled, or API-led entry point based on ShipStation’s event coverage and the integration’s completeness requirements.
Instructions in Martini
- Use a Martini API for inbound ShipStation webhook callbacks
- Use a scheduler for incremental Orders or Shipments synchronization
- Use an exposed Martini API for label or shipping requests
- Use reconciliation schedules for events not covered by notifications
Objective
Retrieve the current ShipStation resource rather than relying on incomplete event payloads, and process collections safely.
Instructions in Martini
- Call the relevant Orders, Shipments, Products, Stores, Warehouses, Carriers, or label endpoint
- Follow pagination until the collection is complete
- Apply supported date or identifier filters
- Persist the cursor, timestamp, or page checkpoint
Objective
Coordinate API calls, enrichment, state management, and target-system operations in a maintainable Martini workflow.
Instructions in Martini
- Normalize the incoming event or API response
- Retrieve authoritative ShipStation details when needed
- Load correlation and idempotency state
- Route records according to store, warehouse, carrier, or fulfillment rules
Objective
Convert ShipStation payloads into the canonical and target models while tolerating optional fields and changing carrier values.
Instructions in Martini
- Map Orders and Shipments to the target data model
- Normalize timestamps to UTC
- Map carrier, service, package, and warehouse identifiers through configuration
- Handle label URLs, binary content, PDF, PNG, or ZPL requirements explicitly
Objective
Apply operational controls before writing data or performing consequential shipping actions.
Instructions in Martini
- Check for existing shipments or labels before retrying
- Validate addresses, services, packages, and required identifiers
- Apply shipping-cost, destination, warehouse, and service-level rules
- Separate authorization, validation, throttling, and transient failures
Common ShipStation data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Orders | Orders imported into or created in ShipStation, including customer, address, item, payment, and fulfillment information. | Shopify, NetSuite, Amazon Seller Central, eBay, WooCommerce, BigCommerce, and order-management applications | Martini retrieves Orders through REST APIs or processes related notifications, maps them to target order models, persists identifiers, and handles pagination and incremental cursors. |
| Shipments | Shipment records containing carrier, service, tracking, package, label, and delivery information. | Salesforce, Shopify, NetSuite, Zendesk, marketplaces, and customer-notification systems | Martini can receive selected shipment events, retrieve the authoritative Shipment, transform tracking data, and apply idempotent updates and retry rules. |
| Products | Product catalog items associated with order line items and inventory or fulfillment processes. | Commerce platforms, ERP applications, inventory systems, and order-management applications | Martini can synchronize Products through paginated REST calls and map identifiers, SKUs, descriptions, and fulfillment attributes where required. |
| Stores | Connected selling channels or commerce stores from which ShipStation imports orders. | Commerce platforms, marketplaces, ERP applications, and channel-management systems | Martini can retrieve Stores for configuration and reconciliation workflows and use store identifiers when routing Orders and Shipments. |
| Warehouses | Ship-from locations and inventory or fulfillment locations configured in ShipStation. | NetSuite, inventory applications, warehouse systems, and order-management applications | Martini can map warehouse identifiers to source-system locations and apply configurable ship-from routing rules. |
| Carriers | Shipping carriers and services available for rating, label creation, and shipment fulfillment. | Shipping orchestration services, ERP applications, commerce platforms, and customer-facing systems | Martini can retrieve and normalize carrier and service values, applying configuration-driven mappings rather than hard-coded branches. |
Authentication and security considerations
Authentication options
ShipStation authentication depends on the API generation and integration scenario. API keys are commonly used for direct account access, OAuth 2.0 supports approved application scenarios, and earlier API versions may use an API key and secret with Basic Authentication.
Secure Martini configuration
- Store API keys, secrets, and OAuth values in Martini environment-specific secrets.
- Apply only the headers or tokens required by the selected ShipStation API.
- Limit account permissions and OAuth access according to the integration’s responsibilities.
- Rotate credentials without embedding them in workflow mappings or custom logic.
Operational considerations for ShipStation integrations
Rate limits and retries
Respect ShipStation rate limits and response headers where provided. Use exponential backoff for throttling and transient server errors, while separating authorization, validation, and unsupported-operation failures from retryable conditions.
Pagination and synchronization
Orders, Shipments, Products, and other collections may be paginated. Persist cursors or timestamps, use overlap windows, and reconcile with scheduled workflows so delayed or missed webhook notifications do not create gaps.
Idempotency and labels
Label creation and fulfillment can have operational or financial consequences. Persist source identifiers and ShipStation identifiers, check for an existing shipment or label before retrying, and account for URL expiration, document formats, and secure file handling.
Schema and data quality
Treat carrier codes, service names, package types, warehouse identifiers, and status values as configurable data. Normalize timestamps to UTC, tolerate optional fields, and test mappings against the selected ShipStation API version.
Why use Martini instead of scripts or point-to-point integrations?
Reusable integration orchestration
Martini provides workflows and APIs for coordinating ShipStation calls, webhook processing, scheduled synchronization, reconciliation, and downstream updates without duplicating orchestration logic across scripts.
Controlled transformation
Mapping and transformation capabilities convert ShipStation Orders, Shipments, label data, and operational values into canonical and target-system models. Business rules can centralize carrier, warehouse, package, and service decisions.
Operational reliability
Martini can manage secrets, pagination, retries, idempotency state, exception routing, and monitoring. This provides a maintainable integration layer compared with brittle scripts or tightly coupled point-to-point flows.
API façade capability
Martini can expose a normalized REST API for internal applications while keeping ShipStation authentication, version-specific behavior, validation, and error handling behind reusable workflows.
Frequently asked questions
ShipStation can be integrated through its REST APIs, API-key authentication, OAuth 2.0 for supported application scenarios, selected webhook-style notifications, and scheduled polling with filters and pagination. Label and shipping operations can also be orchestrated through supported REST endpoints.
Yes. Martini can integrate with ShipStation by consuming its REST APIs, receiving supported webhook notifications, applying the required authentication method, orchestrating workflows, mapping data, and persisting synchronization state externally.
No. A dedicated ShipStation connector is not required. Martini can use ShipStation’s confirmed native REST APIs, webhook callbacks, authentication methods, label-document endpoints, and scheduled synchronization mechanisms.
Lonti does not charge an additional per-connector or per-vendor fee to integrate ShipStation. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from ShipStation, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are the primary method for Orders, Shipments, Products, Stores, Warehouses, Carriers, rates, and labels. Use webhook-style notifications for selected near-real-time events, and scheduled REST polling for completeness, reconciliation, or objects not covered by notifications.
ShipStation supports webhook-style notifications for selected order and shipment lifecycle events. Coverage is partial rather than universal, so Martini workflows should validate notifications, retrieve the current resource when necessary, and use scheduled reconciliation for missed or unsupported changes.
Martini can use ShipStation date filters, identifiers, pagination, and webhook triggers to implement incremental synchronization. A workflow can persist cursors, timestamps, correlation identifiers, and idempotency keys, use overlap windows, and check whether a shipment or label already exists before retrying.
Yes. Martini can expose a REST API that presents a normalized shipping or fulfillment interface to internal applications, then orchestrate ShipStation API calls behind it. This can centralize authentication, mapping, carrier rules, idempotency checks, error handling, and label-document processing.
Related Martini documentation
API Integration
Workflows
Connect ShipStation with Martini
Use Martini to build maintainable ShipStation integrations for orders, shipments, labels, tracking, and fulfillment workflows.