api_key_required
No API key was supplied for an authenticated commercial request.
Errors
How integrations should interpret request failures.
Treat the HTTP status and structured error code as the contract. Avoid relying on message text
alone.
Representative error shape
{
"error": "unsupported_species",
"message": "Commercial API v1 drug list currently supports canine/feline patients only. Use species \"dog\" or \"cat\".",
"details": {
"species": "avian",
"supported_species": ["dog", "cat"],
"future_species": ["avian", "horse"]
}
}Frequent error conditions in partner integrations
invalid_api_key
The supplied key failed validation.
rate_limit_exceeded
The request rate exceeded the current allowance for the issued key.
unsupported_species
The request used a species outside the commercial dog/cat contract.
missing_parameter
A required query or body field was missing.
method_not_allowed
The endpoint was called with an unsupported HTTP method.
Calculation failures should still be handled predictably
Invalid weight
Requests missing or mis-formatting patient.weight_kg should be corrected and retried.
Unsupported workflow
If a workflow is intentionally unsupported, the fix is to change the request rather than retry blindly.
Drug not found
Use exact names returned by /api/drugs or /api/drugs-data, especially for fluid entries.
How partner clients should respond
Prompt for input fixes
Missing fields, bad species values, and unsupported concentration choices should be corrected in the request UI.
Escalate auth issues
Invalid, expired, or access-related failures should route to support or credential-management flows.
Retry loops without change
Unsupported species and validation failures are not transient failures.
Parsing messages only
Use the structured error code and HTTP status as the integration contract.