Integrating with the system has two parts that work together:
An HTTP API — read, create, update and delete data in the system.
Webhooks — get notified (a "ping") when data changes or an event happens, so other systems can react.
How an integration usually works
The recommended pattern is to subscribe to webhooks for the data you care about, and when a ping arrives, fetch the current state from the HTTP API. You only do work when something actually changed. When you need more than one item, use the bulk by-numbers endpoints rather than a loop of single requests — one bulk call is far faster and uses a single rate-limit slot. Webhooks are covered in Webhooks; the key you'll authenticate with is in API keys and authentication.
API versions
Endpoints are prefixed with a version, and the versions run side by side — an existing integration doesn't have to migrate unless it wants new functionality.
v3 — newest. Currently covers articles only, in two forms: channel-aware (v3/articles), which returns data per channel keyed by channel key — see Channels — and season-aware (v3/articles-with-seasons). New brands must use v3 for article data.
v2 — stable. Used for components, and for articles only where a brand was already on v2 (gated by an allowlist; a 403 on a v2 article endpoint means the brand isn't allowlisted and should move to v3).
v1 — older legacy endpoints, kept for existing integrations. Not used for new work.
Environments
There are two environments:
Production — https://app.resourced.com
QA / Test — https://qa.findsourcing.com
The QA database is regularly replaced with a fresh copy of Production, so QA holds realistic data for building and testing. QA can run a few days ahead of Production.
Endpoint paths and the Swagger reference
Integration endpoints sit under /api/integration/{brandId}/{version}/... — for example an article fetch looks like /api/integration/{brandId}/v3/articles/{articleNumber}. Your Brand ID and API key are on the User admin page (see API keys and authentication).
The full, current list of endpoints lives in the integration Swagger spec — an interactive reference that documents every endpoint except authentication.
How it's structured:
Select a definition — the dropdown at the top-right switches specs. Use Resourced Integration API V1; the Backend API definition is for internal use.
Tags — endpoints are grouped under Articles and Integration. Expand a tag to see its operations.
Operations — each row is one endpoint, showing its HTTP method and path. Click a row to expand its parameters, request body and example responses.
Authorize — paste your API key here to send live requests straight from the page with Try it out.
The spec is currently published as an alpha version (OpenAPI 3.0), so endpoints may still change.
Pagination, errors and rate limits
Pagination — list endpoints wrap results in an envelope with an items array and a pagination object (count, totalCount, hasMore, offset, limit). The default limit is 50 and is capped at 200; asking for more returns a 400. Page with offset + limit until hasMore is false.
Errors — a failed request returns its HTTP status code plus a JSON body with title, message and errorCode fields (for example, a 400 with the message Limit cannot exceed 200). The one exception is 429 Too Many Requests, which returns a plain-text body.
Rate limits — the article and component endpoints are limited per API key (by the x-api-key header), as concurrent in-flight requests: up to 15 at once for articles and 2 for components. Requests aren't queued — over the limit they're rejected immediately with a 429 and no Retry-After header, so lower your concurrency and retry.