wire ▸ make opened 0
MakeVisual scenario automation

Use Writ
inside Make.

Drop a real, logged-in browser into a Make scenario as one HTTP module.

Get started See how it fits
Writ runs on your own accounts, with your own credentials and data, on sites you are authorized to use.
gap ▸ hits a wall 1
01
the gap

Where Make alone hits a wall

Make's visual scenarios chain modules across many apps, but each module still needs an API on the other end. A site with no API (especially one behind a login and 2FA) has no module, and Make can't drive a browser through it on its own.

fit ▸ one step 2
02
how it fits

Writ becomes one step in your Make flow

Writ slots into a scenario as an HTTP module. Add an "HTTP → Make a request" module that POSTs to the Writ endpoint /v1/{slug}/{path} with your wt_ key; Writ runs the recorded browser workflow on your account and returns JSON that later modules map from. To start a scenario on a change, use a "Custom webhook" trigger and have Writ POST to it.

Make flow
triggers & steps
→
Writ endpoint
browser on your account
→
JSON result
back in Make
login + 2FA CAPTCHA dynamic JS wt_key
wire ▸ steps captured 4
03
wire it up

Connect Writ with Make

  1. 1

    Record and publish in Writ

    Record the login-gated browser action in Writ and publish it as a managed endpoint.

  2. 2

    Add an HTTP module in Make

    In your scenario, add "HTTP → Make a request" pointed at /v1/{slug}/{path}, with the wt_ key in the Authorization header and JSON body.

  3. 3

    Attach a persona

    Attach a persona in Writ so login, TOTP, and mailbox-OTP 2FA run on your own account; parse Writ's JSON response in the module.

  4. 4

    Map or trigger

    Map the returned fields into downstream modules, or drive it the other way with a Make "Custom webhook" trigger that Writ posts to on a page change.

The call Make makes

make-http-module · http 
// Make → HTTP "Make a request" module
URL:     https://api.usewrit.app/v1/{slug}/{path}
Method:  POST
Headers:
  Authorization: Bearer wt_xxx
Body type: Raw (application/json)
Request content:
{
  "input": { "listingId": "{{1.id}}" }
}
Parse response: Yes

A representative request. The endpoint is /v1/{slug}/{path}; authenticate with a wt_ key. API reference.

split ▸ who does what 4
04
better together

Make + Writ, side by side

An honest split of who does what. Writ never replaces your orchestrator; it reaches the part it can't reach alone.

What you need Make alone Make + Writ
Chaining apps that have APIs Make's core strength: visual multi-app scenarios ✓Stays in Make; Writ is one HTTP module
A site with no module / API No module exists; the site can't be reached ✓Writ exposes it at /v1/{slug}/{path} for the HTTP module
Logged-in pages behind 2FA No durable in-browser login session ✓Runs on your authorized session; TOTP + mailbox OTP handled
CAPTCHA on your own accounts Not an in-scenario capability ✓Handled inside the Writ browser run
Dynamic / JS-heavy pages HTTP module fetches raw markup, not a rendered page ✓Real browser renders and waits before extracting
Trigger a scenario on a page change Watches app events, not arbitrary page changes ✓Writ posts to a Make custom webhook on a change
ask ▸ common questions 5
05
faq

Common questions

How do I call Writ from Make?
Use the "HTTP → Make a request" module: POST to /v1/{slug}/{path} with your wt_ key in the Authorization header, enable response parsing, and map the JSON in later modules.
Can Writ start a Make scenario?
Yes. Add a "Custom webhook" trigger in Make and have Writ POST to it (via a Monitor or webhook) when a watched page changes.
Does Writ replace Make?
No, they compose. Keep your visual scenario and multi-app modules in Make; let Writ handle the one browser step on a no-API, login-gated site.
Whose credentials does the browser use?
Yours. Writ runs on your own account with a persona carrying login and 2FA; Make never handles the credentials.