You connect a warehouse to the rest of your stack with two tools working together: webhooks that push an event the second it happens, and a REST API that reads and writes your operational objects. Shipider gives you both, which is what makes it the operations layer sitting inside your stack rather than a walled garden you have to log into and manually reconcile.
A warehouse that cannot talk to the systems around it becomes a data island. Orders get keyed in twice, inventory numbers drift, and your customer service team ends up screenshotting a screen to answer a "where is my pallet" question. The fix is not another dashboard. The fix is wiring: a way for the warehouse to announce what just changed, and a way for other systems to ask for detail and write new work in. That is what this article walks through.
Webhooks react in real time
The old way to stay in sync is polling. Some script asks the warehouse "anything new?" every minute, gets told "no" a few hundred times, and occasionally catches a change a minute late. It burns requests, it adds latency, and it scales badly the moment you have more than a handful of tenants or a busy shipping day.
Webhooks flip that around. Instead of you asking, the warehouse tells you. The instant an order moves through its lifecycle, Shipider sends a small HTTP request to a URL you own, carrying the event and the identifiers you need to act on it. Nothing to schedule, nothing to poll, and the news arrives while it is still fresh.
Shipider fires webhooks across the order and pallet lifecycle. The named events are:
order.received: an inbound order has landed in the warehouse and is queued for work.order.processed: the floor has picked, staged, or otherwise worked the order and it is waiting on a check.order.confirmed: a checker has signed the order off, the maker-checker gate has cleared, and it is good to dispatch.pallet.dispatched: a pallet has physically left the building.
Each of those is a moment your other systems care about. order.received can trigger a "we've got it" message to a customer. order.confirmed can release a billing event. pallet.dispatched can flip a shipment to "in transit" in a portal without anyone refreshing anything. Because the events map to real physical and workflow milestones, you are reacting to the truth on the floor, not to a guess based on a timer.
The API exposes every operational object
Webhooks tell you that something changed. The REST API is how you read the detail and write new work back in. Shipider exposes the objects a warehouse actually runs on: orders, pallets, SKUs, locations, and customers. In practice that means you can:
- Create inbound orders straight from a storefront, an ERP, or a supplier feed, so nothing gets hand-keyed at the warehouse.
- Read pallet contents and condition records to see exactly what is on a pallet and what state it arrived or shipped in.
- Pull SKU movement history to trace where a product has been and reconcile counts against your own records.
- Push inventory so stock levels stay aligned between the warehouse and whatever system your customers actually look at.
Access is governed by scoped API keys, one per integration. Your storefront connector gets a key that can do what the storefront needs and nothing else; your analytics job gets a read-scoped key of its own. If a key leaks or an integration is retired, you rotate that one key without touching any of the others. It also means an audit of "what can this integration actually do" has a short, honest answer.
Full endpoint reference, request and response shapes, and the current event list live in the API docs. That is the source of truth to build against; this article is the map, the docs are the territory.
Where scanning and the API meet
A fair amount of the data the API serves originates from the floor, and Shipider lets staff capture it with browser barcode scanning on a phone camera, so there is no scanner hardware to buy or provision. A scan updates a pallet or a location, that change becomes readable over the API, and if it advances an order it fires the matching webhook. The floor, the API, and your downstream systems all end up looking at the same record.
A concrete end-to-end flow
Here is how the pieces fit for a single order, from the customer clicking buy to the customer seeing it shipped, with no polling anywhere in the chain:
- A shopper checks out on your storefront. Your storefront calls the Shipider API to create an inbound order using its scoped key. Shipider records the order and fires
order.received. - Your systems catch
order.receivedand send the customer a "we've got your order" note. No one at the warehouse typed anything. - On the floor, staff pick and stage the order, scanning pallets with a phone camera as they go. Shipider fires
order.processedonce the work is done and the order is waiting on a check. - A second person reviews and signs the order off under the maker-checker workflow, so the person who did the work is not the person who approves it. When the check clears, Shipider fires
order.confirmed. - The pallet leaves the building. Shipider fires
pallet.dispatched. - Your customer portal is listening for
pallet.dispatched. It updates the order to "shipped" the moment the event lands. The customer sees the change without ever refreshing, and your team never had to touch a screen.
At any step, a downstream system that wants more detail than the event carries can call the API for it: read the pallet contents behind pallet.dispatched, pull the SKU history to reconcile stock, or fetch the customer record to route a notification. The webhook is the nudge; the API is the follow-up question.
Polling versus webhooks, side by side
If you are weighing whether to keep a polling job or move to webhooks, this is the trade in plain terms:
| Dimension | Polling | Webhooks |
|---|---|---|
| Latency | As long as your poll interval; a change can wait a full cycle before you notice | Near instant; the request goes out as the event happens |
| Load | Constant requests, most of them returning nothing | Traffic only when something actually changed |
| Freshness | Stale between polls; you are always looking slightly into the past | Current at the moment of the event |
| Scaling | Cost grows with every tenant and shorter interval you add | Cost tracks real activity, not the clock |
| Best used for | One-off reconciliation, backfills, catching anything a listener missed | Reacting to lifecycle changes the instant they occur |
The two are not enemies. A common, sensible pattern is to drive live behaviour from webhooks and keep a low-frequency poll or an occasional full read from the API as a safety net, so a missed delivery gets picked up on the next sweep.
Per-tenant events for 3PLs
If you run a third-party logistics operation, one warehouse holds many clients' goods, and each of those clients may have their own systems to feed. Shipider is multi-tenant and 3PL-first, so events are scoped per tenant. Client A's storefront receives events about Client A's orders and pallets, and only those. You are not fanning out one firehose and asking every consumer to filter for their own rows. Each tenant's integration sees a clean stream of its own activity, which keeps data isolated and keeps your onboarding of a new client down to issuing them a scoped key and a webhook URL.
Getting the wiring right
A few habits keep an integration healthy once it is live:
- Make handlers idempotent. Treat every event as if it might arrive more than once, and design your handler so a repeat does no harm.
- Acknowledge fast, work after. Return a success response quickly, then do the heavy processing on your side, so a slow job never looks like a failed delivery.
- Scope keys per integration. One key per consumer, each with only the access it needs, so rotation and audits stay simple.
- Keep a reconciliation path. Use the API to re-read state on a schedule or on demand, so nothing depends on a single delivery landing perfectly every time.
Do those four things and the warehouse stops being a place your data goes to hide. It becomes a participant in the stack, announcing what it did and answering what you ask, which is exactly the point of connecting it in the first place.
FAQ
What is the difference between a webhook and an API call here?
A webhook is Shipider pushing to you the instant something changes, like order.confirmed or pallet.dispatched. An API call is you asking Shipider for something, whether that is reading pallet contents or creating an inbound order. Webhooks tell you when to act; the API is how you read detail and write new work in.
Do I have to poll if I use webhooks?
No, and that is the point. Webhooks remove the need for a constant polling loop, since Shipider notifies you as events happen. Many teams still keep a light, occasional read from the API as a safety net so any missed delivery gets caught, but that is a backstop rather than your primary mechanism.
Which lifecycle events does Shipider send?
Shipider fires webhooks on the order and pallet lifecycle: order.received, order.processed, order.confirmed, and pallet.dispatched. Each maps to a real milestone on the floor or in the maker-checker workflow. The current event list is documented in the API docs.
How does this work for a 3PL with many clients?
Events are scoped per tenant, so each client's integration sees only its own orders and pallets. You issue every client a scoped API key and a webhook URL, and their stream stays isolated from everyone else's. That keeps data separation clean and makes onboarding a new client a short task.
Can I create orders through the API, not just read them?
Yes. The API reads and writes. You can create inbound orders from a storefront or supplier feed, read pallet contents and condition records, pull SKU movement history, and push inventory. Each integration uses its own scoped key, and the full reference is in the API docs.
Ready to wire your warehouse into the rest of your stack? Create your Shipider account and start building against the API and webhooks today.
Related reading: ERP Sync Without Double Entry: Connecting Your WMS to Your ERP