. 🧩 Problem: “Catch Raw Hook” in Zapier seems to mangles binary/gzipped HTTP bodies — not actually “raw”

Summary:

When a service sends a gzipped JSON webhook, the Zapier “Catch Raw Hook” trigger does not preserve the real bytes.

Instead, Zapier replaces invalid UTF-8 bytes with Unicode “replacement characters” (U+FFFD, rendered as �), so the payload becomes unrecoverable.
This breaks all use cases where compressed or binary bodies must be decompressed or verified inside Zapier.

Steps to Reproduce

1. Create a test Zap:

   • Trigger: Webhooks by Zapier → Catch Raw Hook

   • Test & copy the generated URL.

2. Send a gzipped POST body:

   echo '{"hello":"world"}' | gzip | \ curl -X POST "$ZAPIER_URL" \ -H "Content-Type: text/plain" \ -H "Content-Encoding: gzip" \ --data-binary @-

3. Inspect the test trigger sample in Zapier.

What You See in Zapier

Zapier’s trigger output looks like this:

{ "raw_body": "\u001f\ufffd\b\u0000\u0000\u0000\u0000\u0000\u0000\u0000uSMo\ufffd0\u0014...", "headers": { "content_encoding": "gzip", "content_type": "text/plain; charset=UTF-8" } }

The true gzip header byte 0x8B has been replaced with \ufffd.
Decompression fails 😒
 

Why This Matters

Many modern webhook APIs (security logs, telemetry, IoT, etc.) use gzip or deflate compression for performance.
Without true binary access, Zapier cannot act as an endpoint for those webhooks — users must build an intermediate proxy to decompress before Zapier.

 

Can you please make “Catch Raw Hook” truly raw:

• Do not automatically decode binary payloads as UTF-8 text.

• Provide a binary file field or base64-encoded version.

• Optionally, automatically decompress when Content-Encoding: gzip is present.