Workflows: REST block corrupts binary responses (audio/mpeg) - body is UTF-8 decoded before base64 encoding

💬 Workflows
,
1

Hi all,

since roughly the last Retool update our workflow that generates MP3 files via the ElevenLabs API and stores them in Retool Storage produces unplayable files. The setup has been running unchanged for months, and files created before the update are fine. I have narrowed it down to the REST block in Workflows and would like to know whether others see the same behaviour.

Setup

  • Workflow, Loop block (create_audio, execution mode Batched, batch size 5)

  • Loop runner: REST query against https://api.elevenlabs.io/v1/text-to-speech/{voice_id} (POST, header Accept: audio/mpeg)

  • Second Loop block (save_mp3) with Retool Storage as loop runner, action "Upload file", file content {{ value.base64Data }}, file name part-<id>.mp3

  • Retool Cloud, x-retool-api-version: 4.52.0-2338586 (Build 379538)

What happens

The REST block returns the response correctly typed as binary, but the bytes are corrupted. Here is the relevant part of the block output:

json

{
  "data": [{
    "name": "Xb7hH8MSUJpSbSDYk0k2",
    "type": "audio/mpeg",
    "sizeBytes": 750534,
    "base64Data": "SUQzBAAAAAAAI1RTU0UAAAAPAAADTGF2ZjYwLjE2LjEwMQAAAAAAAAAAAAAA77+977+977+977+9AAAA..."
  }],
  "metadata": [{
    "headers": {
      "content-type": ["audio/mpeg"],
      "content-length": ["420928"]
    },
    "status": 200
  }]
}

Two things stand out:

  1. The upstream response is content-length: 420928, but Retool reports sizeBytes: 750534 - almost twice the size.

  2. The base64 payload contains the sequence 77+9 over and over again, right after the ID3 header where the first MP3 frame sync (FF FB) should be. 77+9 is base64 for EF BF BD, which is the UTF-8 encoding of U+FFFD (the replacement character).

Both symptoms point to the same root cause: the binary body is being decoded as a UTF-8 string somewhere in the REST block, every byte that is not valid UTF-8 is replaced with U+FFFD, and the result is then re-encoded to bytes and base64. The ID3 tag survives because it is ASCII only, so file still identifies the result as "Audio file with ID3 version 2.4.0", but there is not a single valid MPEG frame left in the file. ffprobe reports Duration: N/A, 0 channels, and browsers show 0:00 / 0:00.

Downloading the same ElevenLabs response with curl gives a valid MP3 with exactly 420928 bytes, so the API side is fine.

Expected behaviour

For a response with content-type: audio/mpeg, base64Data should be the base64 encoding of the raw response bytes, and sizeBytes should match content-length.

2

Summary

On Retool Cloud, a Workflows REST block that fetches MP3 audio (audio/mpeg) from the ElevenLabs API started returning corrupted binary since a recent update — the raw bytes appear to be UTF-8 decoded before base64 encoding, replacing every non-UTF-8 byte with U+FFFD (EF BF BD / '77+9'), roughly doubling sizeBytes and destroying all valid MPEG frames.

AI Response

This matches a recently reported regression where some Retool DBConnectors were switched from buffering to streaming via a feature flag around 2026-08-25, which causes binary response bodies to be UTF-8 decoded (irreversibly corrupting non-UTF-8 bytes) before base64 encoding. Retool staff acknowledged this and resolved it for an affected org by turning the feature flag off, so reporting this thread with the org subdomain is the fastest path to having the flag disabled. In the meantime, a known workaround is to ensure binary payloads are treated as binary — e.g. serving/storing them with a Content-Type Retool treats as binary such as application/octet-stream — so the read returns an intact base64 body you can decode yourself.

Sources

:bookmark: S3 "Read file from S3" returns UTF-8-mangled binary in Workflows
A same-week report of the identical 'body is UTF-8 decoded before base64' binary corruption, where staff confirmed it was caused by a buffering-to-streaming feature-flag rollout (~2026-08-25) and fixed it by disabling the flag for the affected org.
:bookmark: FR: Workflow Data Usage Breakdown
A feature request that details the root cause — bodies being UTF-8 decoded server-side unless the Content-Type is on Retool's binary allowlist — and reinforces the workaround of using a binary Content-Type like application/octet-stream.

The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a :heart:, :+1:, or :-1:. Or by marking this post as the "Solution"! Let us know if you have any feedback here. :rocket:

3

Hi @Tobias_Sell

Thanks for flagging this! This issue looks to be related to a rollout of changes to DB Connector resources from buffering to streaming with a feature flag. I went ahead and turned off the flag for your organization. Let me know if the issue still occurs after this change.

Thank you!