Skip to main content
Every workspace has a sandbox. Use a test key and the API returns fixture data, charges nothing, and behaves identically in every other respect.
There is no separate base URL. The key prefix — unif_sk_test_ — decides the environment, so switching is a matter of changing one environment variable.

What is the same

The full schema

Same fields, same types, same envelope. A client written against the sandbox works unchanged against live data.

Validation and errors

Invalid parameters fail with the same codes. Coverage rules and filterability are enforced identically.

Pagination and jobs

Cursors work, jobs run through their statuses, and webhooks deliver with real signatures.

Rate limits

Enforced at the same thresholds, so you can exercise your backoff path.

What is different

Fixture data is stable, not realistic. It is built so that assertions do not break, which means it will not reproduce data-shaped problems — a market with weekly-only granularity, a creator with a null agency, an ambiguous product. Test those against live data with a small budget before you ship.

Deterministic fixtures

The same request returns the same rows every time, so you can assert on values:
Known fixture IDs are listed in the dashboard under Settings → Sandbox, so you can write tests against a specific shop or product rather than whatever happens to rank first.

Exercising the paths that are hard to reach live

The fixture set includes entities that deliberately trigger each edge case.
Point CI at the sandbox and keep live keys out of it entirely. A test suite that spends credits will eventually spend a lot of them on a branch nobody merged.

Webhooks in the sandbox

Sandbox webhooks deliver real signed requests with their own secret, so your verification code is exercised properly. Register an endpoint with a test key and it fires on sandbox jobs and trackers only — sandbox events never reach a live endpoint, and vice versa.