Virtual try-on API errors and safe retries
A production integration should distinguish request rejection from accepted asynchronous work. Do not create a new job automatically when a request outcome is uncertain; retry the same action with the same idempotency key.
Request errors
4xx responses cover invalid input, unsafe URLs, authentication, account state, insufficient credits, and rate limits. Correct the cause before a new customer action.
Temporary capacity and gateway errors
Use bounded exponential backoff with jitter. Respect Retry-After when supplied and preserve the original idempotency key.
Terminal generation states
failed and timeout are terminal. TryRobe's credit engine releases locked credits for failed generation paths; integrations should show a clear retry action rather than silently looping.
Frequently asked questions
Should I retry every error?
No. Validation, authentication, permission, and insufficient-credit errors require correction. Retry only temporary failures with limits and the same idempotency key.
What if the client disconnects after submission?
Recover using the stored idempotency key and job history instead of assuming the request failed.