Errors

The drio management API returns two different error families. Which one you get depends on which part of the platform you are calling.

This latest docs set describes v3. If you are debugging a legacy integration, use the archived v2 error docs or archived v1 error docs.

First Question: Which Route Family Failed?

If the failing route is...	Expect this error format
`/.well-known/*`	OAuth-style error response
`/api/v3/me` or `/api/v3/apps/*`	drio resource API error envelope

1. OAuth Errors

Discovery and auth routes use OAuth-style error responses.

Applies to:

/.well-known/*

Example:

{
  "error": "invalid_request",
  "error_description": "Missing required field: refresh_token"
}

Common auth error codes:

invalid_request
invalid_client_metadata
invalid_grant
invalid_token
server_error

2. Resource API Errors

Apps, provider catalogs, and user routes use the drio API error envelope.

Applies to:

/api/v3/me
/api/v3/apps/*

Example:

{
  "error": {
    "code": "not_found",
    "message": "App not found",
    "details": null,
    "request_id": "4c9b58ff-69a7-4ccf-840d-a0f1ec9f9d77"
  }
}

Common Protected Error Codes

bad_request
unauthorized
forbidden
not_found
validation_error
gone
internal_error

Typical Status Codes

Status	Meaning
`400`	Invalid input or malformed auth request
`401`	Missing, invalid, or expired bearer token
`403`	Authenticated but not allowed to access that resource
`404`	The requested route or resource does not exist
`410`	The requested API version has been removed
`422`	The request shape was valid JSON, but failed validation
`500`	Unexpected server-side failure

How To Debug Faster

if the failure came from /.well-known/*, debug it as an OAuth discovery issue
if the failure came from /api/v3/apps/* or /api/v3/me, debug it as a resource API issue
use request_id from the resource envelope when coordinating support or log lookup