Fill this sandbox with a starter catalogue so every other operation has something to answer
Writes a small starter set into the sandbox the key belongs to: two locations, two sales channels, two suppliers, three products with two variants each, and a stock level for every variant at both locations. Enough that every published read answers rows and every published write has a real channel, location and variant to name.
Send it with a tly_test_ key and no body. It answers 200 whether it wrote anything or not: seeded says whether this call wrote, already_seeded says whether an earlier one did, and written counts the rows this call inserted, per table, which is zero once the sandbox is filled. So a partner's CI can call it before every run and read one shape back.
Nothing is truncated, updated or deleted: every row is inserted on conflict do nothing, so a sandbox somebody has since loaded their own data into keeps it. The ids it writes are stable and prefixed sbx-, and they are not ids to build against: read your ids off variants/table and inventory/table as the examples do, because a sandbox seeded with something else holds different ones.
This is not the multi-season demo book. That is composed from bundles by Tightly and comes through support; this is the starter set an integrator needs on their first afternoon.
A live organisation is refused 409, whatever key was used, and nothing is written.
Scope: sandbox:write, which includes sandbox:read.
Request
- Base URL: https://api.app.tightly.io
- URL: https://api.app.tightly.io/api/v1/sandbox/seed
- Auth: HTTP bearer
Headers
The date train to answer on. One train exists today, 2026-11, the one this reference describes and the one every key is minted on, so the call answers on it with or without this header. Send it anyway, so a client built now names its train from the start.
A string of your own, up to 255 characters, that makes this write safe to retry. Send the same key twice and the second request is answered with the first one's status and body instead of writing again, so a client that retried after a timeout ends holding the record's id rather than creating a second one. Reusing a key with a different body, or while the first request is still running, is refused 409. A write that failed releases its key. Keys answer for 24 hours and belong to the API key that used them. A key longer than 255 characters is ignored and the write goes ahead without the guarantee.
Request body
No fields. The sandbox is the key's own organisation and the set is fixed.
Response
The sandbox as this call left it. written counts the rows this call inserted, per table, so the first call reports the starter set and every call after it reports zeros beside already_seeded: true. One success code either way, because a repeat creates nothing and a client should read what happened out of the body rather than out of the status.
Changes
No recorded changes to this operation across all 1 revision of this API.