HTTP Status Codes
Success Codes
200 OK
200 OK
Meaning: Request succeeded.When: All API methods (tokenize, detokenize, mask, redact, hash, synthesize, encrypt) return 200 on success.Example Response:
Client Error Codes
400 Bad Request
400 Bad Request
Meaning: Malformed request or missing parameters.Common Causes:How to Fix:
- Missing required
textparameter - Invalid JSON format
- Invalid entity type specified
- Invalid configuration parameters
- Empty text field
- Verify all required fields are present
- Check JSON formatting
- Ensure
textfield is not empty - Validate entity type names
401 Unauthorized
401 Unauthorized
429 Too Many Requests
429 Too Many Requests
Meaning: Rate limit exceeded.Common Causes:Plan Limits:
- Too many requests in short time period
- Exceeded plan quota
- Burst limit reached
- Free: 500K characters/month, 5K chars per request
- Pay As You Go: Unlimited characters, 500K chars per request
- Implement exponential backoff
- Use the
retry_aftervalue from response - Batch multiple texts into single requests
- Upgrade to Pay As You Go for unlimited usage
Server Error Codes
500 Internal Server Error
500 Internal Server Error
Meaning: Unexpected server-side error.Common Causes:How to Fix:
- Temporary service disruption
- Internal processing error
- Database connectivity issue
- Retry the request after a few seconds
- If error persists, contact support with
request_id - Check status page for service status
503 Service Unavailable
503 Service Unavailable
Error Response Format
All error responses follow a consistent format:Fields Explained
- detail: User-friendly error message explaining what went wrong
- error: Machine-readable error code for programmatic handling
- status_code: HTTP status code
- request_id: Unique identifier for the request (present in 5xx errors)
Handling Errors in Your Code
Python SDK
The Python SDK raises specific exceptions for different error types:JavaScript SDK
The JavaScript SDK throws typed errors:REST API (cURL)
When using the REST API directly, check the HTTP status code:Retry Logic
Exponential Backoff
Implement exponential backoff for transient errors (429, 500, 503):JavaScript Retry Example
Best Practices
Log Request IDs
Always log the
request_id for 5xx errors. This helps support diagnose issues quickly.Implement Retry Logic
Use exponential backoff for rate limits and server errors. Respect the
retry_after value.Validate Before Sending
Validate input locally before making API calls to avoid 400 errors.
Monitor Error Rates
Track error rates in your application. Sudden increases may indicate issues.
Common Error Scenarios
Scenario 1: Authentication Failure
Scenario 2: Missing Required Field
Scenario 3: Rate Limit Exceeded
Getting Help
If you encounter persistent errors:Contact Support
Email support@blindfold.dev with the
request_id from error responses.Status Page
Check current service status and maintenance schedules
API Reference
Full API documentation with request/response examples