> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brew.new/llms.txt
> Use this file to discover all available pages before exploring further.
# Sync Brew and Attio Over MCP
> Map Attio's record and list-entry attributes to Brew, sync the fields you filter on, and write email engagement back onto the Attio entry.
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.
Every marketing recipient must have opted in to hear from you. Importing or syncing contact data into Brew is not permission to email it. See [What You Can Send](/get-started/what-you-can-send).
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](/api-reference/mcp/sync-a-crm). 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.
| Attribute | Lives on | Type | What you get |
| ------------------------------- | ---------- | ------------------ | ----------------------------------------- |
| `record_id` | people | text | Stable join key. Emails change, IDs don't |
| `email_addresses` | people | email, multi-value | Match key |
| `last_interaction` | people | interaction | Recency, maintained by Attio |
| `last_email_interaction` | people | interaction | Email-only version |
| `strongest_connection_strength` | people | select | Very weak through Very strong |
| `strongest_connection_user` | people | actor reference | Who on your team knows them |
| `created_at` | list entry | timestamp | How long they've been in the list |
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](/api-reference/mcp/sync-a-crm).
Attio display names and API slugs differ. A list shown as "Trial Signups" can have the slug `trial_list`. Ask your assistant to read the definitions before you write any filter.
`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](/api-reference/guides/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.
| Change in Attio | Expected in Brew |
| ------------------------------------------ | --------------------------------- |
| Entry attribute set to your excluded value | Contact drops out of the audience |
| Entry attribute set back | Contact returns |
| Add a person to the list | Appears after the next sync |
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:
Type in the "Ask any question" search bar at the top left to instantly find relevant documentation pages.
Click "Open in ChatGPT" at the top right of any page to explore it further with ChatGPT or Claude.
Book time with our founders for personalized guidance on strategy, best practices, or complex implementation questions.
Need immediate assistance? Reach us at **+1-(332)-203-2145** for urgent issues or time-sensitive questions.
Our preferred support channel. You'll receive an invite after signup for direct founder support and fast responses.
Contact us at **[support@brew.new](mailto:support@brew.new)** for detailed inquiries or if you prefer not to use Slack.