Attio + Clay Integration (2026): How to Build the Enrichment Stack
•
Clay connects natively to Attio as of March 30, 2026. You can pull Attio records into a Clay table, enrich them across Clay's 150+ data providers, and write the results back to any Attio object, all over OAuth with no Zapier, Make, or webhook glue anywhere in the loop. For seed to Series B teams, this pairing is the strongest CRM enrichment stack you can run right now.
One opinion up front, because it changes what you should build: if you have engineering help or an AI coding agent, build this on Clay's API rather than its tables. Clay shipped a developer platform in July 2026 that turns enrichment into a function your Attio workflow calls, and for most seed to Series B teams that is now the better architecture. The table build is still right without engineering support, and both are here in full.
Most of my work happens inside other teams' Attio workspaces, and enrichment is where I see the most expensive mistakes. The waterfall that burns a month of credits by Wednesday. The prospecting push that quietly overwrites a live customer record. The field nobody can trace back to a source, so nobody trusts the report built on it. None of those are tool problems, which is why this guide spends as much time on schema and guard rails as on wiring. If you are still choosing a CRM, start with our complete Attio guide instead; everything below assumes Attio is already your system of record.
What the native integration actually does
The integration lives on Clay's side. You connect your Attio workspace to Clay via OAuth (only an Attio workspace admin can authorize it), and Attio then shows up in Clay in two places: as a source that feeds tables, and as a set of actions that write data back.
Clay capability | What it does |
|---|---|
Import records | Pulls records from any Attio object or saved view into a Clay table, up to 50,000 per import |
Import from list | Pulls entries from a specific Attio list, with optional filters |
Create record | Creates a new record in any Attio object |
Update record | Updates an existing record by its Attio record ID |
Upsert record | Updates if a match exists on a unique attribute (email, domain), creates if not |
Lookup records | Searches an object and returns up to 10 matches |
Two details matter more than the feature list. First, this works with every object type, including custom objects, so a Signups or Workspaces object you built on Attio's flexible data model is just as enrichable as People and Companies. Second, Clay price each write action at one credit per run, while Lookup is free. Their own stated best practice follows from that: look up before you create, and use Upsert instead of Create whenever you are not certain a record already exists. Duplicate records are the classic failure mode of CRM enrichment, and the free Lookup action is your guard rail.
Before this shipped, connecting the two tools meant hand-rolled HTTP requests in both directions with a Parse JSON block unpacking the payload field by field. The native integration retires that: Clay pulls records from Attio on a schedule and writes results straight back, with no webhook and no JSON anywhere in the table build.
Attio vs Clay: two layers, not two rivals
Plenty of people search "attio vs clay" as if it were a choice. It is not. Attio is your system of record, where relationships, pipeline, and activity live. Clay finds, enriches, and qualifies records, then hands them somewhere. It is not a CRM and does not want to be. The real question is whether your data problem is big enough to justify a second tool at all.
Because Attio already does a fair amount unaided. It automatically enriches people and companies with descriptions, logos, social handles, and categories, and links people to companies by email domain, on every plan. Its AI Research Agent answers specific questions from the live web inside a workflow. For a team enriching a couple hundred records a month, that is often enough, and I have talked clients out of buying Clay on exactly those grounds.
Clay earns its keep when coverage starts to matter: verified work emails and mobile numbers, headcount and funding cross-checked across providers, intent signals, AI research at volume. Its core mechanic is waterfall enrichment, querying providers in sequence until one returns a match, which is how it beats any single vendor's hit rate. Nor is this a fringe setup. Granola, one of Attio's published customer stories, runs Clay inside its Attio-based GTM system and cut lead triage time by 83%. My rule of thumb: under roughly 200 enriched records a month, stay native. Past that, or the moment you need phone numbers or signal-based outbound, Clay pays for itself.
Two architectures, and which one you should build
Your stack has two jobs to do. Maintenance is bulk work: enriching records at scale, catching job changes and funding rounds before your data rots, backfilling a workspace you have been running half-empty. Inbound is per-record work: a signup lands and needs to be enriched, scored, and routed before a rep opens it. Most teams run both. The only real decision is how they get wired, and there are two honest answers.
The table path runs inside Clay's UI. A Clay table sources an Attio object or list on a recurring sync, waterfalls run across the rows, and Attio actions write the results back. Nothing to host, nothing to deploy, and any ops hire can open the table and see which row failed and why.
The API path runs on Clay's developer platform. You build your enrichment logic once as a Clay function, then call it directly from an Attio workflow. No table sits in the middle, nothing accumulates, and enrichment fires per record in seconds rather than waiting for the next sync. It is newer, and it asks more of whoever sets it up.
Your situation | Build this |
|---|---|
Engineering help or an AI coding agent available | API path |
Speed-to-lead measured in seconds | API path |
Enrichment triggered by product events, not CRM events | API path |
No engineering support on the team | Table path |
Prospecting, list building, large backfills | Table path |
For most seed to Series B teams we build the API path for inbound and keep tables for everything else. That split is not fence-sitting, it follows from what each surface is good at. Inbound is where latency costs you deals. Maintenance is where a visible grid of rows you can scan and sort earns its keep. Both builds are below, API first.
The API path: the build we recommend
The idea is simple even if the plumbing is new: enrichment becomes something Attio calls, not something you run. Clay groups this under Routines, which come in three forms worth knowing apart.
Clay-managed functions are Clay's own, covering the standard jobs, work email, phone number, job title, employee count, revenue, tech stack, job openings, funding, and news. Nothing to build, just call them. Custom functions are your logic, the waterfall and the ICP scoring your team already trusts, built once in Clay's UI and then callable from anywhere. Workflows are the Alpha option, built from a terminal or an AI coding agent rather than the UI, and the only one that escapes the 50,000-row ceiling. For anything running your revenue today, custom functions are the right pick: stable, and your ops hire can still open and read the logic.
Wiring one to Attio takes four steps.
Build the function in Clay, the same waterfall and scoring you would put in a table, saved as a function instead.
Open Functions in Clay, go to Details, enable the API integration, and copy the function id. It looks like
t_abc123, and you call it asfunction:t_abc123.In Attio, create a workflow that triggers on record created and sends an HTTP request to Clay's routines endpoint. Pass the Attio record ID as the item id and whatever you already know, usually email and domain, as the inputs.
Handle the callback, which is where the one real design decision lives.
That callback exists because routine runs are asynchronous. Clay answers immediately with a run ID rather than the enriched data, then notifies you when the work finishes, so nothing blocks and nothing polls. Because you passed the Attio record ID through, the result comes back knowing exactly which record it belongs to. The no-infrastructure version points that notification at a second Attio workflow with a Webhook received trigger, which updates the record. If a backend service already sits between your product and your CRM, point it there instead and let the service call Attio directly. That version buys you retries, logging, and the ability to trigger enrichment from a product event, a workspace crossing an activation threshold, rather than only from a CRM event.
For backfills, the same functions accept a file of records in one batch run, so a one-off cleanup of 20,000 companies is a single job rather than a weekend of table babysitting.
One caveat, so expectations land in the right place. Custom functions are still authored in Clay's UI, so this cuts your runtime dependence on Clay's interface rather than removing the interface. Building outside the UI entirely is real and shipping, that is what Workflows are, but Alpha is Alpha, so treat it as where this is heading rather than what you bet the quarter on.
The table path: step by step
This is the build for teams without engineering support, and the one we still use for maintenance and backfills regardless. Here it is in order, with the gotchas that do not appear in any official doc.
1. Create the inbound list in Attio
Make a list called Inbound Leads and route every lead source into it: website signups, demo forms, webinar registrations, newsletter subscribers. One list, many sources, one enrichment flow behind it. This matters because you configure the loop once and every future lead source just gets added to the list.
2. Point a Clay table at the list
In a Clay workbook, add a source, pick Attio, and choose Import records from list, selecting your Inbound Leads list. Set the sync to recur on the tightest cadence your volume justifies. Each imported row arrives carrying its Attio record ID, and that ID is the quiet hero of the whole build: when Clay writes back later, it targets the ID directly, so you always update the exact record that entered the loop. Matching on email instead invites silent misfires the first time someone signs up twice with different addresses.
3. Add the guards before the waterfalls
Skip this step and you will meet your credit ceiling early. Gate every enrichment column with Clay's conditional runs: skip personal Gmail and Outlook addresses if you only sell B2B, and skip any record whose Last enriched at, a date attribute you create in Attio and import with the rest, falls inside your refresh window (we default to 90 days). With both in place, an already-fresh record flows through the table without spending a credit, and re-syncing the list costs you nothing.
4. Enrich the person in Clay
In the Clay table, chain your person waterfall: find the LinkedIn profile from name and email, enrich the profile for title, seniority, and location, then verify the work email. Add a Claygent step as a fallback for records the providers miss. Then run your qualification logic as extra columns, a persona classification, an ICP score, whatever your routing depends on. This is where you should diverge from any template, ours included, because your scoring rubric is your own.
5. Write the person back, then chain the company
Add an Attio Update record action targeting the record ID on the row, mapping your enriched columns to Attio attributes, including a fresh timestamp into Last enriched at. Then handle the company: take the domain, run your company waterfall (headcount, funding, industry, tech stack), and push it with Upsert record matched on domain. Upsert handles both branches in one action, enriching the company if Attio already auto-created it from the email domain, creating it if not. Attio links the person to the company automatically once the domains match.
One setting to get right on updates: Clay lets you choose whether multiselect values are appended or overwritten. Append for anything that accumulates, like tags or categories you maintain by hand. Overwrite for anything Clay owns outright.
6. Write to your own attributes, not Attio's enriched ones
The gotcha that catches almost everyone: Attio's own enriched attributes, the purple-tinted values like description and categories, cannot be overwritten through the API, which means Clay cannot write into them either. Create your own attributes for Clay-owned data instead: Employee count (Clay), Funding stage, ICP score, Persona. This is cleaner anyway, because you always know which system owns which field, and Attio's auto-enrichment keeps refreshing its own layer alongside yours. If you are designing this schema from scratch, our guide to Attio custom objects and the data model is the deeper treatment.
7. Close the loop with a Slack notification
This is the one place an Attio workflow enters the build. Trigger it when Last enriched at changes on a record in your Inbound Leads list, and post to Slack with the person's name, title, company, ICP score, and a link to the record. The step looks cosmetic and is not. It gives you a running audit log of enrichment quality, and it means a rep can go from signup notification to relevant first touch in minutes. In our own workspace, signups come back enriched and announced in Slack without anyone touching them, and that silence is the entire point of the loop. If workflows are new territory, our Attio Workflows guide covers the builder end to end.
Four plays to run once the loop is live
Inbound enrichment is where every team starts and where most teams stop. It is also the least interesting thing this stack does. Clay starts earning its invoice when it stops filling in fields and starts creating pipeline. These are the four plays we build next, roughly in order of payoff.
Champion tracking
Your closed-won contacts change jobs, and each move is two events at once: a relationship to protect at the account they left, and a warm lead at the company they joined. Build a saved view in Attio of champions at current customers, source it into a Clay table, and add Clay's Monitor for job changes signal, which watches their LinkedIn profiles on a schedule you set. When someone moves, Clay captures the new company and start date, finds the fresh work email, upserts the new company into Attio, and updates the person. An Attio workflow then does what Attio is for: tasks the account owner, posts to Slack, and drops the mover into a Champions on the Move list your team reviews every week. One cadence note from running this: senior titles move rarely, so monthly monitoring is plenty for VP and C-level champions; save weekly scans for high-turnover roles, or the alerts become noise nobody reads.
Signal-triggered outreach on target accounts
Clay's signals also watch companies: fundraising news, hiring spikes, new executive hires. Point them at your Tier 1 account list imported from Attio, and write two attributes back on a hit, something like Signal ("Raised Series A") and Signal date. That tiny schema choice is what turns a notification into a system, because now Attio workflows can act on the data: enroll the mapped buyer in a sequence, create a task with the signal as context, or bump the account into this quarter's outbound view. A funding round plus a hiring spike in your buyer's department is the warmest cold outreach gets.
Net-new TAM, pushed in clean
Clay is also where you build lists that never existed: companies matching your ICP filters, the right personas at each, enriched and scored before Attio sees them. For a fund the same play is sourcing, companies matching your thesis enriched and scored before they reach your deal flow pipeline. The non-obvious part is the push. Run the free Lookup action first and tag rows that already exist in your workspace, so a prospecting import never stomps a live customer record, then Upsert companies matched on domain and let Attio's person-to-company linking do the joining. And stamp every pushed record with a Source attribute set to Clay. Six months from now, when someone asks whether Clay-sourced pipeline actually closes, that one field is the difference between an answer and a shrug.
Pre-call research on new deals
When a deal is created in Attio, a Clay table sourced from your Deals object picks it up, runs a Claygent research pass on the company (recent news, hiring focus, tech stack, anything your reps ask for in discovery), and writes a three-line brief into a Research notes attribute on the record. Reps open the deal and the context is already sitting there, next to the pipeline they live in, instead of in a tab they forgot. This is the play clients are most skeptical about and the one they defend loudest a month later, because it quietly deletes twenty minutes of pre-call scrambling per meeting.
Where Audiences fits for an Attio team
Attio is not a native Audiences source, and that is the one thing worth knowing here. Audiences is Clay's unified data layer, holding millions of records with live segments and enrichments that persist per record. Its sources are Salesforce, HubSpot, Snowflake, BigQuery, CSV, and Clay's own database; its write-back covers Salesforce and HubSpot. Attio is on neither list, so the table build runs at the table layer and the API build sidesteps the question.
You can still get Attio records in, via the bridge Clay documents: import with the native Attio source, then use the Upsert Audiences Record enrichment to commit those rows permanently. Where that pays off is list building, assembling a segment of any size deduplicated against everything you already hold, then pushing the qualified slice into Attio. One warning if you do. Matching is single-key: you pick one identifier per source, domain for companies, email or LinkedIn URL for people, and anything sharing that value gets merged, duplicates within a single source included. Choose it carelessly and you will fuse two real companies into one, then find out weeks later when a rep asks why their account has someone else's deals on it.
What the stack costs to run
Clay repriced in March 2026, replacing its old Starter, Explorer, and Pro tiers, so most pricing posts you will find are stale. Current Clay pricing looks like this:
Clay plan | Monthly / annual | Included per month |
|---|---|---|
Free | $0 | 100 data credits, 500 actions |
Launch | $185 / ~$167 per mo | 2,500 data credits, 15,000 actions |
Growth | $495 / ~$446 per mo | 6,000 data credits, 40,000 actions |
Enterprise | Custom | 100,000+ data credits |
Every Clay plan includes unlimited seats; you pay for usage, not people. The catch for this build: CRM auto-sync sits on Growth, so the native Attio loop realistically starts at $495 a month, or about $446 on annual billing. Clay's docs put a fully enriched record at 6 to 20 data credits depending on your waterfall depth, so Growth's 6,000 monthly credits cover roughly 300 to 1,000 complete enrichments, comfortably enough for 500 inbound leads a month with a disciplined waterfall.
Three habits stretch those credits further, and none of them are obvious from the pricing page. Bring your own provider API keys where you already pay for one, since Clay's billing docs note that private keys cut the data credits spent per record. Order every waterfall cheapest-first, so the expensive providers only fire on the records the cheap ones missed. And split monitoring tables by persona once signals enter the picture, so each segment runs on its own cadence instead of the whole database being checked at the tightest one.
The Attio side of this build is close to free. Since Clay both pulls and pushes through the native integration, Attio runs no workflow at all for the enrichment itself, and its workflow pricing only spends workspace credits on blocks that write data or reach external systems. The Slack notification is the loop's one recurring Attio cost, a single credit per enriched lead, so 500 leads a month runs about 500 credits, inside the Plus plan's 1,500 monthly workspace credits and a rounding error against Pro's 10,000. On Attio's pricing, Plus runs $35 per user per month on annual billing ($44 monthly) and Pro $79 ($99 monthly). Pro is where most teams running this stack land anyway, for custom objects and the bigger credit pool rather than for the loop itself, and Plus caps at 10 seats, so growing past a ten-person GTM team makes the decision for you.
Put together, a five-seat team on Attio Pro with Clay Growth pays about $841 a month on annual billing for the full stack, and only the Attio half of that grows with headcount; Clay stays flat no matter how many teammates use it. Verify current pricing on each vendor's site before buying; both companies ship pricing changes faster than blogs update.
Honest limitations
The Growth-plan floor deserves the most thought, though not for the reason you would expect. $495 a month is not a hard number for a funded team. The question is whether your volume earns it. A team enriching 80 records a month on Growth is paying about $6 per record for work Attio's native enrichment and the Research Agent would have handled, and I have seen that bill run for a year before anyone opened the usage dashboard. Run the native layer until inbound volume, phone numbers, or signal-based outbound make the case, then switch. Attio's own enrichment is a real answer, not a consolation prize.
Clay also has a learning curve, and it charges tuition. A carelessly scoped waterfall can chew through a month of credits in an afternoon. The fix is design discipline rather than heroics: conditional runs, views scoped to records actually due for a refresh, and the Last enriched at guard so nothing gets enriched twice for free.
The constraint worth designing around, though, is the schema. Attio's enriched system attributes are read-only to the API, so your workspace needs its own attributes for Clay-owned data from day one. Retrofitting that after six months of writes is a miserable weekend. Which is the fair summary of this entire stack: none of it is hard to wire, and almost all of it is easy to wire badly. The teams that get value from Attio and Clay are the ones who decided what each system owns before a single field was written.
Frequently asked questions
Does Attio have a native integration with Clay?
Yes. Since March 30, 2026, Clay integrates natively with Attio. You can import records from any Attio object or list into Clay, enrich them, and write results back with Create, Update, Upsert, and Lookup actions over OAuth. No Zapier, Make, or webhook glue is required.
Is Clay a CRM?
No. Clay is a data enrichment and GTM orchestration platform, not a system of record. It finds, enriches, and qualifies records, then syncs them into a CRM like Attio, which holds your relationships, pipeline, and activity history. Some teams prototype list management in Clay, but it is built to feed a CRM, not replace one.
What is waterfall enrichment?
Waterfall enrichment queries multiple data providers in sequence until one returns a match. If the first provider has no verified email for a contact, the request cascades to the next, and so on. Because no single vendor covers everyone, waterfalls deliver meaningfully higher hit rates than any one provider alone. It is Clay's core mechanic.
How much does Clay cost?
Clay's current plans are Free ($0, 100 data credits a month), Launch ($185 a month, or about $167 annual), Growth ($495 a month, or about $446 annual), and custom Enterprise. All plans include unlimited seats. The Attio integration needs Growth or above, since CRM sync and webhooks sit on that tier.
Can I use the Clay API instead of Clay tables with Attio?
Yes, and for many teams it is the better build. Clay's developer platform lets you call a Clay function directly from an Attio workflow, so enrichment fires per record in seconds with no table in the middle. Runs are asynchronous, so Clay calls back via webhook when results are ready.
Do I need Clay if Attio already enriches records?
Not always. Attio automatically enriches people and companies with descriptions, social handles, and categories on every plan, and its AI Research Agent handles targeted lookups, which makes it a fair Clay alternative at low volume. Clay becomes worth it at scale, when you need waterfall coverage, verified emails, phone numbers, or intent signals.
Sparsh Gupta, Founder of Automation Jinn and an Official Attio Expert Partner, designs the GTM systems behind seed to Series B revenue teams and the funds that back them: the data model, the enrichment layer, the workflows, and the reporting that makes all of it legible. If you want every lead enriched, scored, and routed before your reps ever see it, book a discovery call.
