Overview
This guide covers how to handle errors from the Shipstar API, including common error codes, response formats, and best practices for building resilient integrations.Error Response Format
All API errors return a JSON response with adetail field:
HTTP Status Codes
Client Errors (4xx)
| Status | Name | Description |
|---|---|---|
| 400 | Bad Request | Invalid request parameters or validation failure |
| 401 | Unauthorized | Missing or invalid API key / JWT token |
| 402 | Payment Required | Insufficient credits for the operation |
| 403 | Forbidden | Not authorized to access this resource |
| 404 | Not Found | Resource doesn’t exist |
| 409 | Conflict | Resource already exists (duplicate) |
| 422 | Unprocessable Entity | Input validation error |
| 429 | Too Many Requests | Rate limit exceeded |
Server Errors (5xx)
| Status | Name | Description |
|---|---|---|
| 500 | Internal Server Error | Unexpected server error |
| 502 | Bad Gateway | External service error (GitHub, etc.) |
| 503 | Service Unavailable | Service temporarily unavailable |
Common Errors and Solutions
401 Unauthorized
401 Unauthorized
402 Insufficient Credits
402 Insufficient Credits
- Monthly credit allocation exhausted
- Wait for credits to reset at the next billing cycle
- Upgrade your plan for more credits
- Check your usage in the Dashboard under Subscription
403 Forbidden
403 Forbidden
- Accessing a resource that belongs to another project or team
- Attempting an admin-only operation
- Check that your API key belongs to the correct project
- Verify your account permissions
404 Not Found
404 Not Found
- Content ID doesn’t exist
- Public slug doesn’t match any published content
- Resource has been deleted
- Verify the content ID or slug
- Check that the content hasn’t been deleted or unpublished
409 Conflict
409 Conflict
- Attempting to create a duplicate resource
- Check if the resource already exists before creating
- Use update endpoints instead of create
429 Too Many Requests
429 Too Many Requests
- Exceeded requests per minute limit
- Implement exponential backoff
- Respect the
retry_aftervalue - Cache responses where possible
502 Bad Gateway
502 Bad Gateway
- GitHub API is unavailable or returning errors
- Other external service failure
- Retry after a short delay
- Check if GitHub is experiencing an outage
Implementing Error Handling
Basic Error Handling
With Retry Logic
Handling Content Generation Failures
Content generation is asynchronous, so you need to handle failures in your polling logic:Rate Limiting
Shipstar applies rate limits to protect the service. Limits vary by endpoint:| Endpoint Category | Rate Limit |
|---|---|
| Authentication (login) | 10 requests/minute |
| Registration | 5 requests/minute |
| Email verification | 10 requests/hour |
| Password reset | 5 requests/hour |
| Token refresh | 30 requests/minute |
| General API endpoints | 100 requests/minute |
Handling Rate Limits
Best Practices
Handle All Statuses
Account for pending, processing, completed, and failed states in your polling logic
Use Retries
Implement exponential backoff for 429 and 5xx errors
Log Errors
Log errors with context (endpoint, content ID, status) for debugging
Set Timeouts
Don’t poll indefinitely — set a maximum wait time for content generation