Free tool · no sign-up

Free Slack webhook error decoder

Paste whatever Slack gave you back. The decoder finds every known error in your text, explains what it means, and gives you the exact fix, no API doc spelunking.

Paste your error

Anything Slack gave you back, full response body, just the error string, the HTTP status line, all of it pasted together. We'll find the matches.

Try a sample:
no_serviceHTTP 404

Webhook URL no longer exists

Slack doesn't recognise the webhook ID at all. The URL is either malformed beyond recognition or the underlying integration was deleted.

Common causes
  • Webhook was revoked from the Slack workspace's incoming webhooks settings
  • Slack app the webhook belonged to was uninstalled or deleted
  • The URL was typed wrong by one character (the last 32 chars are the secret token)
Fix: Generate a new incoming webhook in Slack: Settings & administration → Manage apps → Incoming webhooks → Add to Slack. Paste the new URL into your script (or your RouteForms dashboard). The old URL is permanently dead, you can't un-revoke it.
Full reference

Every Slack webhook error code this decoder recognises, with the HTTP status and a one-line meaning.

CodeHTTPWhat it means
no_service404Webhook URL no longer exists
no_team404Slack workspace not found
invalid_payload400Slack couldn't parse the JSON body
invalid_blocks400Block Kit structure rejected
invalid_blocks_format400blocks field isn't an array
invalid_token403URL secret rejected
channel_not_found404Target channel doesn't exist
action_prohibited403Workspace policy blocked the post
rate_limited429Too many posts in too short a time
user_not_found404User mention doesn't resolve
missing_text_or_fallback_or_attachments400Message has no fallback text
http_405405Wrong HTTP method
timeoutSlack didn't respond in time
The Slack error vocabulary

Why these codes are so opaque

Slack's incoming-webhook errors are small strings designed for machine consumption, not human reading. no_servicedoesn't obviously mean “the webhook URL was revoked” until you've looked it up. invalid_payloadsounds like “your JSON is broken” but usually means a missing Content-Type header. action_prohibited looks like a permissions issue but is actually a workspace admin policy. The decoder is the layer between the cryptic string and the actionable fix.

The thirteen codes in the reference table below cover roughly all the Slack errors that appear in production Google-Forms-to-Slack setups. The ones we see most often, in rough order of frequency:

  • no_service, webhook revoked. Usually a teammate rotating integrations or cleaning up old apps.
  • invalid_payload, body format wrong. Almost always a missing or wrong Content-Type, or stray characters in the JSON.
  • rate_limited, too many posts. Bursts during form imports or stuck retry loops in homegrown scripts.
  • channel_not_found, target channel was archived or deleted.
  • missing_text_or_fallback_or_attachments, blocks-only payload without a top-level text field. Slack needs the text for accessibility fallback.
When this saves time

The three moments

  • Reading an Apps Script Executions log. Apps Script logs the response body when UrlFetchApp throws. You see {"ok":false,"error":"invalid_blocks"} and want to know what to fix, paste it here, get the explanation, fix the block, redeploy.
  • Debugging a homegrown server-side relay. Your server posts to Slack on behalf of your form receiver. The relay logs a 400 from Slack with a small response body. The decoder maps the body to the fix without you reading api.slack.com.
  • Handing off a broken integration. A teammate sends you a screenshot of an error. Paste it here, send back the fix. Saves a round trip.
When Slack errors disappear entirely

What RouteForms does with this for you

The decoder is reactive, you've already got an error and you're backing into the fix. RouteForms's delivery log is proactive: every Slack POST is recorded with the HTTP status and a decoded reason already on the row. When a delivery fails, you see “Slack returned 404 / no_service, webhook revoked” directly in the dashboard, and a Retry button next to it. No copying error strings between tabs.

FAQ

Frequently asked questions

What does the decoder do?

It takes whatever Slack gave you back when your webhook POST failed, a full response body, the HTTP status line, or just the error string, and tells you what it means, what usually causes it, and how to fix it. Slack's error vocabulary is small but oddly named (no_service, invalid_payload, channel_not_found, action_prohibited); each code looks cryptic until you've memorised what it stands for. The decoder is the lookup table.

How is this different from the webhook checker?

The webhook checker (at /tools/slack-webhook-tester) does a live POST to your URL and reports back what Slack said, you get a fresh response. The error decoder is the offline interpreter, you already have an error (from a script log, a developer console, a screenshot) and want to know what it means without sending another request. They're complementary: webhook checker for 'is this still alive?', error decoder for 'what does this error code I'm staring at actually mean?'

What errors does it recognise?

The thirteen most common Slack incoming webhook responses: no_service, no_team, invalid_payload, invalid_blocks, invalid_blocks_format, invalid_token, channel_not_found, action_prohibited, rate_limited, user_not_found, missing_text_or_fallback_or_attachments, HTTP 405 method-not-allowed, and timeout. If Slack returns something not in this list, the decoder tells you so explicitly, usually that means the response was truncated when copied, or the failure happened before reaching Slack (DNS, TLS, firewall).

Can I paste the raw HTTP response?

Yes. The decoder substring-matches against the input so you can paste whatever you have, the full curl output, the response body alone, a screenshot transcription, an error message your script logged. If multiple known codes appear in your paste (sometimes a response includes the error name in JSON and again in a debug header), the decoder shows a card for each.

What if I only have an HTTP status code?

Paste just the number — '400', '404', '429', etc. The decoder maps each status to the Slack error codes most likely to produce it. HTTP 404 narrows to no_service / no_team / channel_not_found; HTTP 400 narrows to invalid_payload / invalid_blocks / missing_text_or_fallback. You'll get multiple cards in that case, pick the one whose description matches what you actually observed.

Where do these error codes come from?

Slack's incoming-webhooks endpoint returns them in the response body when a POST fails. They're documented across api.slack.com but spread across several pages, incoming-webhooks, block-kit-builder, errors. This decoder consolidates the ones that actually appear in production with form-to-Slack integrations into one lookup.

Will Slack add new error codes that aren't here?

Slack does occasionally introduce new error responses, especially around new Block Kit features or Enterprise Grid policies. If you hit one we don't recognise, the decoder will tell you 'no known error matched' and you'll fall back to api.slack.com's documentation. We update this list as we see new codes in real failures.

Does this send anything to Slack?

No. Everything runs in your browser, your error text never leaves your machine. There's nothing to send: we're parsing what Slack already returned to you.

Stop manually decoding Slack errors

RouteForms's delivery log decodes every Slack error inline, with one-click retries. Free for 30 responses a month.