Error Handling
Understanding API error responses, HTTP status codes, and how to handle failures
Error Response Format
All API errors return a consistent JSON structure:
{
"error": "Human-readable error message",
"details": {}
}The details object is optional and contains additional context when available (e.g., validation errors, platform-specific information).
HTTP Status Codes
| Status | Meaning | When It Happens |
|---|---|---|
400 | Bad Request | Invalid parameters, missing required fields, validation errors |
401 | Unauthorized | Missing or invalid API key |
403 | Forbidden | Valid API key but insufficient permissions, feature requires upgrade |
404 | Not Found | Resource doesn't exist or doesn't belong to your account |
409 | Conflict | Resource already exists or is in an incompatible state |
429 | Too Many Requests | Rate limit exceeded |
500 | Internal Server Error | Unexpected server error - safe to retry |
Post Publishing Failures
When a post fails to publish to one or more platforms, the post status reflects the outcome:
| Post Status | Meaning |
|---|---|
published | All platforms published successfully |
partial | Some platforms published, others failed |
failed | All platforms failed to publish |
Each platform entry in the post has its own status and error fields:
{
"post": {
"status": "partial",
"platforms": [
{
"platform": "twitter",
"status": "published",
"platformPostUrl": "https://twitter.com/..."
},
{
"platform": "instagram",
"status": "failed",
"error": "Media processing failed: video too short for Reels"
}
]
}
}Common Publishing Errors
| Error | Cause | Fix |
|---|---|---|
| Token expired | OAuth token needs refresh | Check account health and reconnect |
| Rate limited by platform | Too many posts to this platform | Wait and retry, or space out posts |
| Media processing failed | File format/size not supported by platform | Check platform requirements |
| Duplicate content | Platform rejected identical content | Modify the content slightly |
| Permissions missing | Account lacks required permissions | Reconnect with proper scopes |
Retrying Failed Posts
For failed or partial posts, use the retry endpoint:
const { post } = await late.posts.retryPost('post_123');result = client.posts.retry("post_123")curl -X POST "https://getlate.dev/api/v1/posts/post_123/retry" \
-H "Authorization: Bearer YOUR_API_KEY"This retries only the failed platforms - already-published platforms are skipped.
Account Health
Proactively check if your connected accounts are healthy before publishing:
const health = await late.accounts.getAccountHealth();health = client.accounts.get_health()curl "https://getlate.dev/api/v1/accounts/health" \
-H "Authorization: Bearer YOUR_API_KEY"The health check endpoint returns token validity, permissions status, and recommendations for each account.
Webhook Reliability
If you use webhooks to track post status, note that:
- Webhooks are delivered at least once (you may receive duplicates)
- Failed deliveries are retried with exponential backoff
- You can view delivery logs via the webhook logs endpoint
Best Practices
- Always check the response status code before parsing the body
- Handle
429responses by respecting theRetry-Afterheader - Monitor account health periodically to catch token expirations early
- Use webhooks instead of polling for post status updates
- Log errors with context - include the request body and response for debugging