Errors and reliability
Design your Closku integration to handle failures gracefully. This page covers common error scenarios, retry logic, validation patterns, and debugging guidance.
Common error codes
The Closku API uses standard HTTP status codes. Your integration should handle each category appropriately:
| Status | Meaning | Handling |
|---|---|---|
| 400 | Invalid request (malformed payload or missing fields) | Fix the request before retrying; no automatic retry |
| 401 | Missing or invalid API credentials | Verify API key and secret; check for rotation |
| 404 | Resource not found | Verify resource IDs; check catalog sync status |
| 429 | Rate limit or usage cap exceeded | Retry after the Retry-After header delay; consider upgrading plan |
| 5xx | Server error | Retry with exponential backoff; check status page for outages |
Failure handling patterns
Most integration failures come from invalid assumptions or stale state rather than infrastructure issues, so design your checks around those realities first. Validate early by checking image resolution, product category, and API credentials before submitting a try-on request. Use idempotency keys for all state-changing requests so retries are safe. For 429 and 5xx responses, retry with exponential backoff using increasing delays of one, two, four, eight seconds up to a maximum of 60 seconds. After max retries, route failed events to a dead-letter queue for manual inspection.
Reliability guarantees
Closku provides a 99.9 percent uptime SLA measured monthly, with try-on rendering typically completing in 10-30 seconds, with a 30-second hard timeout on each job. Cloud infrastructure auto-scales during peak periods, and daily encrypted backups with point-in-time recovery keep data durable.
Debugging posture
Keep enough context to reconstruct what happened without exposing sensitive material. Reliable debugging comes from small, explicit checkpoints instead of broad log volume. Log request IDs returned by the Closku API for every operation, store webhook event IDs to track delivery and processing history, and record state transitions for try-on orders to identify where failures occur.
When a failure pattern repeats, update the boundary or invariant that allowed it rather than adding vague downstream cleanup.
Next steps
Event delivery and retry design.
Complete API endpoint reference.
Related pages
Try-on lifecycle and state management.
Integration sequence overview.