A webhook tells the system to send a small HTTP message (a "ping") to an endpoint you control whenever the data you care about changes — so another system can react without polling. Webhooks are set up on the Webhooks admin page.
Setting up a webhook
Click Add Webhook, fill in the options, and click Save. The numbers below match the fields on the form above:
Name — a label to identify the webhook.
URL — the endpoint the ping is sent to. Must be an absolute http(s) URL.
Method — the HTTP method: POST (default), GET or PUT.
API version — the article API version the ping's path uses (v2 or v3); new webhooks default to v3.
Enabled — whether the webhook is active.
Include resource — controls how much each ping carries. Off (the default), a ping only tells you which item changed and leaves you to fetch it from the API. On, the item's full current data is embedded directly in the ping under a resource field, so the receiving system can act on it immediately without a follow-up call. Leave it off to keep pings small and always pull the latest state yourself; turn it on to save a round-trip when the ping itself is enough.
Authentication — optional HTTP Basic auth. Click Add Basic Auth and enter a username and password/key.
Environments — QA and/or Production (see the environment note below).
Throttle (seconds) — optional; limits how often pings fire for the same item.
Article status filtering — restricts pings to chosen article statuses. Left empty, the webhook sends for all statuses.
What triggers a webhook
A ping is sent whenever one of these items is created or changed and the change is saved in the system:
Articles
Orders
Seasons
Tags
Size systems
Changes to related data count too — they roll up to the item they belong to. Editing an article's SKUs, prices, images, tags, suppliers, sizes, or its BOM and components all register as a change to that article and send a ping for it; you don't only get a ping when the top-level record is edited. An order behaves the same way when its deliveries, rows or allocations change.
Each save produces one ping per affected item. Throttling and article-status filtering (below) then decide whether that ping is actually delivered.
What the ping contains
By default the ping is a small JSON body with a single path field — a full link to the API endpoint for the changed item. The path tells you both what changed and how to fetch it, so its shape depends on the item type. An article update:
{ "path": "https://app.resourced.com/api/integration/{brandId}/v3/articles/{articleNumber}" }
An order update points at the order endpoint instead:
{ "path": "https://app.resourced.com/api/integration/{brandId}/orders/{orderId}" }
Article paths include the version segment (v2 or v3) the webhook is set to; orders, seasons, tags and size systems don't carry a version. Call the path to fetch the item's current state. On v3, an article's data is returned per channel (keyed by channel key) — see Channels.
If Include resource (6) is on, the item's data is added alongside the path under a resource field — exactly what that endpoint returns (an article for an article ping, an order for an order ping) — so you don't have to make the follow-up call:
{ "path": "…/orders/{orderId}", "resource": { … } }
Each ping also carries two headers — X-RS-BrandId (the brand the change belongs to) and X-RS-Environment (QA or PROD) — so a single endpoint can tell environments and brands apart.
Article status filtering
A webhook can be limited to chosen article statuses. With a filter set, a ping is sent whenever an article's previous or new status is one of the chosen statuses — so you're notified when an article enters a filtered status, when it changes while in one, and when it leaves one. With no filter set, every status sends.
Status filtering applies to articles only; pings for other item types are always sent.
Throttling
Throttling limits how often the same item triggers a ping. Set it to a number of seconds: the first change sends a ping immediately, and any further changes to that item within the window are collapsed into at most one more ping once the window closes. This keeps a burst of edits from hammering the receiving system.
On the admin page the throttle can be any value of 1 second or more. Webhooks created through the integration API require a minimum of 15 seconds (larger values such as 600, 3600 or 86400 are recommended).
A note on environments
Webhooks are environment-specific: a webhook fires in Production only when Production is ticked, and in QA only when QA is ticked. Because QA is periodically refreshed with a copy of Production, a webhook that exists only in QA can be wiped on the next refresh — creating it in Production with QA ticked means it carries over into QA with the copy.
Managing webhooks through the integration API
As well as the admin page, webhooks can be managed programmatically through the integration API (API-key authenticated, under the brand's integration path). The endpoints are:
GET /webhooks — list the brand's webhooks.
GET /webhooks/{webhookId} — fetch a single webhook.
POST /webhooks — create a webhook.
DELETE /webhooks/{webhookId} — remove a webhook.
There is no update endpoint — to change a webhook, remove it and create it again. Webhooks created this way always use API v3 and apply to all article statuses (the status filter is admin-only). The throttle must be at least 15 seconds, and the Basic-auth secret is never returned in responses. The create and remove endpoints are documented in the integration Swagger spec — see The integration API: overview for how to read it and API keys and authentication for the key.