Sync Brew and Attio Over MCP

Attio holds the context. Brew sends the email. Then Brew writes back what happened, onto the record your team already opens. Two things make Attio different from a flat CRM, and both change how you set this up. List entries carry their own attributes, and interaction data is read-only. This page covers what’s specific to Attio. For creating custom fields, running the sync, and building the audience, see Sync a CRM Into Brew Over MCP. You need both MCPs connected to the same assistant.

​

Records and List Entries

Attio stores attributes in two places. Picking the wrong one is the mistake that costs you later. Record attributes live on the person. Job title, company, email addresses. They’re shared everywhere that person appears. List entry attributes live on the entry and are scoped to one list. The same person can sit in two lists with different entry values at once. That distinction matters for email state. Put “received the onboarding sequence” on the record and your next send overwrites it. Put it on the entry and each list keeps its own history. The mapping to aim for: One Attio list, one Brew audience, one Email. Facts about the human go on the record. State about a particular send goes on the entry.

​

What to Sync From Attio

These attributes exist in every Attio workspace. Attio maintains them, you read them. All of these are read-only. Actor references resolve to a workspace member, so store the name or email as a string on the Brew side. Add one Brew field per workspace-specific attribute you want to filter on. Then sync and build the audience as described in Sync a CRM Into Brew Over MCP. email_addresses holds more than one address. Decide which is authoritative before you sync, or one person becomes two Brew contacts.

​

Write Engagement Back to Attio

This is the half most people skip, and it’s what makes the record worth opening. Your team sees which emails a contact actually received, next to everything else you know about them. Brew’s per-contact events are the source. Read them with get_event_analytics over MCP, or GET /v1/analytics/events filtered by recipientEmail. See Explore Per-Contact Engagement. The event types you can write back are sent, delivered, opened, clicked, bounced, complained, and unsubscribed. Write them to a status or select attribute on the entry.

After the send, update the Attio list entries for these contacts with their latest Brew email status.

Brew doesn’t observe replies or meetings. Those aren’t Brew events at all. Attio tracks them through mailbox and calendar sync. They flow Attio into Brew as suppression inputs, not the other way.

​

One Owner Per Attribute

This is the rule that keeps the loop from quietly wrecking your data. Picture it. A teammate moves someone forward after a real conversation. The next sync sees that an email went out and overwrites their judgment, with no error and no warning. Give machine-observed facts their own column. Brew writes to something like brew_email_status, and human-judgment columns stay human. Brew never touches them. The tempting alternative is one shared column with a rule like “Brew only advances from this value.” That rule lives in prompt text, and prompt text gets edited and forgotten. One extra attribute per list is cheaper than a funnel nobody trusts.

​

Attio-Specific Traps

Interaction attributes are read-only. Attio’s API rejects writes to them outright. Use your own attributes for anything Brew observes. They’re also often empty. They’re enriched attributes, not available on every Attio billing plan. That means they can be blank for reasons unrelated to your data. A filter on an empty attribute matches nothing and never errors, so check a real sample first. One entry per record, or the write fails. Updating an entry by parent record ID errors on zero entries in that list, and on more than one. Handle both cases before you run it at volume. Multi-value attributes prepend by default. Values stack instead of replacing, so email state written that way accumulates. Use a status or select attribute, which holds one value at a time.

​

Verify

Use two or three test records in one list. Change one thing, re-sync, and check the audience count moves by the number you expect, not just that it moved. Then test the reverse. Send to one test contact and sync back. Confirm your Brew-owned attribute updated on the entry, and that the human-owned ones didn’t move.

​

Start Small

Pick one list that nothing else is writing to. Run the whole loop on a handful of records: Attio list, Brew audience, send, status back on the entry. Don’t build this on a list another tool already manages. Two systems writing the same column is the exact failure this page exists to prevent.

​

Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you: