Test mode
Every partner has two kinds of key, distinguished by the bearer prefix:
pk_live_…, production. Claims and onboardings are real: they enter document generation, billing, and the rest of the pipeline, and onboarding emails are sent.pk_test_…, sandbox. Identical behaviour (same endpoints, shapes, validation, and error codes), but every write is isolated from production data: claims and onboardings never trigger document generation, billing, or any pipeline, and no onboarding emails are sent.
Use a test key to build and verify your integration end-to-end without creating
real claims or contacting real businesses, then switch to your pk_live_ key
for production (a separate key, see the note below).
A key's mode is set when it is issued, and the bearer prefix must match the key's
mode or the request is rejected with auth_bad_secret.
In test mode, POST /connect-requests returns a deterministic, non-redeemable
token (expires_at is null): the call never contacts or connects a real user,
so you can exercise the request itself safely. Because the token cannot be
approved, testing the document and claim endpoints still requires a connected
entity_id: ask your Garfield contact for a sandbox entity. Writes made with a
test key stay isolated from production data regardless.