Incoming webhooks — some requests not processed (encoding in Content-Type)

Update timeline

1. monitoring May 05, 2026, 08:58 PM UTC

   Status: Monitoring Between April 26, 2026, 7:14 PM UTC and April 30, 2026, 4:36 AM UTC, a subset of incoming webhooks to Zapier were not processed during ingestion. Webhooks sent with a Content-Type header that specified a non-UTF-8 character set in the way below were rejected instead of being delivered to your Zaps: Content-Type: application/x-www-form-urlencoded; charset=iso-8859-1 Webhooks using typical UTF-8 Content-Type values were not affected by this issue. If your upstream system sent webhooks matching the pattern above during that time window, those individual events did not trigger your Zaps. Other triggers and webhook formats continued to work as usual. For any specific events that occurred while your app was sending webhooks in that format during the window above, you will need to resend the webhook from the upstream application (for example, by having that app fire the event again or resubmit the payload), so that Zapier receives a new request. Replaying a past run in Zapier does not replace a missing inbound webhook from your app. If you are unsure whether your integration uses that header, check your server or integration configuration for charset=iso-8859-1 (or other non-UTF-8 charset) on application/x-www-form-urlencoded requests to your Zap’s webhook URL.

2. resolved May 05, 2026, 10:37 PM UTC

   Status: Resolved We've implemented an update so webhooks sent with a Content-Type header that specified a non-UTF-8 character set will trigger your Zaps.