How does the integration handle ShipStation webhooks if they only fire on new orders?

ShipStation webhooks (ORDER_NOTIFY, SHIP_NOTIFY) fire only on order creation, not on order edits or shipment updates. ml-connector augments webhook coverage by polling ShipStation's /orders endpoint with a modifyDate filter on a regular schedule, catching order updates and shipment status changes that webhooks miss. This hybrid approach (webhooks plus polling) ensures all order changes flow to IFS Cloud.

What happens when a sales order in IFS Cloud is edited by another user or system at the same time ml-connector tries to write shipment data?

IFS Cloud requires the OData ETag header on PATCH operations to enforce optimistic concurrency control. ml-connector fetches the current order record before each update to capture the @odata.etag, then includes that etag on the PATCH request. If another user has edited the record since ml-connector read it, the etag will not match and IFS Cloud returns a 412 Precondition Failed. ml-connector then retries: it re-reads the current record, captures the new etag, and resubmits the PATCH with the latest etag value.

Does IFS Cloud need to send orders to ShipStation, or is the flow one-direction?

The primary flow is ShipStation to IFS Cloud (shipments and tracking into fulfillment records). However, if you need to push new sales orders created in IFS Cloud into ShipStation so they appear in your fulfillment workflows, ml-connector can be configured to read new customer orders from IFS Cloud on a schedule and POST them to ShipStation. The direction and scope depend on your order-entry point and fulfillment workflow.

IFS CloudShipStation

IFS Cloud and ShipStation integration

IFS Cloud runs your manufacturing, supply chain, and finance operations. ShipStation manages order fulfillment across multiple sales channels and carriers. Connecting them keeps your ERP orders aligned with actual shipments and carrier tracking, eliminating manual re-entry of shipment details into IFS Cloud. When a customer order ships, ShipStation's tracking data flows directly into your ERP so your sales order records reflect current fulfillment status.

How IFS Cloud works

IFS Cloud exposes customer orders, sales order line items, shipment records, and inventory through OData v4 REST APIs against a tenant-specific base URL. Every customer has their own https://<tenant>.ifs.cloud domain. Authentication uses OAuth 2.0 Client Credentials with client_id and client_secret against a tenant-specific token endpoint, with token lifetime approximately 60 minutes. Each customer must provide their company code(s) for financial entities. IFS Cloud has no standard webhook subscription API; Event Actions exist but require per-customer manual configuration in IFS admin UI and are not API-driven. The recommended pattern is pull-based polling on OData entity sets with filters on modified timestamps. Record mutations require the OData ETag header for optimistic concurrency control.

How ShipStation works

ShipStation provides order management, customer and product data, shipment tracking, and warehouse information through REST APIs. Both V1 and V2 base URLs exist; V1 (https://ssapi.shipstation.com) covers order CRUD, customer, product, and warehouse management, while V2 (https://api.shipstation.com/v2) covers label creation and inventory. Authentication uses API Key in the header with no Bearer prefix. ShipStation publishes outbound webhooks for order creation and shipment events, but the payloads contain only resource pointers; actual data requires an authenticated GET to fetch. ORDER_NOTIFY fires only on new orders; order edits and shipment status changes require polling the /orders endpoint with a modifyDate filter. Shipped or cancelled orders become immutable and cannot be updated via API.

What moves between them

The primary flow runs from ShipStation back into IFS Cloud. As orders ship in ShipStation and carriers provide tracking information, ml-connector polls ShipStation for updated shipments, then writes the shipment carrier name, tracking number, and ship-date into IFS Cloud as fulfillment records linked to the matching customer sales orders. Reference data such as warehouse locations and customer master records can flow in both directions to keep systems aligned. The integration runs on a daily or on-demand schedule depending on order volume and shipping cycles.

How ml-connector handles it

ml-connector stores the IFS Cloud OAuth2 client credentials and ShipStation API Key encrypted at rest. For IFS Cloud, it exchanges credentials for a bearer token every 60 minutes and sends OData requests against the tenant-specific base URL, reading customer orders via filters on LastModifiedDate to detect changes since the last poll. Before updating a sales order with shipment data, it fetches the current record to capture the @odata.etag, then submits a PATCH with that etag header to prevent race conditions on concurrent updates. For ShipStation, it polls the V1 /orders endpoint with modifyDate filters to detect shipments not caught by webhooks, since ORDER_NOTIFY fires only on order creation. When a shipment is found, ml-connector follows the webhook pointer to fetch full shipment details, then maps the ShipStation carrier name and tracking number to IFS Cloud shipment fields. Because ShipStation rate-limits at 40 requests/min on V1, ml-connector respects X-Rate-Limit-Remaining headers and backs off on 429 responses. Every shipment record written to IFS Cloud includes a full audit trail so failed deliveries or carrier changes can be replayed if needed.

A real-world example

A mid-sized discretionary manufacturer uses IFS Cloud for production planning, procurement, and sales order management, and fulfills orders through a combination of in-house packing and drop-ship via third-party logistics partners. Orders flow into ShipStation from their web store and ERP-integrated B2B channel, carriers print labels, and tracking numbers accumulate in ShipStation. Before the integration, the operations team manually checked ShipStation daily for new shipments, copied carrier names and tracking numbers into spreadsheets, and re-entered them into IFS Cloud one by one, a process that took 1-2 hours per day and introduced transcription errors. With IFS Cloud and ShipStation connected, each shipment's carrier and tracking number flows into the ERP automatically, sales order fulfillment records stay current, and customers see accurate tracking information if they query the ERP for order status. The daily manual process is eliminated.

What you can do

Sync customer order and shipment status from ShipStation into IFS Cloud sales orders, including carrier name and tracking number.
Poll ShipStation for order changes and shipment events that webhooks do not catch, maintaining a current view of order fulfillment.
Handle IFS Cloud's OData ETag concurrency requirement so updates do not collide with concurrent edits by other systems.
Authenticate IFS Cloud with OAuth2 and tenant-specific credentials, and ShipStation with API Key authentication across multiple sales channels.
Keep a full audit trail on every shipment record synced so failed pushes or carrier changes can be replayed without data loss.

Questions

How does the integration handle ShipStation webhooks if they only fire on new orders?: ShipStation webhooks (ORDER_NOTIFY, SHIP_NOTIFY) fire only on order creation, not on order edits or shipment updates. ml-connector augments webhook coverage by polling ShipStation's /orders endpoint with a modifyDate filter on a regular schedule, catching order updates and shipment status changes that webhooks miss. This hybrid approach (webhooks plus polling) ensures all order changes flow to IFS Cloud.
What happens when a sales order in IFS Cloud is edited by another user or system at the same time ml-connector tries to write shipment data?: IFS Cloud requires the OData ETag header on PATCH operations to enforce optimistic concurrency control. ml-connector fetches the current order record before each update to capture the @odata.etag, then includes that etag on the PATCH request. If another user has edited the record since ml-connector read it, the etag will not match and IFS Cloud returns a 412 Precondition Failed. ml-connector then retries: it re-reads the current record, captures the new etag, and resubmits the PATCH with the latest etag value.
Does IFS Cloud need to send orders to ShipStation, or is the flow one-direction?: The primary flow is ShipStation to IFS Cloud (shipments and tracking into fulfillment records). However, if you need to push new sales orders created in IFS Cloud into ShipStation so they appear in your fulfillment workflows, ml-connector can be configured to read new customer orders from IFS Cloud on a schedule and POST them to ShipStation. The direction and scope depend on your order-entry point and fulfillment workflow.

Connect IFS Cloud and ShipStation

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started