API reference
Consult audio in, structured clinical note out.
Status: draft. Every operation below is implemented. Nothing is open to partner traffic yet: no partner has credentials.
For practice management systems embedding WisePaws note generation.
A vet connects their WisePaws account to your product once. From then on, each consult is three calls: submit the audio, poll until the note is ready, and tell us what the vet did with it.
Scope of v1. English SOAP notes only. language and note_format are required when you submit a recording, constrained to a single value each, so adding formats or languages later is additive rather than breaking.
The note is English; the consult need not be. Transcription detects the spoken language and code-switches per phrase, so a consult held partly in another language is transcribed faithfully and still produces an English note. language pins what the note is written in, not what the transcript contains.
Building against a sandbox. Ask us for sandbox credentials and you get a second client_id and secret. A sandbox connection validates every request exactly as production does, with the same refusals for a bad key, an unsupported format or an off-contract WAV, but no audio is stored, nothing is transcribed, no subscription is required and the note comes back ready in milliseconds with fixture content under the real section keys. It is a separate partner, so a production client_id can never return a fixture. Nothing generates, so failed statuses and warnings cannot be exercised there. Point a sandbox at a test account: its notes are titled [TEST] and the consent screen warns the vet, but one connected to a working clinic still files fixtures into its records.
Compatibility. Within /v1 we only add: new fields, new enum values on response-only enums, new warnings, new error codes. Removing a field, removing a request enum value, or changing a type means /v2. Ignore response fields you do not recognise.
Examples. The people, practices, pets and partners in the examples are fictional.
Base URL
https://api.wisepaws.vet, production.
Authentication
The connection_token from /v1/connections/exchange, as Authorization: Bearer <token>.
One token per vet per practice, not per vet. It identifies both, which is why no request carries a user or practice identifier, and why a vet who works across more than one practice connects once for each and ends up holding several.
So key what you store on your user and the site the consult belongs to. Keyed on the user alone, a second connection overwrites the first and that practice's notes stop. GET /v1/connection returns practice_name, which is how you tell two tokens for the same vet apart. It does not expire on a timer: a vet forced to re-authorise mid-consult would be a worse failure than a long-lived credential. But it stops working the moment they disconnect, leave the practice, or their account is deleted. It also stops the moment we disable your integration, which reads as partner_disabled and is the one cause reconnecting the vet cannot fix.