Step 3

Test and monitor

Check a payload before you send it, confirm the connection works, then watch what actually happened to every product — including the ones that did not land.

Before you send: validate

The validator runs the same schema and business rules BrandsGateway enforces. It needs no credentials and has no rate limit, so it belongs in your build, not just your browser.

validate

curl -s -X POST 'https://vendors.brandsgateway.com/api/v1/validate' \
  -H 'Content-Type: application/json' \
  -d @product.json

Paste a payload into the browser validator for the same result with the failing fields highlighted. Running it in CI is how you stop a feed change from rejecting thousands of products overnight — see validating in CI.

Validating is not sending

A payload that validates can still be rejected on arrival — a barcode another vendor already lists, or a brand we do not have a mapping for. Validation catches everything we can know without asking the platform.

Confirm the connection

Sign in and open your dashboard. It checks your credentials against BrandsGateway and gives you the exact commands to run from your own system, already filled in with your vendor ID. If the read test returns a product list, you are ready to write.

What can happen to a product

Every product you send is recorded with one of these outcomes. They are the same words used in your dashboard and in the API.

Outcome	Meaning
`created` Created	New product published on BrandsGateway.
`updated` Updated	Existing product matched on _external_id and refreshed.
`unchanged` Unchanged	Payload identical to the last accepted version — nothing sent.
`skipped` Skipped	Deliberately not sent (no sellable variation, or a duplicate feed row).
`failed` Failed	Rejected. The reason is recorded against the product.
`reset` Set to zero	Present on BrandsGateway but absent from this run — stock set to zero.

Nothing disappears quietly

A product removed from your feed is set to zero stock, not deleted, and is recorded as reset. A product we could not accept is recorded as failed with a stable reason code — never dropped silently.

Watch it over time

Products lists every product you have sent with its outcome, filterable by outcome and by error code. Failures are grouped by cause, so one mapping fix can clear hundreds of rows at once.

Runs shows each sync as a whole: how many rows your feed offered, and how they broke down. A run whose accepted count drops sharply is usually a feed problem, not a platform one.

When something fails

Every rejection carries a stable code. Look it up in the error reference — each entry names the field, the cause and the fix. Codes in your dashboard link straight to the right entry.

If a value simply has no mapping yet — a brand or colour we do not know — the response names what we do accept, and the missing value is queued for BrandsGateway to add. You do not need to raise a ticket.

Monitoring from your own systems

Reading this over HTTP — runs, per-product outcomes and failure statistics, for your own graphs and alerts — is not available yet. The dashboard above is the whole of it today, and every send already answers with its own outcome, so an integration can log what happened as it goes.