Overview
Error handling changes affect all API endpoints, providing improved debugging capabilities and standardized error responses.Key Changes in v2:
- Standardized format: All errors use 
{meta, error}envelope with consistent structure - Request IDs: Every response includes 
meta.requestIdfor debugging - Enhanced error structure: Errors follow RFC 7807 Problem Details format
 - Better debugging: Improved error context and troubleshooting information
 
Error Response Format Changes
v1 Error Format → v2 Error Format
- Basic Error Structure
 - Validation Error Structure
 
Error Response Migration
Error Code Mapping Table
The following table provides a comprehensive mapping of v1 error codes to their v2 equivalents:HTTP Status Errors
| v1 Error Code | HTTP Status | v2 Error Type | v2 Category | Description | 
|---|---|---|---|---|
BAD_REQUEST | 400 | https://unkey.com/docs/errors/unkey/application/invalid_input | Application | Invalid request parameters or malformed input | 
UNAUTHORIZED | 401 | https://unkey.com/docs/errors/unkey/authentication/key_not_found | Authentication | Missing or invalid authentication | 
FORBIDDEN | 403 | https://unkey.com/docs/errors/unkey/authorization/forbidden | Authorization | Insufficient permissions for the requested action | 
NOT_FOUND | 404 | https://unkey.com/docs/errors/unkey/data/key_not_found | Data | Requested resource does not exist | 
CONFLICT | 409 | https://unkey.com/docs/errors/unkey/data/conflict | Data | Resource conflict (e.g., duplicate creation) | 
PRECONDITION_FAILED | 412 | https://unkey.com/docs/errors/unkey/application/precondition_failed | Application | Required preconditions not met | 
TOO_MANY_REQUESTS | 429 | https://unkey.com/docs/errors/unkey/application/rate_limited | Application | Rate limit exceeded | 
INTERNAL_SERVER_ERROR | 500 | https://unkey.com/docs/errors/unkey/application/internal_error | Application | Unexpected server error | 
DELETE_PROTECTED | 403 | https://unkey.com/docs/errors/unkey/authorization/delete_protected | Authorization | Resource cannot be deleted due to protection rules | 
Key Verification Specific Codes
| v1 Verification Code | v2 Error Type | Description | Migration Notes | 
|---|---|---|---|
VALID | N/A | Key is valid and verification successful | No error - successful response | 
NOT_FOUND | https://unkey.com/docs/errors/unkey/data/key_not_found | Key does not exist or has been deleted | Same as HTTP 404 NOT_FOUND | 
FORBIDDEN | https://unkey.com/docs/errors/unkey/authorization/forbidden | Key is not allowed to access this API | Same as HTTP 403 FORBIDDEN | 
USAGE_EXCEEDED | https://unkey.com/docs/errors/unkey/data/usage_exceeded | Key has exceeded its usage limit | New specific error type in v2 | 
RATE_LIMITED | https://unkey.com/docs/errors/unkey/application/rate_limited | Key has been rate limited | Same as HTTP 429 TOO_MANY_REQUESTS | 
UNAUTHORIZED | https://unkey.com/docs/errors/unkey/authentication/unauthorized | Key authentication failed | Same as HTTP 401 UNAUTHORIZED | 
DISABLED | https://unkey.com/docs/errors/unkey/authorization/key_disabled | Key has been disabled | New specific error type in v2 | 
INSUFFICIENT_PERMISSIONS | https://unkey.com/docs/errors/unkey/authorization/insufficient_permissions | Key lacks required permissions | Enhanced RBAC error in v2 | 
EXPIRED | https://unkey.com/docs/errors/unkey/data/key_expired | Key has expired | New specific error type in v2 | 
Migration Code Examples
- Basic Error Handling
 - Error Categorization
 
v1 vs v2 Error Handling
Error Documentation
For comprehensive information about specific error codes, causes, and resolution steps, refer to the error documentation:Common Error Categories
- Application Errors: Invalid input, assertion failures, service unavailable
 - Authentication Errors: Missing, malformed, or invalid keys
 - Authorization Errors: Insufficient permissions, disabled keys, workspace access
 - Data Errors: Resource not found, conflicts, data validation issues
 
Error Troubleshooting
- Request IDs: Always include the 
meta.requestIdwhen contacting support - Error Types: Use the 
typeURL for detailed documentation about specific errors - Validation Errors: Check the 
errorsarray for field-specific validation failures - Status Codes: HTTP status codes indicate the general category of the error
 
Common Error Migration Issues
Problem: Error handling code not working after migration Symptoms:- Errors not being caught properly
 - Missing error details that were available in v1
 - Unable to determine error type or category
 
- 
Update Error Access Pattern
 - 
Handle New Error Structure
 - 
Error Categorization
 - 
Retry Logic for Retryable Errors
 
Migration Considerations
When migrating error handling code:- Update error parsing to access 
response.errorinstead of direct error access - Extract 
meta.requestIdfor logging and support requests - Handle the new RFC 7807 format with 
title,detail,status, andtypefields - Process validation errors from the 
errorsarray for detailed field-level feedback