Home / Blog / Clio + n8n intake: a Grow lead, a Calendly consult and an auto-reply

Clio + n8n intake: a Grow lead, a Calendly consult and an auto-reply

A Clio and n8n intake build: answer web inquiries, check Clio for existing clients, file a Grow lead and put Calendly consults on the Clio calendar.

By · Published · Updated · 7 min read

Your website form emails you, someone copies the details into Clio Grow, someone else sends the intake form, and when the prospect books a consult in Calendly, someone adds it to the Clio calendar by hand. Each step is small. Together they mean a web inquiry can sit for hours, and a booked consult can be missing from the calendar the attorney actually checks.

We've covered why the reply speed matters and how to word it. This post is the build: how our inquiry intake recipe wires a website form, Clio Manage, Clio Grow, Resend and Calendly together in n8n, and which parts of Clio's and Calendly's docs you need to read before you trust it.

Not legal advice. We build and test automations; we're not lawyers. This is a plain-English summary of primary sources, checked on October 27, 2026. Your state's rules on advertising, prospective clients and client communication control.

Check what Clio already does first

Build only what Clio doesn't already cover:

  • Clio Grow has its own intake forms and automated workflows, and can send a form or email when a lead comes in. If your website form can feed Grow directly and that's all you need, you don't need n8n.
  • Clio's AI intake features. Clio's product terms describe optional Grow AI features (web chat, email and voice agents, consult scheduling). We haven't tested them.
  • Calendly's own integrations. Check whether one of them covers your calendar sync before you build a custom one.

The build below earns its keep when you want things the built-ins don't do together: a check for existing clients before intake goes out, an urgent alert for hearing dates, a polite decline with a bar referral for matters you don't handle, and booked consults written to the Clio calendar with a conflict-check reminder.

What the workflow does

There are two webhooks in one n8n workflow:

  1. Website inquiry (mss-l1-inquiry): screen the submission, look the sender up in Clio, pick a reply, send it, alert the attorney if needed, and file a Clio Grow lead.
  2. Calendly booking (mss-l1-calendly): verify Calendly's signature, then create a Clio calendar entry and send the attorney a heads-up email.

No AI is involved anywhere. Routing is plain rules, and you can read every one in the Code nodes.

Step 1: A Clio API app, in the right region

Create an app in Clio's developer portal with read access to Contacts and write access to Calendars. Two things in Clio's docs catch people out:

  • Regions are separate. US accounts use https://app.clio.com/api/v4. Canada, the EU and Australia have their own hosts (for example https://ca.app.clio.com/api/v4), and Clio says tokens aren't valid across regions. Our workflow points at the US host. Change it if your account is elsewhere.
  • Tokens expire. Clio's docs say Manage access tokens last 30 days, and a request with an expired token gets a 401. Manage refresh tokens don't expire. Our workflow handles this itself. You set CLIO_CLIENT_ID, CLIO_CLIENT_SECRET and CLIO_REFRESH_TOKEN. When Clio answers 401, the workflow asks Clio's token URL for a new access token once, keeps it in the workflow's static data and repeats the request. Our mock test checked the refresh and that later calls reuse the new token.

Step 2: Screen the form before anything goes out

The first Code node drops junk before it reaches Clio or your inbox:

  • Honeypot. A hidden form field that people never see and bots fill in. The workflow checks a hidden field named company_website, and our setup notes now use the same name. Give your form's hidden field that exact name (scenario I5).
  • Valid email and link count. Messages with three or more links are treated as spam.
  • One auto-reply per email address per 24 hours, so a double submit gets one reply (I6).

That 24-hour memory lives in n8n's workflow static data. n8n's docs say static data isn't saved when you test in the editor. The workflow has to be published and called through its production webhook URL. Point your form at the production URL (/webhook/..., not /webhook-test/...), or the double-submit protection won't work. The memory also resets if you re-import the workflow.

Step 3: Look the sender up in Clio, and respect the rate limit

Next, the workflow searches Clio contacts by email (contacts.json?query=<email> with a short fields list) and checks is_client. Existing clients get a short acknowledgement, and their attorney gets an alert instead of the intake reply (I4).

Clio's rate limits are per token. The default is 50 requests a minute during peak hours, which for the US and Canada are 04:00 to 19:00 Pacific, Monday to Friday. A request over the limit gets a 429 with a Retry-After header. Our Clio calls wait for the number of seconds in Retry-After and try again, up to six tries (I7, against a mock that returned 429; a later test checked a 2-second Retry-After was honored). They also space requests about 1.3 seconds apart to stay under 50 a minute. If you run other Clio automations on the same token, they share that limit.

Step 4: Route and reply

The routing node picks one of four replies:

  • Urgent: the message mentions something like a hearing, court date, eviction, arrest, being served, a deadline or "tomorrow." The attorney gets an URGENT alert, and the person is asked to call now (I2).
  • Out of scope: the practice area isn't in FIRM_PRACTICE_AREAS. The person gets a polite decline with your STATE_BAR_REFERRAL link and no booking link (I3).
  • Existing client: an acknowledgement, plus an alert to their attorney (I4).
  • Everyone else: your intake form and booking link, plus a notice not to send confidential details by email yet, and that contacting you doesn't create an attorney-client relationship (I1).

Email goes out through Resend with an idempotency key, so a retried send doesn't produce a second email. In the test, the reply went out in about half a second. The urgency list is keywords, not judgment, so an attorney should still read every inquiry. Our inquiry auto-reply post covers the wording and the prospective-client rules behind it.

Step 5: File the Clio Grow lead, knowing the API is "legacy"

The workflow posts each new inquiry to Clio Grow's Lead Inbox API: https://grow.clio.com/inbox_leads, or the eu., au. or ca. host for other regions. Clio's docs list from_first, from_last, from_message, referring_url and from_source as required, and email and phone as optional. A 422 means a required field is missing. Because web forms often have only one name field, the workflow fills from_last with "(not given)" when needed, and puts the practice area at the start of the message.

One thing to know before you build on this: Clio's developer docs label the Lead Inbox API a "Legacy Approach" and point new builds to the Clio Platform API. It works today, but plan for a rewrite. Clio's FAQ says Platform tokens last 24 hours and rotate their refresh tokens, which is another reason to use n8n's OAuth2 credentials rather than pasted tokens. If you don't use Grow, delete the node.

Step 6: Calendly bookings onto the Clio calendar

When someone books, Calendly calls the second webhook. Before the workflow trusts the call:

  • You need a paid Calendly plan. Calendly's help says webhooks are available on its paid plans (Standard and up). Bookings made before you subscribe won't trigger them.
  • Subscribe to invitee.created. You create webhook subscriptions through Calendly's API (POST /webhook_subscriptions), with user or organization scope.
  • Set a signing key. With a personal access token, Calendly's docs say the signing key is optional when you create the subscription. Set one anyway and put it in CALENDLY_SIGNING_KEY. Calendly sends a Calendly-Webhook-Signature header (t=...,v1=...). The workflow computes an HMAC-SHA256 of the timestamp, a dot and the raw request body, compares it in constant time, and rejects anything older than three minutes, which is the tolerance in Calendly's example. A forged call is ignored (I9).
  • Raw body matters. The signature is computed over the exact bytes Calendly sent. Enable the n8n Webhook node's "Raw Body" option, as our workflow does. If n8n re-serializes the JSON first, valid signatures fail.

Then the workflow creates a Clio calendar entry ("Consultation: name") on the calendar in CLIO_CALENDAR_ID. The description includes "Run a conflict check before the consult," and the attorney gets an email heads-up (I8). It remembers each booking's Calendly URI, so a re-delivered webhook doesn't create a second entry (I10).

The workflow doesn't run a conflict check. It only reminds you to. Someone at the firm still has to do it before the consult.

What we tested, and what we didn't

The recipe is verified with mocks. On October 27, 2026 it passed 10 of 10 scenarios on n8n 2.45.4. Clio Manage, Clio Grow, Resend and Calendly were local mocks built from their public docs, including Clio's 429 behavior. It has not run against a live Clio account, a real Grow inbox or a live Calendly subscription. Before you turn it on, send yourself one test inquiry per practice area, one with "hearing tomorrow" in it, and one real Calendly booking, then check Clio.

On October 28, 2026 we fixed three gaps from the first version: the setup notes now use the code's honeypot field name, the workflow refreshes its Clio token on a 401, and it honors Retry-After. Known gaps: the urgency check is a keyword list, the Grow lead uses Clio's legacy Lead Inbox API, and it isn't set up for Clio's non-US regions without edits. It's a tool, not legal advice.

For phone inquiries, see missed-call text-back for law firms and whether lawyers can text clients. Everything we've built for firms is on the law firms page.

Sources

All checked October 27, 2026.

The recipe for this problem

Found an error or a better source? Corrections policy. More articles on the blog.