Studio httpput Retries Silently Break Content-Type After a 429
The error com.capeclear.capeconnect.transport.BadRequestException: error from returned HTTP status: 429 Too Many Requests URL= : Retrying in 13000 msec. (esbHttpRequestId=65146305-0d26-4457-094f-1d265d177c66)
com.capeclear.capeconnect.transport.BadRequestException: error from returned HTTP status: 415 {"errors":[{"code":1008,"message":"Unsupported media type \"text/plain\" in request.","field":""}]}
What it means
The third-party API is rate-limiting the integration (429 Too Many Requests) and Studio's httpput component automatically retries the call after the suggested delay - but on some retries the retry logic resends the request with the wrong Content-Type header (e.g. text/plain instead of application/json), so the retry itself fails with a 415 that has nothing to do with the original rate limit.
Troubleshooting
- Confirm from the logs that the 415 only happens on retried calls, not on the initial calls that succeed - that isolates it to the retry path, not the base request.
- Inspect exactly how the httpput component is configured to retry (built-in retry vs a custom loop) and whether it re-serializes the payload or replays the original byte stream with a fresh Content-Type default.
- Explicitly set the Content-Type header on every retry attempt rather than relying on the component's default, since defaults can differ between the first send and a retried send.
- Add logging around each retry attempt that prints the outgoing Content-Type so a recurrence is caught immediately instead of being rediscovered from scratch.
⚡ Quick fix
Hard-code the correct Content-Type header (e.g. application/json) on the retry path so it cannot silently fall back to text/plain.
✓ Permanent fix
Build exponential backoff with a capped retry count instead of relying on the component's default retry behavior, and specifically test the retry path, since it is the code path least exercised in normal operation.
Was this helpful?