Runs onWrit Cloud
On this page
No node to install. Three mechanisms that already work.
To be straight with you: there is no first-party Writ node for n8n, app for Zapier, or module for Make. Do not go looking in a directory. What exists is three generic mechanisms all three tools already speak — and each one is a five-minute setup.
framing ▸ what exists
Pick the direction you need.
The question is which way the call travels. Writ is either the thing your flow calls, or the thing that starts your flow — and OAuth is how a tool holds your credential without you pasting a key into it.
| Mechanism | Use it when |
|---|---|
| Call Writ from the tool | Your flow needs data from, or an action on, a site with no usable API. An HTTP request step does it. |
| Connect with OAuth | You would rather the tool held a revocable grant than a pasted key — and you want its connection UI to configure itself. |
| Receive events from Writ | A change or a finished run should start your flow, rather than your flow polling for it. |
call ▸ http request
1 · Call Writ from the tool.
Publish a workflow as an endpoint, then point the tool’s HTTP Request node — or Webhooks by Zapier, or Make’s HTTP module — at it. That is the whole integration.
http-request-step.sh
curl -X POST https://api.usewrit.app/v1/acme/price-check \
-H "Authorization: Bearer $WRIT_CONSUMER_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/product/42"}' HTTP Request node — field by field
{
"method": "POST",
"url": "https://api.usewrit.app/v1/acme/price-check",
"headers": {
"Authorization": "Bearer csk_...",
"Content-Type": "application/json"
},
"body": { "url": "https://example.com/product/42" }
} | Method and URL | POST to your endpoint path. |
| Authorization | A consumer key you mint for this one integration, sent as a Bearer token. Revoke it without touching anything else. |
| Body | JSON, matching the inputs your workflow declares. |
| Response | Synchronous by default: the call waits and hands the result back inline, ready to map into the next step. |
When a run is longer than the tool will wait
Ask for a handle up front instead. Send Prefer: respond-async, or add ?async=true if the tool’s HTTP step cannot set a header — you get a 202 and a run handle to poll.
async.sh
curl -X POST https://api.usewrit.app/v1/acme/price-check \
-H "Authorization: Bearer $WRIT_CONSUMER_KEY" \
-H "Prefer: respond-async" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/product/42"}'
# Query-parameter form, for tools whose HTTP step cannot set a header:
curl -X POST "https://api.usewrit.app/v1/acme/price-check?async=true" \
-H "Authorization: Bearer $WRIT_CONSUMER_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/product/42"}' The full endpoint contract — paths, status codes, freshness, polling a run handle — lives on Managed endpoints. This page only restates the parts an automation tool needs.
Managed endpoints →oauth ▸ self-configuring
2 · Connect with OAuth.
Writ runs an OAuth 2.0 authorization-code server with PKCE, and publishes a discovery document at /api/oauth/.well-known/oauth-authorization-server. Generic OAuth integrations read that document and configure themselves — endpoints, scopes and PKCE method, without you typing any of them.
discovery.sh
curl https://api.usewrit.app/api/oauth/.well-known/oauth-authorization-server | Client type | How it authenticates |
|---|---|
| Confidential client | The Zapier/n8n style: register the app, then use its client secret. Supported at the token endpoint as client_secret_post or client_secret_basic. |
| Public client | PKCE with no secret at all. Code challenge method S256. |
| Device code | For anything that cannot open a browser redirect — approve on another device. |
You can review every connected app and revoke any of them at any time. Revoking is the point of using OAuth rather than pasting a long-lived key into a third-party tool.
events ▸ into the tool
3 · Have Writ start the flow.
Every one of these tools gives you a catch-hook URL — a Webhook trigger node in n8n, a Catch Hook in Zapier, a Custom Webhook in Make. Point a Writ monitor or automation at it and your flow starts when something actually happens.
- 1 · Copy the catch-hook URL — From the trigger step in your tool.
- 2 · Add it as a webhook recipient in Writ — On the monitor or automation that should start the flow.
- 3 · Verify the signature — Deliveries are HMAC-signed. Check the signature before you trust the payload.
The exact signature contract, header names and a verification snippet live on Webhooks. If your tool cannot verify a signature in-flow, put a small function step in front of it — the alternative is an endpoint anyone can post to.
Webhooks →also ▸ two more doors
Two other ways in.
Not every tool needs an HTTP step. If yours already speaks one of these, use it directly:
reference ▸ next
Keep going
The full contract for a published endpoint.
→ Consumer keysMint one key per integration, revoke it alone.
→ WebhooksThe signature contract, verified.
→ AuthenticationToken families, scopes, OAuth.
→ MCPWorkflows as tools for any MCP client.
→ StreamingThe OpenAI-compatible chat surface.
→faq
Integration questions, answered.
Is there a Writ node for n8n, or a Zapier app?
How do I authenticate the HTTP step?
My run takes longer than the tool will wait. What now?
Will the tool configure OAuth by itself?
Can I revoke a tool’s access later?
Do I need any of this if my tool speaks MCP?
end ▸ wire it
Publish an endpoint and point a step at it.
One HTTP request node is the whole integration, and it works in every tool on this page.