Third-party integrations

A third-party integration in ecommerce operations is a connection that moves order, inventory, or shipment state between two systems that were bought separately. Integrations divide by direction, and the direction sets what the integration can be used for. A read integration pulls state in so it can be displayed or acted on elsewhere. A write integration pushes a change back, such as canceling an order, issuing a refund, or updating an address. Most published connector lists describe read integrations, which is why two tools can advertise the same integration and only one of them can change anything. The distinction is not a marketing one: it is the difference between a safe method and an unsafe one in RFC 9110, the HTTP semantics specification, and it is worth asking a vendor in exactly those terms.

Shipping and 3PL carriers

The carrier and third-party logistics layer supplies the events that everything after dispatch depends on. Three data flows matter and they are usually separate connections: rating and label generation at dispatch, tracking events across the carrier network, and inventory or fulfillment status from the warehouse. Coverage is the recurring problem rather than capability, because a merchant using several carriers and more than one fulfillment location needs every one of them connected, and the orders flowing through an unconnected one produce no events at all. The absence is silent, since a missing feed looks identical to an order with nothing to report. The carrier layer specifically is carrier integration, the tooling that watches it is parcel software, and the event vocabulary that lets several carriers be compared at all is the GS1 EPCIS standard.

Returns and exchanges portals

A returns platform holds the return authorization, the label, the inspection outcome, and the refund or exchange decision. Its integration surface points in two directions at once. It reads the original order to check eligibility, and it writes the outcome back so that stock, refunds, and the customer record reflect what happened. Where the write leg is missing or delayed, the visible symptom is a customer who has been told their return is complete while the order record still shows it open, which produces a contact that neither system can resolve on its own. Exchange flows raise the stakes because they also need a live stock reservation rather than a stock reading. The process behind both is returns management and the customer-facing choice is return vs exchange.

Order management systems (OMS)

The order management system is normally the system of record for order state and often for inventory across locations. That makes it the integration hub in practice, because everything downstream needs the state it holds and everything upstream writes into it. The design question worth settling before connecting anything is which system owns each fact. Where two systems both believe they own inventory, a two-way sync produces conflicts that surface as overselling. Where the order management system owns it and every other connection reads from it, the same data flows are simpler and the failure modes are visible in one place. The application layer around it is ecommerce application, and running it across channels is omnichannel order management.

Helpdesk and WISMO ("Where Is My Order?") automation

Helpdesk integrations bring order and tracking data into the ticket so that an agent does not switch systems to answer a question, and they let macros and automations reference real order state. This is the most commonly installed integration in the category and also the most commonly misread, because it improves how fast a contact is handled without changing how many contacts arrive. The distinction to hold is between an integration that surfaces the order in the ticket, which speeds up an answer, and one that lets the helpdesk act on the order, which resolves the case. Most connectors in this category do the first. The helpdesk is the system in question and the tooling argument is automated ticketing system.

This is the most-installed connector in the category and the most commonly misread, and the reason is worth stating from the operator's side. Connecting order data into the ticket means the agent stops switching systems, which is real and worth having. It does not change how many tickets arrive, because nothing about it touches the order. Every order is a promise, and a connector that shows an agent the broken promise faster has improved the conversation about it. That distinction is the whole of proactive versus reactive customer service, and I have argued it on Spotlight Fridays.

Real-time data sync

Real time in connector documentation covers a wide range, and the specific figure matters more than the label. Event-driven synchronization through webhooks propagates a change within seconds and depends on the source system emitting an event for that change. Polling checks on an interval, which sets a floor on how stale the data can be. Scheduled or file-based synchronization, including any process that still involves a CSV, means the receiving system can be a full cycle behind. The question that resolves it is not whether a connector is real time but which changes emit events, at what interval anything else is checked, and what happens to an event that fails to deliver. Credentials are part of the same answer, since an OAuth 2.0 token that expires quietly stops a feed as effectively as a schema change does.

Compatibility

Compatibility is a claim about a specific stack, not about a platform. A connector that supports a storefront in general may not support the particular version, the particular ERP, or the combination of both that a merchant runs, and the gaps usually appear at the edges rather than in the core object. Custom fields, multi-currency, multi-location inventory, and marketplace channels are the four that most often turn out to be unsupported after installation. The way to test a compatibility claim before committing is to name the objects that carry the merchant's own edge cases and confirm each one round-trips, rather than confirming that the platform appears on a supported list. Where a vendor publishes an OpenAPI description, the objects and fields are readable before anything is installed, which turns a compatibility conversation into a check. What the whole stack looks like is company tech stack and how to choose it is best tech stack for ecommerce.

Reduction of ticket volume

Integrations reduce contacts through two mechanisms and only one of them is about the connector. Self-service tracking removes the informational contact by letting the customer answer the question, which needs a read integration and works for orders progressing normally. Most of that volume is WISMO. Acting on the order before the customer notices removes the contact entirely, which needs both a detection path and a write path. Measuring this properly requires contacts per hundred orders by reason code rather than total ticket count, since an integration that changes handle time without changing arrival rate will show no movement in the rate and a large movement in the team's workload. The measures are defined on ecommerce KPIs and the clock on resolution time.

Error handling and alerts

The most important property of an integration is what it does when it fails, because failures in this layer are silent by default. A failed sync, an expired credential, a rate limit, or a schema change on the other side all produce the same visible symptom, which is data that stops changing. Nothing raises an error where nothing was expected. The controls that address this are a failure alert on the connection itself, a reconciliation check that compares record counts between systems on a schedule, and a staleness monitor that flags a feed that has produced no updates within its normal window. The third is the one most often missing, and it is the one that catches the failure that looks like a quiet day.

Silent failure is the whole reason to care about this layer, and the honest version of it is worse than it sounds. When a connection fails, the systems on both sides keep looking correct. There is no error, because nothing errored, and the first signal anybody gets is a customer asking a question the data cannot answer. That is why the staleness monitor matters more than the retry logic: retries handle the failures that announce themselves, and the expensive ones do not. Ask any vendor what happens when their feed simply stops, and listen for whether the answer involves a person noticing. What the failure looks like to a customer is a delivery exception nobody acted on, and the operating model that treats it as the main event is post-purchase operations.

How long a quiet day can last is in the 786 pain points we mined from 270 customer call transcripts between May 2025 and May 2026. Silent connection failures stopped data syncing for weeks at a time with the merchant unaware of the gap, and the schedulers between the storefront, the ERP and the warehouse system were the usual point of failure, with a customer ticket as the only signal. A staleness monitor is the control that would have caught every one of those entries on day one.

• IETF. RFC 9110, the HTTP semantics specification. Read against write, in the terms a vendor's engineers use.
• GS1. GS1 EPCIS standard. One event vocabulary across carriers and warehouses.
• IETF. OAuth 2.0. Credentials expiring quietly as a failure mode.
• OpenAPI Initiative. OpenAPI description. Testing a compatibility claim before installing anything.