Error Handling
The Soku API uses standard HTTP status codes and returns structured error responses with machine-readable codes, human-readable messages, and request identifiers for troubleshooting.Error Response Format
All error responses follow a consistent JSON structure:Error Types
Error Codes Reference
400 Bad Request
validation_error
One or more fields in the request body are missing, malformed, or contain invalid values.
upload_failed
The media URL provided in the request could not be downloaded or stored.
missing_integrations
One or more platform targets in the request are not connected to your Soku account.
missing_account
The specified accountId does not exist for the given platform, or you have multiple accounts for a platform and did not specify which one to use.
401 Unauthorized
unauthorized
The request is missing authentication credentials, or the provided credentials are invalid.
402 Payment Required
insufficient_credits
Your account does not have enough AI credits to complete the requested operation.
403 Forbidden
forbidden
The request was authenticated but the account does not have permission to perform the action. This typically means your subscription is not active.
404 Not Found
not_found
The requested resource does not exist.
409 Conflict
idempotency_conflict
The same idempotency key was used with a different request payload.
429 Too Many Requests
rate_limit_exceeded
You have exceeded the rate limit for your tier.
Retry-After header with the number of seconds to wait.
Solution: Wait the number of seconds specified in the Retry-After header before retrying. Implement exponential backoff in your client. See Rate Limits for best practices.
500 Internal Server Error
dispatch_failed
The post was created but delivery to one or more platforms failed during dispatching.
post_creation_failed
An internal error occurred while creating the post.
requestId.
internal_error
A general internal server error.
requestId.
HTTP Status Code Summary
Error Handling Best Practices
Use the error code, not the message
Always base your error handling logic on theerror.code field, not error.message. Messages may change between API versions; codes are stable.
Log the requestId
Always log therequestId from error responses. This value is essential for debugging with Soku support.
Implement retry logic for transient errors
Errors with status codes429 and 500 are often transient and can be resolved by retrying:
Validate before sending
Check required fields and data formats on the client side before making an API call. This reduces unnecessary requests and avoids hitting rate limits with invalid payloads.Getting Help
If you encounter persistent errors or need assistance debugging an issue:- Note the
requestIdfrom the error response. - Note the timestamp and the endpoint you called.
- Contact Soku support with these details for faster resolution.