IFTTT Webhook Tester
Test IFTTT Maker webhooks with custom JSON payloads, free, no sign-up, 100% private.
How to use this tool
Test IFTTT webhooks without leaving your browser
Free IFTTT Webhook Tester sends a POST request straight to maker.ifttt.com with your event name, key and up to three JSON values, exactly like your applet expects. Use it to debug automations, verify keys and confirm that your service receives the payload.
How to test an applet
- Create a Webhooks applet on IFTTT and copy your key from the Webhooks service page
- Enter the event name and your key above
- Add value1, value3 if your applet uses them and send
Good to know
- The request goes directly from your browser to IFTTT. No proxy server
- A successful test only means IFTTT accepted the trigger; check the applet's activity log for the action
- Your key is never stored or logged
How the webhook test works
IFTTT webhooks are plain HTTPS endpoints: the key sits in the path and an optional JSON body carries up to three values. The tester sends a real request from your browser (subject to CORS, so IFTTT's response may be opaque) and reports the HTTP status, timing and raw response where readable. A 200 confirms the key and event name are valid; 401 and 404 point at a wrong key or event. The test does not prove the applet's downstream action ran, check the applet activity log for that.
Formats, limits and parameters
| Property | Webhook tester behavior |
|---|---|
| Input | Event name, IFTTT key, optional JSON values |
| Request | Direct from the browser to maker.ifttt.com |
| Reports | HTTP status, timing, readable response when allowed |
| Stored by 0Appz | Nothing: the key never reaches our servers |
| Cost | Free, no account, unlimited tests |
Privacy: nothing passes through 0Appz
An IFTTT key can trigger real automations, so sending it to a third-party tester is a genuine risk. Here the request leaves your browser directly for IFTTT: the key is typed into the page, used locally and never transmitted to us or stored anywhere.
Webhook debugging checklist
- Verify the event name matches the applet exactly. It is case-sensitive.
- Re-copy the key from the Webhooks settings page; spaces break it.
- Check the applet is connected and turned on.
- Remember CORS may hide the response even on success; use the activity log.
- Rotate the key if it was ever pasted into an untrusted tool.
Related: browse the developer tools for headers, webhooks and API debugging.
Webhooks, payloads and response codes
A webhook is just an HTTP request a service makes to a URL you control, and testing one means reproducing that request faithfully. The method is almost always POST, and the body is usually JSON, so the Content-Type header must say application/json or the receiving automation may reject the payload. IFTTT's Webhooks service is a special case: it accepts three values, named value1, value2 and value3, which can be sent as a JSON body or as URL-encoded form fields in the query string. Keeping within those three fields is the main design constraint, so pack structured data into a single JSON string in value1 when you need more. Response codes tell you what happened: a 200 means the service accepted the event, 400 usually means malformed JSON or a missing field, 401 or 403 means the key is wrong or revoked, and 404 means the event name does not exist. A 500 is the service's problem, not yours, and retrying the same request is reasonable. Two operational notes: many services deduplicate identical payloads, so a test that sends the same body twice may only trigger once, and network intermediaries may cache or block requests without the right headers. When testing, verify the response body as well as the status code, because some APIs return 200 with an error object inside.
Frequently asked questions
How do I test my IFTTT webhook? +
With this tool: enter the Maker event name, your key from ifttt.com/maker_webhooks and a JSON payload with value1, value3, then Send. You get the HTTP status, response body and latency instantly, plus a request history.
What if the response cannot be read (CORS)? +
Some networks block reading the reply. Your applet may still have fired, use "Send blind" (no-cors fire-and-forget) and check the applet activity page, or copy the equivalent cURL command and run it in a terminal.
Is my Maker key safe? +
Yes. Requests go directly from your browser to maker.ifttt.com; the key is never sent to or stored on 0Appz servers. Only the event name (never the key) is remembered locally, and the history log stores statuses without keys.