Building against a sandbox

You can build and test the entire integration, including your field mapping, before a single real consult goes through it.

Getting credentials

Ask us and we issue a second client_id and secret. Connect them exactly the way you connect production credentials, against any WisePaws account. No subscription is required.

What a sandbox does and does not do

A sandbox connection validates every request exactly as production does. The same refusals for a missing idempotency key, an unsupported note format, an off-contract WAV, or a key reused with a different recording. Your request handling gets a real workout.

What changes is the expensive part. No audio is stored, nothing is transcribed, and the note comes back ready within milliseconds carrying fixture content under the real section keys.

Two things you cannot exercise in a sandbox, because nothing actually generates:

• the failed statuses and their error codes
• warnings, including the incomplete-audio one

Build those paths from the reference and the failure guide. The sandbox will never produce them, so a sandbox that passes is not evidence your failure handling works.

It is a separate partner, not a flag

This is the part worth understanding, because it is what makes the sandbox safe.

Test mode is a property of the credentials we issue you, not something you send on a request. Your production client_id can never return a fixture. There is no way to leave test mode switched on by accident and hand a vet a fabricated note, because the production credentials have no test mode to leave on.

Point it at a test account

A sandbox connected to a working clinic still files fabricated consults into that clinic's records.

We do what we can about this: sandbox notes are titled [TEST], and the consent screen warns the vet before they approve. But those are warnings, not a barrier. Connect your sandbox to a test account.