Pull or Push
Read an endpoint when you choose, or receive changes by webhook: which to use, and how to combine them.
GAINS Connect gives you two ways to take data out of GAINS: you read it from an endpoint when you choose (pull), or GAINS sends it to your URL by webhook when something happens (push). This page compares the two and explains how to combine them.
| Read an endpoint (pull) | Webhook (push) | |
|---|---|---|
| What you receive | Everything GAINS currently holds that matches your filters | Orders as they are submitted; policies and forecasts that changed |
| When | Whenever you call | Shortly after the event, in batches |
| Subjects | Every outbound subject; see Outbound Subjects | Replenishment orders, inventory policies, weekly and monthly forecasts |
| Narrowing what you receive | Query parameters on each request | A filter on each trigger |
| If you miss something | Read it again | Retries, then resend from webhook history |
When to read an endpoint
- You need the full current state, for example a first load, or a nightly copy of every inventory policy.
- You want to reconcile what you hold against what GAINS holds.
- The subject has no webhook: demand history, requisitions, service levels, the aggregate forecast, locations, vendors, customers, bills of material, supercessions, lead-time prediction and custom schema data.
An endpoint does not track changes. None of them can return only the records that changed since a given time, and none remembers what you have already read: each call returns everything that matches your filters. The date filters that exist select on business dates, not on when a record changed.
When to use a webhook
- You want to act on events as they happen: a submitted order, a changed policy or forecast.
- You want only what changed. The policy and forecast triggers send a SKU-location only when GAINS detects that it has changed.
- You want to route data. A trigger filter, for example
ReceivingLocation IN ('CHI01', 'DAL02'), sends each destination only the records it needs.
See Webhooks for setting up destinations, filters, retries and resending.
Using both
Where a subject has a webhook, use both channels together:
- Load once from the endpoint. Read every page of the subject to start from the full current state.
- Keep up to date from the webhook. Process each delivery as it arrives. Deliveries can repeat, so make processing a record twice harmless: key orders on
TrackingNumber, and policies and forecasts onItemCodeandLocationCode. - Reconcile on a schedule. Read the endpoint again, for example daily, and compare. This catches anything a delivery missed, such as a payload dropped after its last retry. For orders, you can also re-read a single order with
TrackingNumber.
Related
- Outbound Subjects: every endpoint, and which subjects also arrive by webhook
- Webhooks: triggers and setup
- Delivery & Recovery: retries and resending a missed delivery
- Pagination: reading every page of an endpoint
Updated about 18 hours ago