Start here

Sandbox

A separate environment with its own keys, its own database and synthetic data. Build against it, not against production.

The base URL#

base url

https://sandbox.trimfitt.com/api/partner/v1

Everything else is identical to production: the header, the scopes, the pagination and the error shapes. Only the host and the key prefix change.

Getting a key#

Ask your integration contact for a sandbox key. It is delivered over a channel you would send a password over, and it is shown once. If you lose it, ask for a rotation rather than a resend, because there is nothing to resend: only a peppered hash is stored.

Sandbox keys are test keys. They are minted against the sandbox partner account and are scoped to the sandbox clinic, so they cannot read anything else.

What is in it#

Data	Sandbox
Catalogue	Eight synthetic products across peptides, weight loss, hormones and sleep. No real pricing.
Clinics	One sandbox clinic, the only clinic your key is granted.
Patients and orders	None. The sandbox starts and stays empty of clinical records.

Because the catalogue is invented, a product you see in the sandbox is not a commitment that it exists in production. The production catalogue is agreed separately.

Test keys only#

A sandbox request needs a tfk_test_ key. A tfk_live_ key presented to the sandbox is refused with 401, in the same shape as an unknown key. The reverse holds too: a test key does nothing in production. The prefix, the stored row and the running environment all have to agree.

A sandbox key is not a production key

Never point production traffic at the sandbox host, and never put a sandbox key in a production secret store. The refusal is deliberate, but a mixed-up deployment spends time debugging a 401 that is working exactly as intended.

Same rules as production#

Scopes are fixed at mint time. A missing scope is 403 forbidden_scope.
Rate limits are the same three ceilings: per key per minute, per key per day, per partner per day.
Every response carries a request id, and every request is logged.
Pagination is a keyset cursor, not an offset.
Nothing is cached: every response is no-store.

The reference pages apply unchanged: Authentication, Catalogue, Pagination, Errors, Rate limits.

Quickstart#

shell

export TFK_KEY='tfk_test_<key id>.<secret>'

# Who am I, and which clinics does this key hold?
curl -s https://sandbox.trimfitt.com/api/partner/v1/me \
  -H "Authorization: Bearer $TFK_KEY"

# The first page of the catalogue
curl -s "https://sandbox.trimfitt.com/api/partner/v1/products?limit=25" \
  -H "Authorization: Bearer $TFK_KEY"

# The next page: pass back next_cursor exactly as received
curl -s "https://sandbox.trimfitt.com/api/partner/v1/products?limit=25&cursor=<next_cursor>" \
  -H "Authorization: Bearer $TFK_KEY"

If the sandbox needs to be reset between test runs, ask your integration contact. The seed is deterministic, so a reset returns the same clinic and the same eight products, but every credential is reissued.