# Accepting an Invite Source: https://heybtw.com/docs/collaborators/accepting-an-invite How to join a heyBTW collab when a partner invites you. ## Overview You've received an invitation from a partner to collaborate on a co-marketing event using heyBTW. This guide walks you through what to expect and how to get started. ## What You'll Need * The invitation email from your partner. * About 2 minutes. That's it. No credit card, no lengthy onboarding, no IT involvement. ## How to Join 1. Open the invitation email from your partner. 2. Click the **Join Collab** link. 3. Create your account (or sign in if you already have one). 4. You'll land directly in the shared collab workspace for the event. ## What You'll See Once inside, you'll have access to: * **Event details** for the co-marketing event you're collaborating on. * **Shared invite list** showing target accounts and contacts for the event. * **Post-event metrics** including attendee data and attribution results (after the event happens). ## What You Won't See Your partner's raw CRM data, internal pipeline, or other collabs you haven't been invited to. heyBTW is privacy-first. Each organization controls what data is visible in shared workspaces. ## Optional: Connect Your CRM You can optionally connect your own CRM (HubSpot or Salesforce) to see attribution data from your organization's perspective. This shows you which of your target accounts attended the event and whether they progressed in your pipeline. Connecting your CRM is not required to participate. You can get value from the shared workspace without it. See [Connecting Your CRM](/docs/collaborators/connecting-your-crm) for details. ## Multiple Invitations If you collaborate with this partner on multiple events, you'll be invited to additional collabs over time. Each collab is a separate workspace for a specific event, and your partner network data accumulates across all of them. # Connecting Your CRM Source: https://heybtw.com/docs/collaborators/connecting-your-crm Optionally connect your CRM to see attribution from your organization's perspective. ## Overview As a collaborator, connecting your CRM is optional but unlocks the full value of heyBTW. Without it, you see shared event metrics. With it, you see how the co-marketing event impacted your own pipeline. ## Why Connect? When you connect your CRM, heyBTW can: * Match event attendees to contacts and accounts in your CRM. * Show you which of your target accounts attended the event. * Track whether those attendees progressed to meetings, opportunities, or deals in your pipeline. * Give you attribution data you can use to evaluate the partnership. Without a CRM connection, you still see attendee data and shared metrics, but you miss the pipeline attribution that makes co-marketing measurable. ## How to Connect 1. From any collab workspace, navigate to your workspace settings. 2. Click **Connect CRM** and choose HubSpot or Salesforce. 3. Authorize the connection. The setup process is the same as for any heyBTW user. See [Connecting your CRM](/docs/integrations/crm) for the HubSpot and Salesforce setup paths. ## Privacy Connecting your CRM does not share your data with the partner who invited you. Your CRM data is used to generate attribution insights for your organization only. The partner sees shared event metrics, not your internal pipeline. ## From Collaborator to Customer Many organizations discover heyBTW as collaborators. After seeing attribution data from a few events, they realize they want heyBTW for their own partner program. If you're interested in using heyBTW for your own co-marketing events, reach out to [ben@heybtw.com](mailto:ben@heybtw.com). # Navigating the Shared Workspace Source: https://heybtw.com/docs/collaborators/shared-workspace How to use the collab workspace as a partner-side collaborator. ## Overview The shared workspace (collab) is where you and your partner coordinate on a co-marketing event. As a collaborator, you have access to everything you need to participate in the event without managing a full heyBTW account. ## Workspace Layout When you open a collab, you'll see: * **Event Overview** - The event name, date, location, and description. * **Invite List** - The shared list of target accounts and contacts for the event. You can view the list and contribute contacts from your side. * **Attendee Data** - After the event, this shows who registered, RSVP'd, and attended. * **Attribution Metrics** - Post-event data showing how attendees progressed through the pipeline. ## Contributing to Invite Lists Your partner may ask you to contribute target accounts to the shared invite list. You can add contacts and companies that your organization wants to reach at the event. If you've connected your CRM, you can pull directly from your account data. ## Viewing Attribution After the event, attribution data shows up in the collab workspace. You'll see which attendees converted to meetings and opportunities. If you've connected your own CRM, you see this data from your organization's perspective, showing how the event impacted your pipeline specifically. ## Your Data Stays Private Even though you're in a shared workspace, your CRM data stays private to you. Your partner sees shared event metrics and attribution results, but never your raw CRM records, internal pipeline, or data from other partnerships. # Understanding Shared Attribution Source: https://heybtw.com/docs/collaborators/understanding-shared-attribution How attribution data works in shared collab workspaces. ## Overview When you collaborate on a co-marketing event through heyBTW, both sides get attribution data. But what each side sees depends on their CRM connection and the data they've opted to share. ## What Both Sides See In a shared collab workspace, both you and your partner can see: * Total attendees and registrations for the event. * Aggregate performance metrics (meetings generated, opportunities influenced). * Which companies attended the event (company-level data from event registrations). ## What Only You See If you've connected your CRM, you also see attribution data specific to your organization: * Which attendees match contacts in your CRM. * Which of your target accounts attended. * Whether those contacts progressed to meetings, opportunities, or deals in your pipeline. * Revenue attributed to the event from your deals. Your partner sees their own version of this data based on their CRM. Neither side sees the other's raw pipeline data. ## How Attribution Is Calculated heyBTW matches event attendees to CRM records using email as the primary key. Once matched, it tracks the contact's pipeline journey: 1. **Attendee captured** - The contact registered for or attended the event. 2. **Meeting booked** - A meeting was scheduled with the contact (tracked via CRM). 3. **Opportunity created** - An opportunity was created involving the contact. 4. **Deal closed** - The opportunity closed, and revenue is attributed to the event. Attribution can be **sourced** (the event was the first touchpoint) or **influenced** (the contact existed but the event accelerated the deal). ## Multi-Event Attribution If a contact attends multiple co-marketing events before their deal closes, all contributing events receive attribution credit. This reflects the reality that deals are often influenced by multiple touchpoints across multiple partners. For more detail, see [Multi-Event Attribution FAQ](/docs/faq/multi-event-attribution). # Attribution Model Source: https://heybtw.com/docs/concepts/attribution-model How heyBTW classifies every event-touched deal, what stays stable, and what is coming. heyBTW answers one question: which events and which partners contributed to which deal outcomes. There is one model, one set of rules, and one shape of result. The same answer powers the dashboard, the MCP server, CRM custom fields, and any downstream agent. No surface re-derives attribution on its own. This page describes the model. For how the dashboard surfaces it, see [Event Attribution Funnel](/docs/features/event-attribution-funnel). For the query layer, see [MCP Tools](/docs/integrations/mcp-tools). ## Two categories, and only two Every event-touched deal is classified as exactly one of two things: * **[Sourced](#sourced)**: the event created the relationship. * **[Influenced](#influenced)**: the event touched a relationship that already existed. There is no third category. [Acceleration](#acceleration-coming), covered below, is a weight carried by an Influenced touch, not a category of its own. Per deal, Sourced and Influenced are mutually exclusive: the existence of a prior opportunity decides which one applies. Influenced is heyBTW's core wedge. Most attribution tools are sourced-only and miss it entirely, which is why Influenced is the claim to lead with. ## Two separate questions: class and threshold Classification and qualification are independent axes. Do not conflate them. 1. **Class.** Sourced versus Influenced. Which side of the event the relationship was born on. 2. **Threshold.** Your north-star stage. The bar a deal clears to count as a win, for example closed-won, demo-completed, or qualified-opportunity. You set it in the dashboard. A deal is classified on the first axis and qualified on the second, separately. Changing your north-star stage changes what counts as a win, not whether a deal is Sourced or Influenced. ## Sourced No opportunity existed at the account before the event, and one came after. The event gets origination credit. This is the hardest and rarest claim, so heyBTW applies it conservatively. The guard that keeps Sourced honest: heyBTW does not claim an event sourced a deal that sales was already actively working. If a rep or SDR had an open opportunity or recent outbound on the contact before the event, or your CRM lead source resolves to sales, the event did not source it. Mere presence in your CRM, or a dormant or old marketing touch, does not disqualify a sourced claim. An active prior relationship does. Doing the targeting is not the same as being the source. heyBTW helping you decide who to invite is decision support, not a source touch. The highest-confidence sourced signal is partner-sourced: a brand-new opportunity where a partner's tracked invite drove the first touch and sales was not already working the account. Broader source coverage continues to expand. ## Influenced The opportunity already existed and an event attendee touched it after the event. The event gets influence credit on an in-flight deal. Many events can influence one deal. Sales- and SDR-originated contacts who attend events land here, not in Sourced. This is the claim that holds up under scrutiny, and the one to lead with for in-flight pipeline. ## Acceleration (coming): the weight on Influenced Acceleration is not a third category. It is a velocity weight carried by an Influenced touch. An influenced touch that preceded a faster-than-baseline jump through your pipeline stages is weighted more heavily than one that merely coincided with normal progression. This is what makes "dinners are for acceleration, not acquisition" provable. Acceleration is correlation, not causation. It describes that an event correlates with faster stage progression. It never claims the event caused it. This weight is in development. It requires per-workspace stage history and a baseline velocity to measure against, so it is not yet displayed. When it ships, it always pairs with the Influenced claim and is never shown as a standalone category. ## The dimensions heyBTW reports attribution across independent dimensions. A deal can be marketing-sourced and partner-influenced at the same time, with no contradiction. This avoids the zero-sum fight where marketing and partner teams argue over a single source field. * **Marketing source.** Was an event the first meaningful touch on this deal, and if so, which event? * **Partner source.** Did a partner drive the deal to its first touch? Partner source is ranked by signal: a tracked partner link on the RSVP (highest), the attendee's company being an existing customer of the partner per overlap data (medium), and the partner co-hosting the event (lower alone, stronger combined with the others). * **Partner influence.** Which partners touched the deal during its active cycle. The dashboard surfaces partner roles as Direct, Partner Sourced, Partner Influenced (New Business), and Partner Influenced (Expansion). ## How an event is matched to a deal When heyBTW evaluates whether an event touched a deal, it walks a ranked list of signals, strongest to weakest: 1. **Direct attendee match.** An event attendee is a contact on the opportunity. Strongest. 2. **New opportunity, same person, within the window.** An opportunity is created after the event with the attendee as a contact. 3. **New opportunity, same company, within the window.** A new opportunity appears at the attendee's company, where the attendee handed off internally. 4. **Existing opportunity touched after the event.** This is the influence signal. Signals combine with OR, not AND. Three medium signals do not multiply into a strong one. The strongest single matching signal sets the strength of the claim. ## Match keys and identity resolution How attendees are matched to opportunity contacts: * **Same person.** Work email is the primary match. When only a personal email is provided, heyBTW resolves a current company through [enrichment](/docs/integrations/lead-enrichment) and matches against opportunities at that company. Personal emails with no resolvable company are excluded. * **Same company.** Domain match between attendee email and opportunity contact email. Free email domains are excluded from company matching. The personal-email path matters in practice. Luma events run 60 to 65% personal, non-business emails. Naive domain filtering would discard most of the signal. ## What heyBTW excludes The model has explicit rules to prevent self-attribution: * **Host-workspace employees** attending your own events are not counted toward attribution. * **Partner employees on their own customers' deals** do not give that partner credit. * **Free email domains** are excluded from company matching. ## Time anchors * **Event date anchor.** Event start is the consistent anchor: day one for a multi-day conference, broadcast time for a webinar, reservation time for a dinner. * **Opportunity creation.** Read from the CRM. * **Time window.** Caller-controlled. The dashboard asks for "this quarter," an MCP tool for "last 90 days," an agent for "since last QBR." The model respects each window and imposes no default. * **Closed deals are locked.** When a deal closes, its attribution is fixed at the close date and references the stage taxonomy as it existed then. Closed deals do not change retroactively, even if your CRM stage names change later. ## North-star stage Each workspace defines what "the event worked" means: closed-won, demo-completed, qualified-opportunity, or any other CRM stage. Attribution is computed against that target. A workspace where demo-completed is the north-star stage reports differently from one where closed-won is. The customer's pipeline definition wins. ## Collections Related events can be grouped into [Collections](/docs/getting-started/glossary#collections), for example every event around a conference, a region, a rep, or a recurring meetup series. When more than one event in a Collection legitimately touched a deal, each can attribute at the same time. The more specific event carries the stronger signal, and the broader grouping a weaker one. The model does not force a single attribution choice when multiple events touched the deal. ## Revenue Lift is a separate measure Sourced and Influenced are deal-level: they attribute specific opportunities to specific events through attendee-to-CRM matching. Revenue Lift is different. It is an account-level, population-level incrementality measure that asks one question: do accounts that touched an event spend more than comparable accounts that did not? Revenue Lift compares an event-touched cohort against a non-touched cohort, where membership is determined by event attendance. It is deliberately separate from the Sourced and Influenced model and answers a program-level question rather than a deal-level one. It surfaces on the [Event Attribution Funnel](/docs/features/event-attribution-funnel). ## What heyBTW will not do These are commitments, not gaps. * **Never overwrite CRM revenue, stages, or opportunities.** heyBTW supplements the CRM with event and partner data. heyBTW writes only events, attendees, and partner attachment metadata. * **No pre-event touch-graph attribution.** SDR emails, newsletters, and ads are out of scope; marketing automation already measures those. Events are the unit of attribution, opportunities are the unit of outcome, and attendance is the link. * **Never present acceleration as a category, and never claim it caused anything.** It is a weight on Influenced, correlation only. * **Never claim sourced for a sales- or SDR-originated deal,** or because heyBTW drove the targeting. ## Stability The model commits to specific outputs; the implementation behind them can evolve. * **Stable.** The two-category Sourced and Influenced rule, the dimension names, the signal ordering, the exclusion rules, and the lock-on-close behavior. * **May evolve.** Signal weighting nuances, partner sub-hierarchy refinements, and the acceleration weight once it ships. If you build on a specific field through an MCP integration or downstream automation, pin to the schema version. Schema discovery is exposed via the MCP and OpenAPI surfaces. ## Related * [Event Attribution Funnel](/docs/features/event-attribution-funnel): how the dashboard surfaces these classifications. * [Enrichment](/docs/integrations/lead-enrichment): how attendees are resolved to companies so they can be matched. * [Context Graph Coordinates](/docs/concepts/context-graph-coordinates): the five dimensions every signal is located along. * [MCP Tools](/docs/integrations/mcp-tools): how to query attribution programmatically. # Context Graph Coordinates Source: https://heybtw.com/docs/concepts/context-graph-coordinates The five dimensions heyBTW uses to explain every recommendation, attribution, and insight. # Context Graph Coordinates The Context Graph is heyBTW's core data layer. It connects events, CRM pipeline, partner relationships, and attribution into a single queryable graph that powers every agent, dashboard, and MCP response. Every recommendation the graph produces is grounded in five coordinates. Agents, users, and MCP consumers can trace any surfaced account, attendee, or deal back to the signals that put it there. ## Events Event attendance history. A record carries the Events coordinate when the person or account has attended one or more co-marketing events tracked in heyBTW. The signal includes which events, how many, and which sessions. Example: "Attended Berlin Fintech Dinner and NYC SaaS Summit in the last 90 days." ## Timeline Recency and close-date proximity. A record carries the Timeline coordinate when engagement is recent or there is an open deal with a target close date. The signal captures when something last happened and when the next meaningful moment is expected. Example: "Deal closing in 12 days. Last event touch 3 weeks ago." ## Relationships Partner and account connections. A record carries the Relationships coordinate when the account has partner relationships mapped, a customer or prospect classification, or co-attendance overlap with other target accounts. Example: "Two partners, Stripe and Chargebee, have mapped this account as a customer." Relationship is the coordinate that makes the others cohere. Without it, event data is a list of attendees, CRM data is a list of accounts, and partner data is a list of logos. With it, those lists become a graph that compounds with every co-marketing activity that flows through the platform. ## Outcome CRM pipeline state. A record carries the Outcome coordinate when a deal exists in the connected CRM with stage, amount, and expected close. This is where the graph connects to revenue. Example: "\$150K opportunity in Negotiation, stage weight high." ## Attribution Data source and touch history. Always present. Attribution captures where a signal came from (CRM, event platform, partner upload, manual entry) and the sequence of touches that preceded it. This is what makes every recommendation auditable. Example: "First event touch March 4. Second touch May 12. Deal created May 20, classified as Sourced." ## How the coordinates compose A single recommendation usually carries multiple coordinates. A high-priority account might carry Events, Timeline, Relationships, Outcome, and Attribution all at once. When reading an agent output or MCP response, the coordinates tell you why the account is on the list and what to do next. Events and Timeline tell you when. Relationships tell you who to route through. Outcome tells you what's at stake. Attribution tells you how you got here. Relationship is the coordinate that ties the rest together: it turns four parallel signals into one connected path from a person to a partner to an event to a deal. ## Related * [Event Attribution Funnel](/docs/features/event-attribution-funnel): how Sourced and Influenced pipeline are computed * [MCP Tools](/docs/integrations/mcp-tools): how to query the graph from Claude, Copilot, or a custom agent * [Agent Quickstart](/docs/integrations/agent-quickstart): natural-language patterns the MCP supports * [Data Handling](/docs/concepts/data-handling): workspace scoping, privacy, and the two-path CRM architecture * [Scoring and Tiers](/docs/concepts/scoring-and-tiers): the score and tier legend for the Invite List Builder in the product UI. These are withdrawn and are not documented on any MCP tool reference page; do not build an agent on them. # Data Handling Source: https://heybtw.com/docs/concepts/data-handling How heyBTW scopes data, protects privacy, and lets enterprises choose between two CRM integration paths. heyBTW is built on four data handling principles. They apply to every query, every dashboard, every MCP response, and every collaboration with a partner. ## Workspace-scoped by default Every query, dashboard view, and MCP response is from the perspective of the workspace whose credentials authenticated the request. The MCP API key (`hbtw_ws_...`) is workspace-scoped, never user-scoped. The workspace is determined by the key itself and is never passed as a parameter. There is no way for a query to reach across workspaces. Inside a workspace, your own company's domain is excluded by default from company-level aggregation results. This prevents your own employees from skewing account-level analytics. ## Privacy-first Each workspace sees only its own data. heyBTW never exposes one workspace's CRM, attendees, or pipeline to another workspace. Cross-company signals (for example, Stripe and Chargebee both have an account mapped as a customer) are surfaced only when both workspaces have opted into a collaboration. No collaboration, no signal. ## No collaboration, no data heyBTW learns from co-marketing activity that flows through the platform. It does not scrape external relationship data, infer signals from channels it does not connect to, or build a shadow profile of accounts your team has not engaged with. The Context Graph is something your team builds over time by running collaborations through heyBTW. It is not a third-party data product you query against. ## Two-path CRM architecture Enterprises with strict CRM data residency or governance requirements can choose how heyBTW interacts with their CRM. Both paths are supported. ### Path A: Separate tools behind your agent Connect the heyBTW MCP and your CRM MCP (HubSpot MCP, Salesforce MCP, or your own internal tooling) as independent tools behind the same agent. The agent reasons over both, but no CRM data ever flows into heyBTW. Best for enterprises with data residency requirements, security teams that want to prevent vendor-side joins of CRM and event data, or teams already running an MCP-based agent stack. Trade-off: the agent does the join at query time, so heyBTW cannot pre-compute enriched results that depend on CRM context. ### Path B: CRM connected inside heyBTW Connect HubSpot, Salesforce, or Attio directly inside heyBTW. heyBTW reads contact, company, deal, and meeting data, joins it with event and partner data, and returns enriched results pre-joined. Best for teams that want the full Context Graph, including invite lists ranked against pipeline, attribution to specific deals, and partner relationship surfacing tied to CRM accounts. Trade-off: CRM data is processed by heyBTW. Standard scopes apply: read by default, write only for the fields you explicitly enable. Full integration details are in [CRM](/docs/integrations/crm). You can switch paths at any time. Disconnecting the CRM inside heyBTW removes the synced data on the heyBTW side. ## Trust Center For heyBTW's security posture, subprocessors, and compliance documentation, see the [Trust Center](https://trust.heybtw.com). ## Related * [MCP Tools](/docs/integrations/mcp-tools): API key generation, scoping, and tool reference. * [CRM](/docs/integrations/crm): HubSpot, Salesforce, and Attio integration details. * [Context Graph Coordinates](/docs/concepts/context-graph-coordinates): how relationships, attribution, and outcomes compose. # Scoring and Tiers Source: https://heybtw.com/docs/concepts/scoring-and-tiers What the score and tier on each account mean, and which one to build a workflow on. Accounts that surface in the Invite List Builder carry a score and a tier, so you can prioritize at a glance. This page is the legend for that in-product view. **This page describes the product UI. Do not treat it as the MCP contract.** The scores and tiers described here are being withdrawn (HEY-1764, HEY-1897, HEY-2067) and are documented on no MCP tool reference page. Some of the underlying scalars are still emitted on contract v1, which is the default — their removal is implemented in contract v2, which is not yet advertised — so you may see them in a live response. Seeing one is not a reason to build on it: they are withdrawn, and the per-tool reference pages are authoritative over this page for anything an agent consumes. If you are building an agent, work from the [MCP tool reference](/docs/integrations/mcp-tools) and rank on response order and source-backed fields, not on a score or tier threshold read from here. ## Score A 0 to 100 score that ranks an account by how strong its signals are: an open CRM opportunity, a partner relationship, event attendance history, and how many of those overlap. More independent signals push the score higher, so an account with both an open deal and event attendance ranks above one with only a single signal. The exact formula evolves as heyBTW learns what predicts pipeline outcomes. Treat the score as a ranking, not a fixed cutoff. ## Tier A simpler A, B, or C classification on top of the score, used across the product UI and in agent outputs: * **Tier A.** Focus here first. * **Tier B.** Worth activating. * **Tier C.** Track, but not an immediate action. Filters like "only Tier A in DACH" work directly against the tier. If you build a workflow on a threshold, use the tier rather than a raw score, because the tier stays stable while the score's internal formula can change. ## Where it shows up * **Invite List Builder.** Every recommended account card shows its score and tier. * **MCP responses.** Not a supported surface for these. No MCP tool reference page documents an account score or an A/B/C tier, and they are withdrawn. Contract v1 still emits some of the underlying scalars, but they are not part of the contract you should build on. Rank on the order the tool returns and on the source-backed fields documented per tool; see [`get_invite_recommendations`](/docs/mcp-tools/get-invite-recommendations). ## Relationship strength is scored separately In the [Context Graph Explorer](/docs/features/context-graph-explorer), the strength of a path into an account and the credibility of the people on it are scored on their own terms, from observed event behavior and seniority, and shown with their own labels. Those describe how to reach an account, not how to prioritize it, so they are separate from the account score and tier on this page. ## Related * [Attribution Model](/docs/concepts/attribution-model): how the underlying signals are computed. * [Context Graph Coordinates](/docs/concepts/context-graph-coordinates): the dimensions that feed scoring. * [MCP Tools](/docs/integrations/mcp-tools): what agents actually receive, which does not include these scores and tiers. # FAQ Source: https://heybtw.com/docs/faq/faq Quick answers about heyBTW, co-marketing attribution, and getting started. ## What does heyBTW do? heyBTW connects your co-marketing events to pipeline and revenue. See which partner events drive meetings, opportunities, and closed deals. No more spreadsheets. The Context Graph captures the cross-company relationship data behind those deals so you can prove what's actually working. ## How do I get started? Log in with your workspace domain and sync your first event from Luma, Splash, or Zuddl. Connect the HubSpot or Salesforce app to start getting attribution data. Your first event is free. See the [Quickstart guide](/docs/getting-started/quickstart) for step-by-step setup. ## Why can't I just use my CRM for this? Your CRM records attendance. It can't tell you which relationships influenced deals, which events created warm paths to meetings, or which partners are worth doubling down on. ## What is event attribution? heyBTW ties contacts and companies from co-marketing events to CRM opportunities and deal stages. See which events led to meetings booked, accelerated deals through stages, and influenced closed-won revenue. ## What is the Context Graph? The Context Graph is the relationship layer for B2B AI. It captures who was in the room together, which cross-company connections made introductions, and how those touchpoints map to pipeline. Every collaboration adds data. Over time, it becomes a strategic asset your competitors can't replicate. ## Is my data secure? Your CRM data stays private to your workspace. You choose which partners to collaborate with. Each organization owns and controls their own data. Partners in a collab see shared event metrics and attribution, never your raw CRM records or internal pipeline. ## How do I invite a partner to collaborate? Add partners by domain (e.g., `stripe.com`) or invite by email under My Partners. When your partner logs in with their workspace domain, they'll see your collaboration. Partners always join free. See [Adding and Inviting Partners](/docs/partner-ecosystem/adding-and-inviting-partners) for details. ## What does it cost? Your first event is free. Your partner always joins free. See [Pricing and Plans](/docs/faq/pricing-and-plans) for tier details. ## Can I use heyBTW for my own events, not just co-marketing? Yes. heyBTW supports all marketing events: your own hosted events, field events, conferences, webinars. You get full event attribution across all of them. What makes heyBTW different is the partner and ecosystem intelligence layer on top. ## I run community events with sponsors. How do I show them ROI? heyBTW has Sponsor Mode for conferences and community events. Each sponsor gets their own view of event ROI. You control which attendee data to share through tier-based data configuration. Sponsors can connect to their own workspace to see attribution results directly. See [Sponsor Mode](/docs/partner-ecosystem/sponsor-mode) for setup. ## Why not just build this myself? Each partner has their own tech stack. Co-marketing always comes down to copy-pasting between spreadsheets to keep everyone in sync. Even if it works inside your stack, it has no context about the relationships driving your pipeline. heyBTW captures that automatically and is building agent workflows to automate the coordination. ## What data does heyBTW write to my CRM? **HubSpot:** heyBTW syncs contacts (event attendees are created or matched). If MQL is enabled, it also updates the Lead Status field (`hs_lead_status`). Everything else (companies, deals, meetings) is read-only. **Salesforce:** Fully read-only. The managed package reads contacts, accounts, and opportunities for attribution but does not write anything back. Your Salesforce instance stays untouched. See [CRM integration](/docs/integrations/crm) for details. ## How does multi-event attribution work? When a contact attends multiple events before their deal closes, all contributing events receive attribution credit. This shows which sequence of events and partners moved the account through the funnel, not just the last touch. Individual collab rows in the performance table may sum higher than the deduplicated total on the Attribution Dashboard. This is expected. It reflects the reality that deals are influenced by multiple touchpoints. ## Will heyBTW create duplicate contacts in my CRM? No. Matching uses email as the primary key. If an attendee already exists in your CRM, heyBTW matches to the existing record rather than creating a new one. ## How does lead enrichment work? Enrichment fills in missing contact and company data on your event attendees. It uses credits. Your plan may include a number of credits, with additional credits available for purchase per lead. heyBTW always confirms before spending credits (e.g., "Confirm update 47 leads, using 47 credits"). See [Lead Enrichment](/docs/integrations/lead-enrichment) for details. # Pricing and Plans Source: https://heybtw.com/docs/faq/pricing-and-plans Start free, no credit card. Partners always join free. Add full attribution when you're ready. heyBTW connects the events you sponsor and co-host to the pipeline and revenue they drive. You can run co-marketing events, sync attendees to your CRM, and query your data from an AI agent without paying. Upgrade when you need full attribution, unlimited events, or write access from agents. ## Free **\$0 per month.** Collaborate on co-marketing events with partners and sync attendees to your CRM. Get started without a credit card. * Co-marketing event collaboration * 4 events per year * Partner account mapping * CRM contact sync * AI event summaries * 100 free contact enrichments * Connect to Claude, ChatGPT, and AI assistants ## Growth **\$149 per month.** Prove which co-marketing events drove pipeline. Full attribution, unlimited partners. * Everything in Free * Event Attribution Dashboard * Unlimited events, unlimited partners * Cross-event AI insights * Full MCP access for Claude, ChatGPT, and AI assistants (read) * Salesforce integration * 200 contact enrichments per month * Pay-per-lead enrichment at \$0.05 per lead above 200 ## Enterprise **Contact Sales.** For teams running large partner programs, with SSO, dedicated onboarding, and AI GTM agents. * Everything in Growth * SSO / SAML authentication * AI GTM Agents for unlimited AI-powered workflows * Custom enrichment volume * Dedicated onboarding Lead enrichment beyond your plan's included volume is metered at \$0.05 per enriched lead. Re-enriching a contact within 90 days reuses the cached result for free. See [Enrichment](/docs/integrations/lead-enrichment) for details. ## Partners always join free When you add a partner to a collab, they don't need a paid account. They join free and can see shared event data and attribution from their side. This is by design. The partner experience is how partners discover heyBTW. ## MCP for AI agents The eight MCP read tools are included on every plan, including Free. Agents like Claude, ChatGPT, or any custom agent can query your event intelligence, partner insights, attribution, cross-event patterns, invite recommendations, and per-event detail out of the box. One write tool, [`activate_list`](/docs/mcp-tools/activate-list), sends a saved List to its linked Luma event. It is gated on the `agent-connections-outbound` capability rather than on a plan tier by name. See [MCP Tools](/docs/integrations/mcp-tools) for setup and the full tool catalog. ## Questions? For enterprise pricing or custom needs, contact [ben@heybtw.com](mailto:ben@heybtw.com). # Agents Source: https://heybtw.com/docs/features/agents AI workflows that answer one question each, across your event data, CRM, and partner ecosystem. Agents are AI workflows that run across your event data, CRM, and partner ecosystem. Each one answers a single question at a single phase of the event lifecycle. Open them from **Agents** in the workspace sidebar. The header shows your workspace totals: Events, Attendees, Companies, Partners, and Integrations. Agents are deliberately narrow today. Each returns a focused answer rather than a long report. Treat them as a fast read on a specific question, not as a replacement for the [Event Attribution](/docs/features/event-attribution-funnel) dashboard. ## Running an agent 1. Open **Agents** and pick the agent for the question you have. 2. Choose a collaboration from the list. Each entry shows the event date, its phase (for example Post-Event or Planning), and the partners involved. 3. Click **Run**. The action on each row reflects its history: **Run** for the first time, **Run again** once it has been run before, and **Resume** to pick up a run that was left partway. Each agent card on the index shows how many runs it has completed, so you can see what your team is actually using. ## Pre-Event ### Invite List Builder **"Who should be in the room to maximize pipeline?"** Proposes a targeted invite list from your CRM pipeline and partner account mapping, so you are picking from accounts that matter rather than from whoever happens to be on a spreadsheet. The output is a [List](/docs/lists/overview). Once it exists, it behaves like any other list: filter it, work it in ABM or Invite Builder, and activate it when you are ready. The agent proposes and you dispose. Nothing is sent on your behalf. ## Post-Event ### Pipeline Impact Tracker **"Which deals moved because of this event?"** Returns attributed pipeline and the number of deals that moved for the selected event. It is the quick answer to "was that dinner worth it," and it is the number to check before a partner conversation. For the full picture, including the five-way influence split, stage progression per deal, and revenue lift, use the [Event Attribution Funnel](/docs/features/event-attribution-funnel). ### Follow-Up Intelligence **"Who needs follow-up and what context do I bring?"** Identifies attendees worth following up with and the context to bring: what they attended, their deal status, and the partner relationships in play. Pair it with a follow-up [List](/docs/lists/overview) when you want to route the result rather than read it. ## Related * [Lists](/docs/lists/overview): the object agents produce and the surface that activates it * [Event Attribution Funnel](/docs/features/event-attribution-funnel): the full attribution picture * [heyBTW AI](/docs/features/heybtw-ai): ask questions in natural language instead of running a fixed workflow # Approval Voting Source: https://heybtw.com/docs/features/approval-voting Require partner consensus before attendees are approved. Set a threshold, grant voting rights, and let partners vote directly from their view. # Approval Voting Approval Voting adds a consensus layer to your event RSVPs. Instead of one person deciding who gets in, partners vote on each attendee and the system approves them automatically once the threshold is met. This is useful when multiple partners co-host an event and need to agree on the guest list. Each partner sees only a vote dropdown for their own vote, and attendees move to Approved once enough partners say yes. ## Turning On Approval Voting Open a collab and go to the **My Partners** tab. The Approval Voting card appears in the settings area alongside Sponsor Mode. If Sponsor Mode is on, Approval Voting sits below the Sponsor Mode sub-features (UTM Attribution, Signup Quota, Show Questions to Partners). If Sponsor Mode is off, Approval Voting appears directly below the Sponsor Mode toggle. Either way, it is always available. Toggle it on. Approval Voting is independent of Sponsor Mode. You can use it with or without Sponsor Mode enabled. The two features compose when both are active, but neither requires the other. When you toggle Approval Voting on, a setup modal opens where you set the initial approval threshold. ## Configuration Three controls are available once Approval Voting is enabled. **Approval threshold.** The minimum number of partner approvals required before an attendee is approved. Set this with the +/- stepper. Minimum is 1, maximum is the number of partners with voting rights. If you lower the threshold, attendees who already meet the new threshold are auto-approved. **Voting rights.** Each partner in the collab has a toggle to grant or revoke voting rights. The collab creator's voting rights are always on and cannot be toggled off. All partners default to voting rights on when Approval Voting is first enabled. If you revoke a partner's voting rights and that drops the voting partner count below the current threshold, the threshold auto-reduces to match. **Per-collab setting.** Approval Voting is configured per collab, not globally. You can have it on for a conference with 5 co-hosts and off for a small dinner. ## How Voting Works When Approval Voting is enabled, all attendees who are not already Approved or Rejected move to **Pending Vote** status. Each partner with voting rights sees a vote column in the attendee table with a dropdown to cast their vote. Votes are evaluated in real time. When an attendee reaches the approval threshold, their status automatically changes to Approved. If an attendee cannot mathematically reach the threshold (enough partners have voted no), the system handles that as well. The collab creator can override any individual vote decision. ## What Partners See Partners with voting rights see their own vote dropdown in the attendee table. They can see the vote columns for all voting partners, including partner names as column headers. This is true regardless of the partner's Sponsor Mode tier settings. Even if a partner's tier has "See other partners" turned off, they still see all vote column headers when they have voting rights. Voting rights and tier visibility are completely independent systems. If you do not want a partner to see other partner names via vote columns, revoke their voting rights. ## Composing with Sponsor Mode When both features are active, they layer on top of each other. **Sponsor Mode on, Voting on.** Tier visibility controls which attendee data columns partners see. Vote columns are always visible to voting partners regardless of tier. Status shows as a read-only badge. **Sponsor Mode off, Voting on.** All attendee data is visible to partners. Vote columns are visible to voting partners. Status shows as a read-only badge. **Sponsor Mode on, Voting off.** Tier visibility applies normally. Status is hidden from partners. **Sponsor Mode off, Voting off.** Standard collab. Partners have full access including the interactive Status dropdown. Disabling Sponsor Mode has no effect on Approval Voting, and disabling Approval Voting has no effect on Sponsor Mode. ## Disabling Approval Voting Toggle Approval Voting off in the My Partners tab. A confirmation dialog warns that pending votes will be cleared. All attendees with Pending Vote status revert to their previous status. Vote data is preserved for audit but no longer active. # Collab Performance Table Source: https://heybtw.com/docs/features/collab-performance-table Compare performance across all your co-marketing collaborations. ## Overview The Collab Performance Table gives you a side-by-side view of how each co-marketing collaboration is performing. Instead of checking individual collabs one at a time, you get a single table showing attribution metrics across all your events and partners. ## What's in the Table Each row represents a collab, and columns include: * **Collab Name** - The event or campaign name. * **Partner** - Which partner you collaborated with. * **Attendees** - Total attendees from the event. * **Meetings** - Meetings booked with event attendees. * **Opportunities** - Opportunities created or influenced. * **Revenue** - Deal value attributed to the event. ## Understanding Multi-Event Attribution in the Table A single deal may be influenced by multiple events. When this happens, the deal appears in the row for each contributing collab. This means the sum of individual collab rows may be higher than the total shown on the Attribution Dashboard's Sourced card. This is expected behavior, not double-counting. It reflects the reality that deals are often influenced by multiple touchpoints. Look at the Sourced card on the Attribution Dashboard for the deduplicated total. Hover over metrics in the table for tooltips explaining how multi-event attribution applies to that specific number. ## Sorting and Filtering Sort the table by any column to quickly find your top-performing collabs. Filter by partner, date range, or event type to focus on specific segments of your program. ## Using It for Partner Conversations The Collab Performance Table is designed to be shareable. Use it in partner QBRs to show which joint events delivered the best results and where to invest next. Export the table or share a link with your partner contact. # Collabs Source: https://heybtw.com/docs/features/collabs Your event workspace. Track attendees, manage partners, run AI insights, and prove attribution. A collab is the workspace for a single event. When you import events from your event platform, each event becomes a collab automatically. That is the preferred route, because attendee data flows in with it. Tabs across the top: **Overview**, **ABM**, your connected CRM (for example **HubSpot**), **My Partners**, and **Attribution**. **Run AI agent** sits in the top right of every tab. ### Creating a Collab Click the **+** next to **Collabs** in the left sidebar. The dialog offers two routes. **Import from Luma URL.** Paste an event URL and heyBTW pulls the details. See [Event Platforms](/docs/integrations/event-platforms) for how guest data follows. **Create manually.** Fill in: * **Name** - The collaboration name. * **Location** - Optional, for example San Francisco, CA. * **Collaboration Type** - In-Person Event, Webinar, or Content Collaboration. * **Dates & Times** - Set the start, then pick a duration: 1h, 2h, 3h, 4h, All day, or Custom. The end time updates as you choose, shown as "Ends +3h." * **Timezone** - All times display in this timezone. Manual collabs do not auto-import attendees. Upload by CSV or connect an event platform later. ### Finding a collab The Collabs list in the sidebar has its own sort and filter controls, which matter once you are past a dozen events. **Sort** by Recent, Event date, A to Z, Status, or Location. **Filter** by Status (Live, Upcoming, Past), Region, and Rep. The **...** menu on any collab offers **Pin**, **Edit details**, **Archive**, and **Delete**. Pin the two or three you are actively running. Archived collabs move under **View archived** and stay searchable. ## Overview Tab The Overview has two collapsible sections at the top, plus the attendee table below. ### Event Overview Shows your event details and progress: * **Event Name** - Editable. * **Cost (USD)** - Enter your event cost. This feeds into attribution ROI calculations. * **RSVP Target** - Set a target (e.g., 50 RSVPs). Used for progress tracking. * **RSVP Progress** - Shows current RSVPs against your target with a progress bar (e.g., "15/50 RSVPs, 30%, Getting Started!"). * **Timeline Progress** - Days remaining until the event date. ### AI Event Attendee Insights Ask heyBTW AI questions about your attendees for this specific event. The AI has context on your attendee data, enrichment, RSVPs, event information, and registration question answers. Example prompts: * "What are the main roles of our attendees?" * "Which attendees are the best prospects?" * "Provide a breakdown of attendee answers to registration questions, segmented by the question." * "Who are the decision makers in our audience?" Type your own question in the input field or click a suggested prompt. Both the Event Overview and AI Insights sections can be collapsed to give you more space for the attendee table. ### Latest Attendees Table The main data view. Each row is an attendee with columns for: * **Full Name** * **Email** * **Status** - Dropdown with options: Approved, Declined, Waitlist, Checked In, Invited, Pending, Pending Vote, Session. * **Company** * **Title** * **LinkedIn** * **CRM Status** - Net New, Open Opportunity, or Customer. * **Event History** - How many of your prior events this person attended, or First time. * **Partner Source** - Which partner sourced this attendee. Set automatically via UTM tracking (if Sponsor Mode defines a UTM per partner) or manually by selecting which partner invited them. Host and co-host staff are marked EXCLUDED so your own team never counts as sourced attendance. * **MQL** - Checkbox. When checked, syncs the Lead Status (`hs_lead_status`) to HubSpot. * **Meeting Booked** - Checkbox. Track whether a meeting was booked with this attendee. * **Opportunity** - Checkbox. Track whether an opportunity was created. **Summary pills.** Above the table, heyBTW breaks the room down before you touch a filter, with a plain-language line beneath, for example "32 attendees. 14 already in your CRM, 10 with open opportunities. 18 net new prospects. 9 sourced by your partners." **Filtering:** Status, Check-In, Partner Source, Contact Type, Target Acct, CRM Status, Event History, and Engagement. Event History is the underrated one. It separates first-timers from people on their third event, which is usually a better signal than anything else on the row. **Enrich:** Click the **Enrich** button to run lead enrichment on attendees. Uses credits. See [Lead Enrichment](/docs/integrations/lead-enrichment). **Manage Columns:** Click the column icon to show or hide columns. **Export:** Download the attendee data. ## ABM Tab Account-Based Marketing for this specific event. A shared account mapping dashboard visible to all partners in the collab. ### How It Works Each partner uploads their target account list (CSV). heyBTW maps overlap across all partners so everyone can see where to focus. The left sidebar shows: * **Relationship Status** filter (All Companies). * **Partner View** filter (All Partners). * **Partner Uploads** - Each partner's upload status (Completed or Upload Needed). Click **CSV** to upload your list. The main table shows **Account Mapping** with columns for: * **Company** - Account name. * **Vertical** - Industry (Fintech, Gaming, Unknown, etc.). * **One column per partner** - Shows each partner's relationship with that account. * **Priority** - How important this account is for the event. Use this to coordinate who invites who. If both you and your partner have a relationship with an account, decide which side sends the invite. If only one partner knows the account, that partner takes the lead. ### ABM vs. Partner Ecosystem Dashboard The ABM tab is scoped to one event. It answers: "For this specific event, which accounts should we prioritize and which partner should invite them?" The [Partner Ecosystem Dashboard](/docs/partner-ecosystem/partner-ecosystem-dashboard) is workspace-wide. It answers: "Across all events and partnerships, how do our accounts overlap?" ## Inviting Partners Click **+ Partner** in the top right of any collab to open the Invite Partners modal. Enter partner domains (e.g., `meta.com`, `appsflyer.com`, `braze.com`). Users with email addresses from those domains will be automatically joined to this event. You can add multiple domains and remove them with the Delete button. This is domain-based access. No email invitation is sent. Partners see the collab when they log into their own heyBTW workspace. ## Collab Tabs Reference | Tab | What It Does | | --------------- | ------------------------------------------------------------------ | | **Overview** | Event details, RSVP tracking, AI attendee insights, attendee table | | **ABM** | Per-event account planning, working from a List | | **HubSpot** | Settings for the connected CRM on this collab | | **My Partners** | Partner list, tier assignments, Sponsor Mode controls | | **Attribution** | Attribution for this event | # Context Graph Explorer Source: https://heybtw.com/docs/features/context-graph-explorer The interactive window onto your Context Graph. One graph, three lenses: Connect to open a relationship, Accelerate to move a deal, and Influence to prove the impact. The Context Graph is the intelligence layer underneath heyBTW. Every surface, the dashboard, the [MCP tools](/docs/integrations/mcp-tools), and the attribution funnel, reads from it, so the numbers never diverge no matter where you look. The Context Graph Explorer is the place you see that graph directly and work it. The Explorer is organized as one graph with three lenses: **Connect**, **Accelerate**, and **Influence**. Same underlying graph, three questions it can answer. Your graph is scoped to your workspace. Each customer gets their own. Connect and Influence are live. Accelerate is coming soon. The lens still appears in the Explorer so you can see what it will surface. ## One graph, three lenses * **Connect** answers "how am I connected to this account, and what is the warmest way in?" * **Accelerate** answers "which open deals have stalled, and what would move them?" * **Influence** answers "which partners, collections, and events actually drove closed pipeline?" Every lens shares the same filters across the top: collection, partner, region, and rep, plus a time window. Filtering by collection is the most common starting point, since it scopes the whole view to one conference or program. ## Connect: open the relationship The Connect lens lists your target accounts that have an unused warm path, ranked by open pipeline. More independent paths into an account means a warmer, more reachable account, so the ranking surfaces the accounts where you have leverage you have not spent yet. Each row shows the account, its stage and region, the open pipeline value, and the warmest route in: which partner the path runs through, how many independent paths exist, and the strongest single connection (often a specific event or collection). A suggested next step sits on each row, for example an invite to an upcoming event or a warm intro from a named person. Select a row and the panel on the right shows how to reach that account: the warm paths you already have, drawn as a small graph from your trusted network into the account, with an option to show the co-attendees behind each path. A **Trusted voices** panel ranks the people who can vouch for you into that account, scored from event behavior and seniority. The score is explainable, never a black box: each person carries the evidence behind their rating, such as hosting a shared room, repeat co-attendance, or seniority in the account. You can also sort by connection strength and filter to partner intros only when you want routes that go through a partner rather than a direct contact. ## Accelerate: move the deal Coming soon. The Accelerate lens lists your open opportunities by time stalled, and flags the ones where an event or partner touch could move the deal. Each row shows the account, stage, open value, and how long the deal has been sitting in stage, along with whether it has gone untouched by any event recently or when its last touch was and through which partner. Select a deal and the right panel shows the lever that would progress it. It compares deal velocity in your workspace, the average days to close for event-touched deals versus deals with no event touch, and surfaces a suggested next step you can add to a plan. This is the velocity story behind the [acceleration weight](/docs/concepts/attribution-model) in the attribution model: event-touched deals tend to close faster, and Accelerate shows you the stalled deals where that lever is available. ## Influence: prove the impact The Influence lens shows your attributed and influenced pipeline: [Sourced](/docs/getting-started/glossary#sourced) first-touch credit versus [Influenced](/docs/getting-started/glossary#influenced) any-touch credit, with host and partner presence excluded so a partner cannot take credit for sitting in its own room. Group the view by partner, [collection](/docs/getting-started/glossary#collections), or event depending on what you are trying to prove. Each row shows the deal count and total pipeline for that partner or collection, with the Sourced and Influenced split drawn as a single bar. Select a deal and the right panel reconstructs why it closed: the multi-touch path from first touch to Closed Won, frozen at the close date so the story does not drift after the fact. This is the same data the [Event Attribution Funnel](/docs/features/event-attribution-funnel) reports and the same payload an agent receives over MCP. The dashboard and the agent never diverge, because they read the same canonical service. ## Explore the whole workspace Alongside the three lenses, the Explorer includes a graph view for seeing your whole workspace at once. The graph is built from a small set of node types: * **Collection**: a grouping of related events, such as all of your activations at one conference. * **Event**: a single dinner, roundtable, or activation. * **Partner**: a co-marketing partner in your ecosystem. * **Target account**: an account you are trying to reach or move. * **Person**: an attendee or contact. * **Unlisted agency**: an inferred intermediary, such as a media agency that brokers a relationship, shown as a hollow node because it is inferred from co-attendance rather than entered directly. Your workspace sits at the center. From there you can follow any node to see how it connects, or jump to a focused view such as the warm paths into a single account or the partner network behind a conference. ## Proof, not a black box Every row in every lens can show why it surfaced and what to do next. That "why" traces back through the [Context Graph coordinates](/docs/concepts/context-graph-coordinates), the dimensions heyBTW locates each fact along, so a recommendation is always backed by the events, attendance, and relationships that produced it. Scores are derived from observed event behavior and seniority, and the evidence is shown alongside the score. ## Related * [Context Graph Coordinates](/docs/concepts/context-graph-coordinates): the dimensions every fact in the graph is located along. * [Attribution Model](/docs/concepts/attribution-model): how Sourced and Influenced are defined, and where the acceleration weight fits. * [Event Attribution Funnel](/docs/features/event-attribution-funnel): the dashboard view of the same Influence data. * [MCP Tools](/docs/integrations/mcp-tools): query the same graph from an AI agent. * For a conceptual overview of the Context Graph, see [heybtw.com/context-graph](https://heybtw.com/context-graph). # Event Attribution Funnel Source: https://heybtw.com/docs/features/event-attribution-funnel Full-funnel attribution from event attendance to closed revenue, with partner influence tracking and configurable stages. The Event Attribution Funnel is where heyBTW proves that relationships close deals. It connects the dots between who attended your co-marketing events and what happened in your pipeline afterward. No more guessing whether an event was worth it. Find it in the left sidebar under **Event Attribution**. It requires a connected CRM (HubSpot, Salesforce, or Attio) to populate. ## Freshness Attribution refreshes daily. The header shows the connected CRM and when the data was last updated, for example "Updated 11 hours ago." Click **Refresh** to pull immediately instead of waiting for the next daily run, which is worth doing before a board meeting or a partner QBR. Click **Audit** to see how a number was produced. Use it whenever a figure looks wrong, before assuming it is. ## Attribution Cards Summary cards at the top show your attribution at a glance. * **Sourced.** Pipeline and revenue where the first meaningful touchpoint was an event managed through heyBTW. The deal originated from event attendance. Shows total pipeline value, number of deals, won revenue, and win rate. * **Influenced.** Pipeline where the deal already existed but a co-marketing event touched someone involved in the buying process. The event moved the deal rather than creating it. Shows the same metrics as Sourced. Both matter. Sourced deals prove your events create pipeline. Influenced deals prove your events move it. Both cards show deduplicated totals: if a deal was touched by multiple events, it counts once in the card total. ## How Classification Works heyBTW classifies each attributed deal as either Sourced or Influenced. The boundary is a comparison of two dates: the date the deal was created in your CRM, and the date the associated contact first attended one of your events. * **Sourced.** The contact's first event attendance came before the deal was created. The event came first, so the event is credited with creating the relationship. * **Influenced.** The deal was created before or on the same day as the contact's first event attendance. The deal already existed, so the event is credited with touching an open opportunity. Classification is per deal, not per contact. A contact can have Sourced deals and Influenced deals at the same time depending on when each deal was created. Matching is by email first, with partner domain as a fallback. Deals with no attending contact do not appear in either card. For the full Sourced definition, including how heyBTW avoids crediting deals that sales was already actively working, see the [Attribution Model](/docs/concepts/attribution-model). ## Influence Breakdown Sourced and Influenced are the top-level classification. The **Influence Breakdown** splits attributed pipeline five ways beneath it, each card showing dollar value, opportunity count, and share of the total. * **Direct.** First touch via your own events, no partner co-host. * **Direct Influenced.** Existing opportunities advanced by your own events. * **Partner Sourced.** First touch via partner events. * **Partner Influenced (New).** New opportunities accelerated by partner events. * **Partner Influenced (Expansion).** Existing accounts expanded via partner events. The first two are your own events, the last three involve a partner. Read it as a two-by-two that heyBTW splits into five: who owned the room, and whether the deal already existed. ## Conversion Funnel The funnel shows your event-attributed pipeline as a sequence of stages. Each stage shows the count and conversion rate from the previous stage. Stages are configurable and mapped to your own CRM pipeline, so what you see depends on how your workspace is set up. A common four-stage configuration is MQLs, Demo Completed, Opportunities, and Closed Won. Only contacts who attended events managed through heyBTW appear in the funnel. If someone is in your CRM but never attended one of your events, they do not show up here. This is what makes it an event attribution funnel, not a general CRM funnel. ## Configure Funnel Click **Configure Funnel** to map each stage to the corresponding deal stage in your CRM. For example, map "Closed Won" to your CRM pipeline's Closed Won stage. If your workspace has multiple CRM pipelines (for example, a "Sales Pipeline" and a "heyBTW Sales Pipeline"), make sure the funnel stages are mapped to the correct pipeline. Stage identifiers differ between pipelines even when the labels look the same. ## Time Period Filtering Filter the funnel by time period using the tabs at the top: Last 30 Days, This Quarter, Last Quarter, YTD, and Program Total. The time period scopes which events are included. "Last Quarter" shows the funnel for attendees of events that occurred last quarter. "Program Total" includes all events across your entire history with no date filter. All funnel stages, attendee counts, attribution cards, and the opportunities table update to reflect the selected time period. ## Event-Attributed Pipeline The **Event-Attributed Pipeline** card gives you the total in one number, with opportunity count, won revenue, win rate, and average deal size beneath it. Deal values are counted in full rather than split fractionally across the events that touched them. If several of your events touched the same deal, it appears once at full value and the Influence Breakdown attributes it to the relevant type. This is the number for an executive conversation, because fractional splitting dilutes exactly the multi-event pattern you are trying to demonstrate. ## Partner Scorecard The Partner Scorecard rolls attributed pipeline up by partner. This is the view for a partner QBR, and for deciding which relationships to invest in next quarter. ## Revenue Lift Revenue Lift answers a different question from Sourced and Influenced. Instead of attributing specific deals to specific events, it measures incrementality at the account level: do accounts that touched an event spend more than comparable accounts that did not? heyBTW splits your accounts into two cohorts: * **Event-Touched.** Accounts with at least one attendee matched to one of your events. * **Non-Touched.** Accounts with no event attendance. Cohort membership comes from attendance and is fixed by the data already in your workspace. Today, account spend is brought in by uploading a CSV through the Revenue Lift tile, mapping monthly spend onto accounts by company name and domain. Once spend is attached, the dashboard shows each cohort's spend, the lift versus the non-touched baseline (touched spend minus non-touched spend, divided by non-touched spend), and a month-over-month chart of the two cohorts. A positive lift means touched accounts outspend the non-touched baseline. Because this is a cohort comparison rather than a before-and-after measurement on the same accounts, read it as a program-level signal, not deal-level attribution. Spend upload is a manual CSV process today. Automated ingestion is planned. ## Attributed Opportunities Below the funnel, the **Attributed Opportunities** table shows the individual deals behind the numbers. Each row is an opportunity, with columns for Company, Deal, Amount, Stage, Attribution Type, **Stage Progression**, Last Event, and Contact. Stage Progression is the one to read closely. It shows whether the deal actually moved after the event, not just that it was touched, which is the difference between an event that influenced a deal and an event that happened near one. Tabs split the table into **All**, **Sourced**, and **Influenced** with counts, and you can filter by partner, by stage, or narrow to event-attributed deals only. Sort by any column and export to CSV for board presentations, partner QBRs, or BI tools. ## Multi-Event Attribution When a contact attends multiple co-marketing events before their deal closes, heyBTW tracks the full sequence. This is critical for understanding which combination of events moved an account through the funnel. ## Cost Metrics If you enter event costs on your collabs, the funnel calculates: * **Cost per Meeting.** How much you spent per meeting generated from an event. * **Cost per Opportunity.** How much you spent per opportunity created. * **Event ROI.** Revenue attributed to the event divided by its cost. These metrics let you compare performance across events and optimize your calendar. ## Partner-Specific Funnels Each partner in a collab has their own independent funnel view. Partners can mark leads as MQL, Meeting Booked, or Opportunity from their own view of the attendee table using the checkbox columns. Partner funnel data is workspace-scoped: updating a lead's status on one partner's workspace does not affect another partner's funnel. This lets each partner track their own pipeline progression independently. ## Exporting Export attribution data for board presentations, partner QBRs, or BI tool ingestion. Exports are available in CSV format and can be filtered by the same criteria as the funnel. ## Related * [Attribution Model](/docs/concepts/attribution-model): the full Sourced, Influenced, and Acceleration definitions. * [Context Graph Coordinates](/docs/concepts/context-graph-coordinates): the five dimensions heyBTW uses to explain attribution. * [MCP Tools](/docs/integrations/mcp-tools): query attribution data from Claude, ChatGPT, or a custom agent. # Event Platform Sync Source: https://heybtw.com/docs/features/event-platform-sync Automatic attendee capture from Luma, Splash, and Zuddl. ## Overview Event Platform Sync automatically captures attendee data from your connected event platforms. No more exporting CSV files, cleaning up columns, and manually uploading attendee lists into your CRM. heyBTW handles it. ## Supported Platforms * **Luma** - [Setup guide](/docs/integrations/event-platforms) * **Splash** - [Setup guide](/docs/integrations/event-platforms) * **Zuddl** - [Setup guide](/docs/integrations/event-platforms) ## What Gets Captured For each event linked to a collab, heyBTW automatically captures: * Registrations and RSVPs (with timestamps) * Attendee check-ins * Contact details (name, email, company) * Engagement signals specific to the platform ## Automatic CRM Matching Once attendee data arrives, heyBTW matches each attendee against your connected CRM using email address as the primary key. Matched attendees are linked to their CRM contact and account records, enabling attribution tracking from that point forward. Unmatched attendees (contacts not yet in your CRM) are flagged for review. You can configure whether these contacts get created in your CRM or stay in heyBTW only. ## Cross-Platform Events If you use Luma and your partner uses Splash, both platforms sync into the same collab. Attendee data is unified regardless of which platform each side uses. This is one of the key advantages of heyBTW for cross-organizational events: you don't need to be on the same tools to collaborate. ## Real-Time Updates Event data syncs in near-real-time. As attendees register, RSVP, or check in, the data appears in your collab automatically. No manual refresh required. # heyBTW AI Source: https://heybtw.com/docs/features/heybtw-ai The conversational intelligence layer across heyBTW. Ask in plain language and get answers from your Context Graph: event history, partner relationships, attribution, and pipeline. heyBTW AI is the assistant built into the platform. Ask it a question in plain language and it answers from your Context Graph, the same canonical data behind every dashboard and MCP response. As your Context Graph grows with each collaboration, its answers get richer and more actionable. heyBTW AI was previously called AI Insights. It is the same intelligence, now accessible across the platform rather than from a single tab. ## What you can ask * "How many touchpoints have we had with \[Account]?" See the full history of a target account's engagement across all your co-marketing events. * "Show me attendees who haven't been contacted by sales yet." Identify warm leads from recent events that need follow-up. * "Tell me about our \[Partner] relationship." Get a summary of your collaboration history, attribution metrics, and trends with a specific partner. * "Which recent event leads need sales follow-up?" Surface high-intent attendees based on their account's pipeline status. ## Where it draws from * Your event attendee data across all collabs. * Your CRM pipeline data (contacts, accounts, deals, meetings). * Cross-event patterns (accounts that appear at multiple events). * Partner-level performance trends. ## What it will not do heyBTW AI does not invent relationships. If an account never appeared at a co-marketing event run through heyBTW, it will not claim a relationship exists. It follows the same rules as the rest of the platform: it leads with [Influenced](/docs/concepts/attribution-model) for in-flight pipeline and claims [Sourced](/docs/getting-started/glossary#sourced) only with clear evidence and provenance. It will not manufacture a source touch from heyBTW having driven the targeting. ## Cross-event intelligence One of the most useful patterns heyBTW AI reveals is cross-event behavior. If an account attended three different co-marketing events over six months before its deal closed, heyBTW AI shows that full journey, helping you understand which sequence of events and partners contributed to the conversion. The [Context Graph Explorer](/docs/features/context-graph-explorer) is the visual counterpart to this, with the same path frozen at the close date. ## Across the platform heyBTW AI is being made accessible across screens and features, so the same intelligence is one question away whether you are looking at an event, a partner, or the Context Graph Explorer. You do not have to leave what you are doing to ask. ## Getting better over time heyBTW AI improves as your Context Graph grows. Early on, answers focus on individual event performance and attendee matching. As you accumulate more collaborations, it starts surfacing strategic patterns: which partners consistently drive pipeline, which event formats convert best, and where overlapping account interest signals an opportunity. ## Related * [Context Graph Explorer](/docs/features/context-graph-explorer): the visual view of the same graph. * [Agents](/docs/features/agents): structured, guided AI workflows for each phase of the event lifecycle, such as the Invite List Builder. * [MCP Tools](/docs/integrations/mcp-tools): the same intelligence, queryable by an external AI agent. * [Attribution Model](/docs/concepts/attribution-model): how Sourced and Influenced are defined. # Workspaces Source: https://heybtw.com/docs/features/workspaces Your organization's home in heyBTW. ## Overview A workspace is your organization's home in heyBTW. It holds everything: your integrations, your partner network, your collabs, and all your attribution data. When you sign up, you create a workspace for your company. Team members join the same workspace to share access to collabs, dashboards, and partner data. ## What's Inside a Workspace Your workspace sidebar gives you access to: * **Overview** - Quick stats, integration status, and recent activity. * **AI Insights** - Cross-event intelligence and recommendations. * **Collabs** - All your active and past co-marketing collaborations. * **My Partners** - Your full partner network with performance data. * **Settings** - HubSpot settings, event platform settings, and team management. ## Integration Status The Workspace Overview shows the connection status of your CRM and event platform integrations at a glance. You'll see cards for HubSpot (or Salesforce), your connected event platform, and Lead Enrichment status. ## Quick Stats The overview displays high-level metrics including: * Total number of active collabs * Total signups and attendees across events * Revenue influenced and program ROI (once attribution data accumulates) ## Team Management Invite team members to your workspace so they can access collabs, attribution dashboards, and partner data. Each team member authenticates through their own account, and access is scoped to your organization's workspace. # Glossary Source: https://heybtw.com/docs/getting-started/glossary Key terms and concepts used throughout heyBTW. Key terms and concepts used throughout heyBTW. This glossary is the single source of vocabulary for heyBTW. Every concept is defined here once. Concept pages, feature pages, and MCP tool descriptions link back to this page rather than redefining a term. When a definition changes, it changes here first. ## ABM ABM stands for Account-Based Marketing, the practice of prioritizing a defined list of target accounts rather than casting a wide net across inbound leads. In heyBTW, ABM is the account mapping feature available within a collab and across your partner ecosystem. ABM powers invite planning and list building: which companies to prioritize, which partner is best positioned to invite which account, and how invitation coverage is progressing across partners. Accounts can be flagged as high priority to align every partner in the collab on where to focus invitations. See also: [Global Prospect](#global-prospect), the workspace-level version of the same idea. ## Acceleration A velocity weight applied to [Influenced](#influenced) deals. It measures how event touches correlate with faster stage progression through your pipeline, correlation only, never causation. Acceleration is not a third attribution category. Every deal is still classified as either [Sourced](#sourced) or [Influenced](#influenced); acceleration only describes how much an event appears to have sped up an Influenced deal. This weight is in development and not yet displayed. ## Approval Voting A collab-level feature where partners vote on pending attendees. When enabled, attendees who are not already Approved or Declined carry a [Pending Vote](#pending-vote) state. Once the voting threshold is met, the vote resolves each attendee to Approved, Declined, or Waitlist. Collab creators can override a vote outcome at any time. ## Attendee (EventSignUp) The unified attendee record across all integrated event platforms. When a person registers for a collab on Luma, Splash, or Zuddl, heyBTW creates a single Attendee record that every downstream feature reads from: analytics, ABM matching, CRM sync, partner funnels, and MCP responses. Regardless of which platform the person registered through, their Attendee record has the same shape. Attendee statuses follow this lifecycle: * **INVITED**: the attendee was invited but has not yet responded. * **PENDING\_APPROVAL**: the attendee registered; the host has not yet approved them. * **APPROVED**: the host confirmed attendance. * **WAITLIST**: the attendee is queued and will be admitted if space opens. * **DECLINED**: the attendee declined the invitation or was declined by the host. * **SESSION**: the attendee is registered for a specific session within a multi-session event. * **CHECKED\_IN**: the attendee physically checked in at the event. These statuses reflect what Luma, Splash, and Zuddl support. Each platform emits its own set, and heyBTW normalizes them into this shared lifecycle so every Attendee record reads the same way. Collab creators can override any attendee status directly, regardless of what the event platform reports. ## Pending Vote When [Approval Voting](#approval-voting) is enabled on a collab, attendees who are not already Approved or Declined carry an additional PENDING\_VOTE state on top of their platform status. Pending Vote is a conditional heyBTW state, not an event platform state. The underlying event platform status (Luma, Splash, or Zuddl) does not change while Pending Vote is active. Once the voting threshold is met, the vote resolves the attendee to Approved, Declined, or Waitlist based on the outcome, and that resolution is what propagates back to the event platform. Collab creators can override a vote outcome or any RSVP status at any time. ## Attio A supported CRM. Like HubSpot and Salesforce, Attio connects to your [Workspace](#workspace) so heyBTW can match event attendees to your pipeline and compute [Attribution](#attribution). heyBTW reads Attio deals for attribution and writes enriched People records, including custom attributes, back into Attio. Only one CRM connects at a time. See [CRM](/docs/integrations/crm) for connection steps. ## Attribution The process of connecting a co-marketing event to downstream pipeline outcomes. Every deal is classified into exactly one of two categories: * **[Sourced](#sourced)**: first event attendance came before the deal was created. The event is credited with creating the relationship. * **[Influenced](#influenced)**: the deal already existed at or before first event attendance. The event is credited with touching an open opportunity. These are the only two categories. [Acceleration](#acceleration) is a velocity weight on Influenced deals, not a third category. See [Attribution Model](/docs/concepts/attribution-model) for how Sourced and Influenced are computed. ## Auto-Enrich A setting that enriches every event imported from Luma, Splash, or Zuddl automatically as RSVPs sync, rather than waiting for you to trigger it. Auto-Enrich runs in the background and respects a scope (for example, Approved only), a Skip partner contacts option, and per-event overrides. It draws on the same enrichment credits as on-demand runs. See [Enrichment](/docs/integrations/lead-enrichment) for details. ## Collab A shared workspace for a specific co-marketing event or campaign between you and a partner. Each collab contains event details, invite lists, attendee data, and attribution metrics visible to both sides. ## Collections A grouping of related events. Collections, formerly called Conferences, let you roll up multiple events that belong together: every event around a single conference, a region, a sales rep, a recurring meetup series, or any other grouping you define. Analytics and attribution can be viewed across a whole Collection or per individual event. ## Context Graph The cross-organizational dataset that heyBTW builds over time from your co-marketing collaborations. Every event, attendee interaction, and pipeline outcome adds to the graph. The more collaborations you run, the richer the intelligence becomes. Every signal in the graph is organized along five coordinates (Events, Timeline, Relationships, Outcome, Attribution) that explain why a recommendation was surfaced. See [Context Graph Coordinates](/docs/concepts/context-graph-coordinates) for details. ## Context Graph Explorer The interactive view onto your [Context Graph](#context-graph), organized as one graph with three lenses: Connect (the warmest paths into a target account), Accelerate (open deals that have stalled and what would move them), and Influence ([Sourced](#sourced) versus [Influenced](#influenced) pipeline). Connect and Influence are live; Accelerate is coming soon. Every row shows why it surfaced and a suggested next step. It reads from the same canonical data as the dashboard and the [MCP Server](#mcp-server), so numbers never diverge. See [Context Graph Explorer](/docs/features/context-graph-explorer). ## CRM Sync The connection between heyBTW and your CRM (HubSpot, Salesforce, or Attio). One CRM connects to a workspace at a time. heyBTW reads deal stages, amounts, and close dates to match event attendees to pipeline outcomes, and can write enriched attendee contacts back. You control what flows back to your CRM. See [CRM](/docs/integrations/crm). ## Enrichment Resolving an attendee's identity and firmographics, especially for personal-email registrations, so the attendee can be matched to a company and to pipeline. Enrichment adds company, title, seniority, LinkedIn profile, company size, industry, and location. It never adds phone numbers. It can run automatically (see [Auto-Enrich](#auto-enrich)), on demand for a single event, or as a one-shot pass over past events. Enrichment is metered: one credit enriches one contact, new accounts include 100 free enrichments, paid plans include a monthly allowance that resets each cycle, and overage is priced per lead. Re-enriching a contact within 90 days reuses the cached result for free. See [Enrichment](/docs/integrations/lead-enrichment). ## Event History Import Backfilling past events into your workspace so attribution works from day one instead of waiting for new events to accumulate. The amount of history you can import (3, 12, or 24 months) depends on your plan. ## Event Platform Sync The automatic connection between heyBTW and your event platform (Luma, Splash, or Zuddl). This captures attendee registrations, RSVPs, check-ins, and engagement data without manual list uploads. ## Global Prospect A target prospect account set at the workspace level. Global Prospects form your ABM target list: the companies you want to prioritize for invites, RSVPs, and partner matching across every collab you run. When a partner has a mapped relationship with a Global Prospect, heyBTW surfaces that partner as the best path to bring the account to an event. Global Prospects enable privacy-first partner collaboration. You share priority signals with partners without exposing your full customer list, and partners don't have to expose theirs. ## Influenced A deal classification. The deal already existed at or before first event attendance, so the event is credited with touching an open opportunity rather than creating it. Sales- and SDR-originated contacts who attend events are Influenced, not Sourced. Influenced is one of exactly two [Attribution](#attribution) categories, classified per deal, not per contact. [Acceleration](#acceleration) measures how much an event sped up an Influenced deal. ## Invite List Builder A pre-event [Agent](/docs/features/agents) that proposes a targeted invite list from your CRM pipeline and partner account mapping, answering "who should be in the room to maximize pipeline?" The agent proposes and you dispose. Its output is a [List](#lists), which is then the object you activate, segment, and reuse. ## Lists A reusable, filtered group of contacts drawn from the data already in your workspace. One object covers both halves of an event: who to invite beforehand, and who to follow up with afterward. Lists are **dynamic** or **static**. A dynamic list is a saved set of filters re-evaluated live, so membership changes as new RSVPs arrive and CRM records move. A static list captures a fixed selection at save time. A list's **basis** scopes where matches are drawn from, either all workspace data or a single collab. Lists can be built by hand, proposed by an [Agent](/docs/features/agents), or saved out of Partner Ecosystem account mapping. See [Lists](/docs/lists/overview). ## MCP Server heyBTW's Model Context Protocol endpoint, which lets AI agents query your [Context Graph](#context-graph) in natural language. Nine tools are live: eight read tools plus one write tool. The eight read tools are `get_workspace_overview`, `get_account_relationship`, `get_partner_insights`, `get_event_attribution`, `get_cross_event_patterns`, `get_invite_recommendations`, `get_event_details`, and `query_event_intelligence` (deprecated, being retired). They are available on all plans. The write tool is [`activate_list`](/docs/mcp-tools/activate-list), which sends a saved List's invites to its linked Luma event and requires an explicit human confirmation step. It is gated on the `agent-connections-outbound` capability. See [MCP Tools](/docs/integrations/mcp-tools). ## Multi-Event Attribution When a contact attends multiple co-marketing events before converting, heyBTW tracks the full sequence. This shows which combination of events and partners contributed to a deal, not just the last touch. ## My Partners The section of heyBTW where you manage your full partner network. View all partners, their types (multi-channel, solution, etc.), active collabs, and aggregate performance metrics. ## North-Star Stage The CRM stage your workspace defines as "the event worked," for example closed-won, demo-completed, or qualified-opportunity. Attribution is computed against your North-Star Stage, so it reflects your sales motion rather than a fixed definition imposed by heyBTW. ## Portfolio A list of companies you track against a partner without that partner onboarding to heyBTW. You upload and maintain the list yourself, and the accounts carry the **Portfolio** status in account mapping. Portfolios are how a partnership starts before there is anything mutual to map: a VC's portfolio companies, an accelerator cohort, or any partner whose account list you can assemble on your own. Invite the partner later and the mapping you already built stays. See [Partner Ecosystem Dashboard](/docs/partner-ecosystem/partner-ecosystem-dashboard). ## Partner A company that participates in a collab as a co-host or sponsor. When two or more companies co-market an event, the non-host companies are partners. Partner is a company-level concept: it represents an organization participating in your events. You manage your partners in [My Partners](#my-partners), and a partner-side user invited into a collab can view shared event details and the attribution data relevant to their organization. ## Partner Ecosystem Dashboard A high-level view of your entire partner network's performance. Shows partner rankings by pipeline influenced, active collaborations, and overall program ROI. ## Partner-Influenced Pipeline Deals where at least one contact attended a co-marketing event managed through heyBTW, and the deal already existed at or before that first attendance. The event touched someone in the buying process but did not create the deal. This follows the deterministic [Influenced](#influenced) rule: deal creation date sits at or before first attendance date. ## Partner-Sourced Pipeline Deals where a co-marketing event was the first meaningful touchpoint, meaning first attendance came before the deal was created. The event created the initial relationship that led to the deal. This follows the deterministic [Sourced](#sourced) rule. When more than one partner could claim a source, heyBTW ranks the partner-source signal in order: UTM link, then overlap data, then co-host. ## Partner Tier A permission bundle inside Sponsor Mode that controls which attendee data fields a partner can see. Tiers are custom and defined per collab by the collab creator. Common tier structures are Gold / Silver / Bronze, but tier names and the data fields each tier unlocks are fully configurable. Each partner in a collab is assigned to a tier, and the tier governs column visibility in the attendee table and which attendees the partner sees. See [Sponsor Mode](/docs/partner-ecosystem/sponsor-mode) for the full mechanics. ## Sourced A deal classification. First event attendance came before the deal was created in the CRM, and no active sales relationship existed at the account beforehand, so the event is credited with creating the relationship. An old marketing touch or mere CRM presence does not disqualify a sourced claim; an active prior sales relationship (an open opportunity or recent outbound) does. Sourced is one of exactly two [Attribution](#attribution) categories, classified per deal, not per contact. ## Sponsor Mode A partner configuration within My Partners for managing event sponsorship relationships. Includes features specific to sponsored events and sponsor-level tracking, governed by [Partner Tiers](#partner-tier). See [Sponsor Mode](/docs/partner-ecosystem/sponsor-mode) for details. ## UTM Link A link generator for building trackable registration links. heyBTW generates and organizes a link per partner per collab, tagging each with UTM parameters (`utm_source`, `utm_medium`, `utm_campaign`, and so on) so registrations can be attributed back to the partner and channel that drove them. `utm_source` is the key identifier tied to a partner. When an attendee registers through a partner's link, `utm_source` is captured on the Attendee record and feeds into Sponsor Mode attribution and the partner's funnel view. ## Workspace Your organization's home in heyBTW. A workspace contains your integrations (CRM and event platforms), your partner network, all your collabs, and your attribution data. Workspaces are scoped by business domain. When you sign up with an email address, heyBTW creates or joins a workspace based on the domain portion of your email. Anyone who later signs up with the same business domain (for example, everyone with an @acme.com email) joins the same workspace automatically. This means teammates at the same company share a workspace without needing manual invites for domain matches. Personal email providers (Gmail, Outlook, Yahoo, etc.) are excluded from domain-based joining; those users create individual workspaces. ## Workspace API Key The credential that scopes [MCP Server](#mcp-server) access to a single workspace. An agent presenting a workspace's key can only read that workspace's graph. See [MCP Tools](/docs/integrations/mcp-tools) for how to generate and use one. # Quickstart Source: https://heybtw.com/docs/getting-started/quickstart Import your events, add partners, and start seeing attendee data in minutes. ## Step 1: Sign Up Go to [heybtw.com](https://heybtw.com) and click **Sign Up**. You can sign up with Google, Microsoft, or email and password. If you already have an account, click **Log in**. Forgot your password? Use **Reset password** on the login screen. ## Step 2: Connect Your Event Platform Connect the platform you use for events. This is where your data comes from. 1. Click **Integrations** in the left sidebar. 2. Pick your platform: **Luma**, **Meetup Pro**, **Splash**, or **Zuddl**. 3. Follow the setup steps. For Luma, paste your API key. For Meetup Pro, click **Connect with Meetup**. See [Event Platforms](/docs/integrations/event-platforms) for detailed guides. Running events somewhere else, or on your own registration form? Use the [Custom Webhook](/docs/integrations/custom-webhook). Once connected, your events are imported and each event becomes a **collab** automatically. ## Step 3: Add Partners to Your Event Open a collab (your imported event) and add the partners involved. **Quick add (top right):** Click **+ Partner** and enter their domain (e.g., `stripe.com`). This gives that company access to this event only, not your other events. No email is sent. They'll see the event when they log into their own heyBTW workspace. **With invite:** Go to the **My Partners** tab in the collab. Add a partner with the option to set them as co-host and enter their email. This sends them a specific email invitation to join heyBTW. Partners you add to an event collab automatically appear in your [Partner Ecosystem Dashboard](/docs/partner-ecosystem/partner-ecosystem-dashboard). ## Step 4: Connect Your CRM (When You're Ready) CRM connection unlocks attribution, matching event attendees to your pipeline. Go to **Integrations** in the sidebar and connect **HubSpot**, **Salesforce**, or **Attio**. One CRM connects at a time. See [CRM](/docs/integrations/crm) for setup details. You don't need CRM connected to start. Many teams import events and add partners first, then connect CRM when they want attribution data. ## Step 5: Build a List A [List](/docs/lists/overview) is a reusable, filtered group of contacts. It is the object you invite from before an event and segment with after it. Click **Lists** in the sidebar, then **+ New list**. Filter on CRM status, ICP fit, RSVP status, or how many of your events someone has already attended. Dynamic lists stay current on their own as new RSVPs arrive. ## What's Next * [Set up Sponsor Mode](/docs/partner-ecosystem/sponsor-mode) to control what data sponsors can see. * [Upload your target prospect list](/docs/partner-ecosystem/partner-ecosystem-dashboard#global-prospect-list) so you know which event attendees to prioritize. * [Run AI agents](/docs/features/agents) to build invite lists from your pipeline and partner data. * [Track a partner ecosystem](/docs/partner-ecosystem/partner-ecosystem-dashboard) by uploading a portfolio, no onboarding required on their side. # Agent Quickstart Source: https://heybtw.com/docs/integrations/agent-quickstart What you can ask heyBTW from Claude, ChatGPT, or any MCP-compatible agent, grouped by intent and mapped to the underlying tool. heyBTW's MCP server is built for AI agent consumption. Once your workspace is connected, any MCP-compatible agent can query event intelligence, partner relationships, attribution, and pipeline outcomes in natural language. This page shows the patterns that work today, grouped by what an agent or its user is actually trying to do. Every query in the sections below maps to one of the eight live read tools; the ninth tool, `activate_list`, writes and is covered separately under [The one write tool](#the-one-write-tool). Setup, authentication, and tool schemas live in [MCP Tools](/docs/integrations/mcp-tools). ## Account and event intelligence * "What events has Chargebee attended in the last 6 months?" * "Show me engagement history for stripe.com." * "Which accounts have attended 3 or more events and have open pipeline?" These hit `get_cross_event_patterns`, with `get_account_relationship` for a single-account deep dive. `query_event_intelligence` also answers these and is still served, but it is deprecated and being retired (HEY-1895). Prefer the two tools above in new work. ## Partner and relationship intelligence * "Which partners have a relationship with OneTrust?" * "Who could give us a warm intro to Notion?" * "Which partners bring decision-makers versus practitioners?" These hit `get_partner_insights`. ## Attribution and pipeline impact * "Which deals can we attribute to the Berlin Fintech Dinner?" * "Show me Sourced versus Influenced pipeline from our Q1 events." * "What's the time-to-pipeline for event-sourced leads at MAU Vegas?" These hit `get_event_attribution`. When reporting the results, [represent attribution honestly](/docs/integrations/mcp-tools#representing-attribution-honestly): lead with Influenced, claim Sourced only with strong evidence, and always cite provenance. ## Planning and invite lists * "Who should we invite to our Fintech dinner in Berlin next month?" * "Build an invite list for our SaaS roundtable." * "Which accounts with open pipeline haven't been to one of our events yet?" These hit `get_invite_recommendations`. This tool scopes to **one event**, named either by `event_name` (a human-readable name, fuzzy-resolved) or by `channel_id`. Beyond naming the event it takes no targeting parameters: there is no region, vertical, partner, budget, or ROI-target filter, and no account tier to filter on. Phrasing a request as though those exist will not narrow the result — name the event, then filter or segment the returned candidates in the agent. ## Conference and multi-event reporting There is no collection-level rollup tool on this surface today. An earlier version of this page pointed these questions at `get_conference_summary`, which was never a registered tool. Answer them by calling `get_event_details` once per event in the collection and aggregating in the agent, and say so rather than implying a single deduplicated rollup was returned. * "Summarize our performance at MAU Vegas across all activations." * "Give me deduplicated attendance and ROI for our SaaStr presence." These fan out over `get_event_details`, one call per activation. ## Combine heyBTW with your CRM An agent can run heyBTW's MCP alongside your CRM's own MCP (Salesforce, HubSpot, or Attio) and join the two itself, without heyBTW ever touching your CRM data. This is how teams get pipeline-aware attribution while keeping CRM data in place. See [Join heyBTW with your CRM through MCP](/docs/integrations/mcp-tools#join-heybtw-with-your-crm-through-mcp). ## How responses are structured Every tool response includes a metadata envelope describing the data sources queried, the time range applied, the filters that were active, and a coverage note about data completeness. Agents can use this to cite their work and to flag when results are partial. When no data matches the query, tools return empty results with a clear coverage note. They do not error. Read the coverage note before treating a zero as real. ## What the agent will not see heyBTW is workspace-scoped. Every query returns only the data inside the workspace whose API key authenticated the request. Cross-company signals appear only when both sides have opted into a collaboration. Full data handling principles are in [Data Handling](/docs/concepts/data-handling). ## The one write tool Everything above is read-only. One tool on this surface is not: [`activate_list`](/docs/mcp-tools/activate-list) sends a saved List to its linked Luma event. **`activate_list` with `action="confirm"` sends real invites to real people**, and it is not idempotent. Call `action="preview"` first, present the eligible count and the named target event to the human, and send only on their explicit go-ahead. Read [when a retry is safe](/docs/mcp-tools/activate-list#when-a-retry-is-safe) before re-issuing any confirm. * "Send the Berlin dinner list to the event." → `activate_list`, preview first. * "How did the invites we sent last week land?" → `activate_list` with `action="funnel"`. Earlier versions of this page listed `push_event_data`, `confirm_enrichment`, and `update_attendee_status` here. None of the three is registered on this surface. See [MCP Tools](/docs/integrations/mcp-tools#write-tools). ## Related * [MCP Tools](/docs/integrations/mcp-tools): setup, authentication, and full tool reference. * [Context Graph Coordinates](/docs/concepts/context-graph-coordinates): the five dimensions every response can be located along. * [Data Handling](/docs/concepts/data-handling): workspace scoping, privacy, and the two-path CRM architecture. # CRM Source: https://heybtw.com/docs/integrations/crm Connect one CRM to match event attendees to your pipeline and write enriched contacts back. CRM connection is what turns event data into attribution. Without it, you see who attended. With it, you see which attendees became meetings, opportunities, and closed deals. heyBTW supports three CRMs: **HubSpot**, **Salesforce**, and **Attio**. ## One CRM at a time You can connect several event sources at once (Luma, Splash, and Zuddl together), but only **one CRM** can be connected to a workspace at a time. To switch CRMs, disconnect the current one first. heyBTW will tell you when a switch is required. For example, if HubSpot is connected and you start connecting Attio, you will see a notice that connecting Attio replaces the HubSpot integration and that you need to disconnect HubSpot first. ## What CRM sync does Across every supported CRM, the contract is the same: * **Reads deal stages.** heyBTW reads your opportunities and their stages, amounts, and close dates to compute [attribution](/docs/concepts/attribution-model). This is how event attendance connects to pipeline and revenue. * **Syncs contacts.** Enriched attendee contacts can be written back to your CRM. You control what flows back, and enrichment is additive: it fills in missing fields rather than overwriting data you already have. You connect, manage, and disconnect any integration from the **Integrations** area in the left sidebar. ## Prefer not to connect your CRM? Join through MCP You do not have to connect your CRM directly to heyBTW to get attribution. There are two ways to bring event intelligence and pipeline together: * **Connect your CRM directly** (the rest of this page). heyBTW reads your deal stages and returns attribution with pipeline values built in. * **Join through MCP, with no direct access.** Keep your CRM data exactly where it is. heyBTW exposes your event attendance and relationship intelligence through its [MCP Server](/docs/integrations/mcp-tools). Your AI agent combines that with your CRM's own MCP server, for example Salesforce or HubSpot, and does the join itself. In the MCP path, heyBTW never connects to or receives your CRM data. heyBTW provides the relationship and event-attendance layer, your CRM keeps the pipeline data, and the agent cross-references the two to produce attribution that neither system could generate alone. This is the model security-conscious teams reach for when they would rather not grant a vendor CRM access. ## When to connect You don't need a CRM connected on day one. Import events and add partners first. Connect your CRM when you're ready for attribution. ## HubSpot ### Connecting HubSpot 1. Open **Integrations** and find **HubSpot**. 2. Click **Connect** and authorize the OAuth connection. 3. You'll see **Connected** status once complete. No custom dev required. The native HubSpot app handles everything. ### What heyBTW writes heyBTW syncs **contacts** to HubSpot. Event attendees are created or matched as contacts, and enriched fields (company, title, LinkedIn, seniority, and company size) update on sync. If **MQL** is enabled, heyBTW also updates the `hs_lead_status` (Lead Status) field on contacts that qualify based on event engagement. ### What heyBTW reads heyBTW reads, but does not modify: * **Companies** for account matching. * **Deals** for pipeline attribution (stage, amount, close date, associated contacts). * **Meetings** for tracking post-event engagement. Lifecycle stage is read from HubSpot and never overwritten. ## Salesforce ### Connecting Salesforce 1. Open **Integrations** and find **Salesforce**. 2. Install the heyBTW managed package. 3. Authorize the connection. Salesforce requires admin permissions for the initial package installation. Standard user permissions are fine for ongoing sync. ### Read-only The Salesforce integration is read-only. The managed package reads: * **Contacts and Leads** for matching event attendees to CRM records. * **Accounts** for account-level matching and attribution. * **Opportunities** for event attribution, including stage, amount, and close date. * **Events/Meetings** for tracking post-event engagement. Your Salesforce instance stays untouched. ## Attio ### Connecting Attio 1. Open **Integrations** and find **Attio**. 2. Click **Connect with Attio**. You'll be redirected to Attio to authorize heyBTW. 3. Approve access, and you'll return to heyBTW with **Connected** status. If another CRM is already connected, disconnect it first. Attio cannot be connected alongside another CRM. ### What heyBTW reads and writes * **Reads deals** for event attribution (stage, value, close date, and associated people). * **Writes enriched People records**, including custom attributes, back into Attio. Matching uses email as the primary key, the same as the other CRMs. ## More integrations Need a CRM or platform that isn't listed? heyBTW adds integrations at customer request. Reach out and we'll talk through your stack. ## Troubleshooting * **Contacts not matching.** Matching uses email as the primary key. Make sure your event platform captures emails that match your CRM records. * **Deals or opportunities not appearing in attribution.** Attribution requires that contacts are associated with deals or opportunities in your CRM. If a deal has no contact associations, heyBTW can't link it to an event attendee. * **Can't connect a second CRM.** Only one CRM connects at a time. Disconnect the current CRM before connecting a new one. * **Duplicate concerns (HubSpot).** heyBTW deduplicates against existing records. If an attendee already exists in HubSpot, it matches the existing record rather than creating a new one. # Custom Webhook Source: https://heybtw.com/docs/integrations/custom-webhook Push event lead data into heyBTW from any source using a signed HTTP webhook. Not every event runs on Luma, Splash, Zuddl, or Meetup. Conference badge scans, a Typeform, a Google Form, or registration you built yourself all produce the same thing: a list of people who showed interest in an event. The Custom Webhook takes that data directly. Find it under **Integrations** in the left sidebar, then **Custom Webhook**. ## Setup ### 1. Copy your ingest URL Each workspace has its own endpoint: ``` https://heybtw.com/api/webhooks/ingest/{workspace_id} ``` The full URL, with your workspace ID already filled in, is on the Custom Webhook page. Use the copy button rather than retyping it. ### 2. Generate a webhook secret Click **Generate secret**. Until a secret exists, the endpoint does not accept leads. The secret signs every request. Store it wherever you keep credentials for the system that will be sending, and treat it like a password. ## Signing a request Every request carries two headers: | Header | Value | | -------------------- | --------------------------------------- | | `X-HeyBTW-Timestamp` | Unix timestamp in seconds, at send time | | `X-HeyBTW-Signature` | `sha256=` followed by the hex HMAC | The signature is an HMAC-SHA256 over the timestamp and the raw request body, joined by a period, keyed with your webhook secret: ``` signature_base = "{timestamp}.{raw_json_body}" signature = HMAC_SHA256(secret, signature_base) header = "sha256=" + hex(signature) ``` Sign the exact bytes you send. Re-serializing the JSON after signing changes the body and the signature will not match. ## Sending leads `POST` to your ingest URL with `Content-Type: application/json`. ```json theme={null} { "event_name": "Test Event", "source": "manual", "leads": [ { "email": "test@example.com" } ], "dry_run": true } ``` | Field | Required | Notes | | ------------ | -------- | ----------------------------------------------------------- | | `event_name` | Yes | The event these leads belong to | | `source` | Yes | Where the data came from, for example `manual` | | `leads` | Yes | Array of lead objects. `email` is the matching key | | `dry_run` | No | When `true`, validates the request without writing anything | Send `dry_run: true` first. It exercises the signature, the payload shape, and the endpoint without creating records, which makes it the right thing to wire into a staging environment or a health check. ## Example ```bash theme={null} TIMESTAMP=$(date +%s) PAYLOAD='{"event_name":"Test Event","source":"manual","leads":[{"email":"test@example.com"}],"dry_run":true}' SECRET="" SIGNATURE=$(echo -n "${TIMESTAMP}.${PAYLOAD}" | openssl dgst -sha256 -hmac "${SECRET}" | sed 's/^.* //') curl -X POST "https://heybtw.com/api/webhooks/ingest/{workspace_id}" \ -H "Content-Type: application/json" \ -H "X-HeyBTW-Signature: sha256=${SIGNATURE}" \ -H "X-HeyBTW-Timestamp: ${TIMESTAMP}" \ -d "${PAYLOAD}" ``` The Custom Webhook page shows this same snippet with your workspace ID already substituted. ## What happens next Leads arriving through the webhook behave like attendees from any other source. They can be enriched, added to [Lists](/docs/lists/overview), matched to your CRM, and counted in [Event Attribution](/docs/features/event-attribution-funnel). Email is the primary key for all of it, so a lead with no email produces a record but no attribution. ## Security notes * **Rotate the secret** if it is ever exposed. Generating a new secret invalidates the old one, so update your sender first. * **Verify over TLS only.** The endpoint is HTTPS and requests over plain HTTP are rejected. * **Never put the secret in client-side code.** Send from a server, a form backend, or an automation platform, not from a browser. ## Related * [Event Platforms](/docs/integrations/event-platforms): native integrations for Luma, Meetup Pro, Splash, and Zuddl * [Enrichment](/docs/integrations/lead-enrichment): resolve incoming leads to company, title, and seniority * [CRM](/docs/integrations/crm): connect HubSpot, Salesforce, or Attio # Event Platforms Source: https://heybtw.com/docs/integrations/event-platforms Connect Luma, Meetup Pro, Splash, or Zuddl to automatically capture attendee data. heyBTW integrates with the event platforms B2B teams actually use. Connect once, and attendee data flows in automatically for every event you link to a collab. Running events somewhere else, or on registration you built yourself? See [Custom Webhook](/docs/integrations/custom-webhook). ## Supported Platforms ### Connecting your calendar Connecting the calendar is the full integration. Events sync, guest lists sync, and new registrations keep arriving on their own. Luma Plus is required for API access. **Step 1: Get your Luma API key** 1. Go to [luma.com/calendar/manage/api-keys](https://luma.com/calendar/manage/api-keys). 2. Select the calendar you want to connect, for example your company's event calendar. 3. Copy your API key. If you don't have one yet, click **Generate**. **Step 2: Connect in heyBTW** 1. In heyBTW, click **Luma** under **Integrations** in the left sidebar. 2. Paste your API key in the **Luma API Key** field. 3. Click **Test API Key** to verify the connection. 4. Click **Save & Connect**. The page then shows **Connected Account** as Active and an **Events Synced** count from your calendar. ### Importing events Under **Available Events**, switch between **Upcoming** and **Past** and import any event as a collab. **Refresh Events** re-reads the calendar if something new isn't showing yet. Turn on **Auto-Import** to skip that step entirely. New Luma events become collabs as they appear on the calendar. Turn on **Auto-Enrich** to resolve attendees to company, title, LinkedIn, and seniority as soon as an event imports. The toggle shows your monthly credit usage. See [Enrichment](/docs/integrations/lead-enrichment). ### Import by Luma URL For co-hosted events, where the event lives on someone else's calendar, and for anyone without Luma Plus. **Step 1: Add the event to your workspace** 1. Copy the event's Luma URL. 2. In heyBTW, open **Integrations**, then **Luma**. 3. Paste the URL under **Import by Luma URL** and click **Preview**. The public event details import immediately and the event is now bound to your workspace. No guest list yet. **Step 2: Grant guest list access** In Luma, add `events@heybtw.com` as a host on the event and set the permission level to **Manager**, which is the level that includes guest list access. There is no need to display the host publicly. heyBTW then joins the guest list to the event you added and it appears in your workspace. Attendees sync from that point on, the same as any calendar-connected event. **If you skip step 2,** you keep the event details and can upload attendees by CSV. That is a working setup, just a manual one. Step 1 is what ties the event to your workspace, so do it from the workspace you want the attendees to land in. **Co-hosted events where both sides use heyBTW.** Only one workspace needs to do this. Whoever adds the Luma URL and gets `events@heybtw.com` on the event holds the collab, then adds the other company as a partner in heyBTW and that partner has access. There is no need for both sides to claim the same event. What the partner then sees is governed by [Sponsor Mode](/docs/partner-ecosystem/sponsor-mode), and it is worth a look before you invite them. Co-host access means your workspace holds the full Luma invite list, including everyone who never responded. Partner Attendee Visibility defaults to **Approved only** so that list is not shared by accident. ### Sync speed Attendee data syncs in batches of 100. For larger events or multiple events, the full sync may take up to an hour. New registrations sync automatically after the initial import. ### Connecting Meetup Pro 1. In heyBTW, click **Meetup Pro** under **Integrations** in the left sidebar. 2. Click **Connect with Meetup**. 3. Authorize heyBTW in Meetup and you'll return with the connection active. Once connected, events and attendees from your Pro network sync into heyBTW. Meetup Pro is required. Standard Meetup accounts cannot connect, because the group and member data heyBTW needs is only available on the Pro API. ### Connecting Splash 1. In heyBTW, click **Splash** under **Integrations** in the left sidebar. 2. Follow the authorization flow to connect your Splash account. 3. Select which events or event groups to sync. ### Connecting Zuddl 1. In heyBTW, click **Zuddl** under **Integrations** in the left sidebar. 2. Follow the authorization flow to connect your Zuddl account. 3. Select which events to sync. ## What Gets Captured For every synced event: * Registrations and RSVPs, with timestamps * Attendee check-ins * Contact details: name, email, company * Registration question responses, if enabled Email is the primary key for matching attendees to your CRM. An event that does not capture email produces attendance data but not attribution. ## Cross-Platform Events Your partner uses Splash, you use Luma. No problem. Both platforms sync into the same collab. Attendee data is unified regardless of which platform each side uses. ## Troubleshooting **Events not showing up.** Make sure the event is linked to a collab. Only events connected to collabs sync attendee data. On Luma, try **Refresh Events** before anything else. **Attendee data missing.** Check that your event platform captures email addresses. Email is the primary key for matching. **Luma connection fails.** Verify you have Luma Plus enabled and that the API key is from the correct calendar. Use **Test API Key** to check before saving. **Imported a Luma URL but no guests appeared.** URL import brings in the event details. Guests arrive once `events@heybtw.com` has been added to the event in Luma as a host with **Manager** permission. Check the permission level first, since anything below Manager does not include guest list access. Upload a CSV in the meantime. **Meetup won't connect.** Confirm the account is Meetup Pro. Standard accounts are rejected at the authorization step. ## Related * [Quickstart](/docs/getting-started/quickstart) * [Custom Webhook](/docs/integrations/custom-webhook): bring in events from any other source * [Lists](/docs/lists/overview): build and send invite lists to a connected event * [Enrichment](/docs/integrations/lead-enrichment): resolve attendees to company, title, and seniority * [CRM](/docs/integrations/crm): turn attendance into attribution # Enrichment Source: https://heybtw.com/docs/integrations/lead-enrichment Resolve every event attendee to a company, title, LinkedIn, and seniority before they reach your CRM. Event organizers and sponsors want to know who is actually in the room. The problem is that most event registrations come in on personal addresses. A Luma event can be 60 to 65% personal Gmail and other non-business emails, which tells you a name but not a company. Enrichment closes that gap. It takes an attendee's email and resolves their professional identity: company, title, seniority, LinkedIn profile, company size, industry, and location. That is what lets heyBTW match the person to an account and connect them to pipeline. Enrichment never adds phone numbers. ## What gets enriched For each attendee, enrichment adds: * Company name and domain * Job title and seniority * LinkedIn profile URL * Company size and industry * Location Enrichment uses a reverse email lookup. It works on business emails and resolves many personal-email registrations to a current company, which is exactly the case that simple email-domain matching would miss. No phone numbers are ever added. ## Three ways to enrich You can enrich automatically as events come in, on demand for a single event, or in one batch across everything already imported. ### Auto-enrich new events Turn on **Auto-enrich new events** and every event imported from Luma, Splash, or Zuddl is enriched automatically as RSVPs sync. It runs in the background, roughly 1 to 2 minutes per batch, and pulls new RSVPs as they arrive. Two settings control what auto-enrich touches: * **Scope.** Choose which attendees to enrich, for example **Approved only**, so you do not spend credits on registrations you have not approved. * **Skip partner contacts.** Exclude partner-side attendees. Useful when your partners' contacts are already well-covered in your CRM, and it saves credits. Per-event overrides win when set, so you can turn auto-enrich on globally and still control individual events. ### Enrich a single event You can run enrichment on one event on demand, either from the event row on the Enrichment page or from the attendee table inside the collab. heyBTW shows the number of leads and the credit cost before it runs, for example "Confirm update 47 leads, using 47 credits." After it completes, the attendee table and AI insights populate with the new data. ### Catch up on past events When you first connect a source, use **Catch up on existing events** to enrich everything already imported in one run. Past-event enrichment is a one-shot pass over historical attendee lists and takes about 1 to 2 minutes per event. This is the fastest way to make attribution work from day one rather than waiting for new events to accumulate. ## What to expect from match rates Expect 80 to 85% of attendees to resolve to a person on a typical list. Apple-relay and single-use privacy emails cannot be matched, which caps even a clean list at around 90%. The Enrichment page shows a match rate on each enriched event so you can see how a given list performed. ## Credits and billing Enrichment is metered. One credit enriches one contact. * **Free to start.** New accounts include 100 free enrichments. * **Plan allowance.** Paid plans include a monthly credit allowance that resets each cycle. The meter on the Enrichment page shows what is left before any overage applies. * **Overage.** Once you pass your monthly allowance, extra enrichments cost \$0.05 per credit, billed daily as they are used, so there are no surprise end-of-cycle spikes. * **Re-enrichment is usually free.** Re-enriching a contact within 90 days reuses the cached result at no cost. Credits are only spent when the data is genuinely refreshed. * **Enterprise.** Enterprise plans get a custom allowance and pricing. You can also buy additional credits at any time. ## How it writes to your CRM Enriched contacts sync to your CRM as **Contacts**. Company, title, LinkedIn, seniority, and company size update on sync. heyBTW is careful about what it does not touch: * **Lifecycle stage is read from your CRM and never overwritten.** * **Your custom properties are untouched** unless a funnel rule you set fires. * Enrichment is additive: it fills in missing fields rather than overwriting data you already have. ## Partner attendees Partner attendees are enriched along with everyone else by default. If your partners' contacts are already well-covered in your CRM, turn on **Skip partner contacts** per event to exclude them and save credits. ## How enrichment feeds the rest of heyBTW Once an attendee is enriched, that data is persisted and reused everywhere. * **Attribution.** Better company identification means more attendees match to CRM accounts, so more of them connect to your pipeline. * **AI Insights.** The AI Event Attendee Insights panel and the Ask heyBTW AI agent answer with full context: titles, companies, seniority, and LinkedIn profiles. * **Explorer.** Enriched identity and firmographics show up on the person and company nodes you browse in the [Context Graph Explorer](/docs/features/context-graph-explorer). * **Cross-event reuse.** Enrichment results are cached. If the same person appears at multiple events, their data carries over and you do not pay to enrich them again within the 90-day window. # MCP Tools Source: https://heybtw.com/docs/integrations/mcp-tools Connect heyBTW to Claude, ChatGPT, or any MCP-compatible agent and query your event intelligence, partner insights, and attribution programmatically. MCP (Model Context Protocol) lets you connect heyBTW to AI agents like Claude, ChatGPT, or a custom agent system. Once connected, your agent can query your event data, partner relationships, attribution, and cross-event patterns in natural language. Read tools are available on every plan, including Free. One write tool, [`activate_list`](/docs/mcp-tools/activate-list), sends real invites and is gated separately — see [Write tools](#write-tools). ## Setup ### Generate an API key 1. Click your account name in the bottom-left sidebar to open the account menu. 2. Select **API Keys**. 3. Click **Generate API Key** to create a workspace-scoped key. The key starts with `hbtw_ws_` and is tied to your workspace, not to an individual user. You can regenerate or revoke the key at any time from this page, which also shows when the key was created and last used. ### Connect your agent The API Keys page includes a ready-to-copy configuration snippet for Claude Desktop. Expand the **Connect to Claude Desktop** section and copy the JSON config block. It uses `npx mcp-remote` to reach the heyBTW MCP server with Bearer token authentication. Paste the config into your client's configuration file. For Claude Desktop: * macOS: `~/Library/Application Support/Claude/claude_desktop_config.json` * Windows: `%APPDATA%\Claude\claude_desktop_config.json` Replace `` with your actual API key. Any MCP-compatible client connects the same way: point it at the heyBTW MCP server with the key as a Bearer token. ### Restart and verify Restart your client. heyBTW tools will appear as available MCP tools in your conversations. ## Join heyBTW with your CRM through MCP This is the pattern security-conscious enterprises reach for. You do not have to connect your CRM to heyBTW at all. Instead, run two MCP servers behind your agent: heyBTW's, for event attendance and relationship intelligence, and your CRM's own MCP server (Salesforce, HubSpot, or Attio), for pipeline data. Your agent does the join. heyBTW never connects to or receives your CRM data. heyBTW supplies the relationship and event-attendance layer, your CRM keeps the pipeline, and the agent cross-references the two to produce attribution that neither system could generate alone. See [CRM](/docs/integrations/crm) for the direct-connection alternative. ## Available tools heyBTW exposes **nine tools** today: the eight read tools in this section, plus one write tool, [`activate_list`](#write-tools). All tools are workspace-scoped, meaning they only return data from your workspace. The workspace is determined by your API key, never passed as a parameter. Each tool below links to a full reference page with its complete parameter table, a real sample response, and a field-by-field breakdown — read the reference page before building a parser against a tool's output. ### [get\_workspace\_overview](/docs/mcp-tools/get-workspace-overview) Program health and agent capability discovery. Call this first in a new session — it tells you which integrations are connected and which other tools will return real data versus an empty/degraded result. * **When to use it.** "What can I ask about this workspace?" or as the first call before anything else. * **Parameters.** `date_from` (optional). ### [get\_account\_relationship](/docs/mcp-tools/get-account-relationship) Full Context Graph profile for one account: event history, contacts with seniority, warm intro paths, engagement trajectory, and CRM pipeline context. * **When to use it.** "Tell me everything about Zynga" or "Give me a profile on stripe.com." * **Parameters.** `domain` (preferred) or `account_name` — one required. `limit` (optional, default 50). ### [get\_partner\_insights](/docs/mcp-tools/get-partner-insights) Partner influence data: sourcing breakdown, seniority profile, funnel rates, and pipeline impact per partner. * **When to use it.** "Which partners have a relationship with a target account we could leverage for a warm intro?" * **Parameters.** `partner_name` (optional), `partner_domain` (optional), `include_archived` (optional, default false). ### [get\_event\_attribution](/docs/mcp-tools/get-event-attribution) Attribution data connecting events to pipeline outcomes. Classifications follow the [Attribution Model](/docs/concepts/attribution-model): every deal is [Sourced](/docs/getting-started/glossary#sourced) or [Influenced](/docs/getting-started/glossary#influenced). * **When to use it.** "Which deals can we attribute to the Berlin Fintech Dinner in March?" * **Parameters.** `event_name` or `channel_id` (both optional; either narrows to one event, omit both for all events), `date_from` (optional), `date_to` (optional). ### [get\_cross\_event\_patterns](/docs/mcp-tools/get-cross-event-patterns) Multi-event account engagement trajectories: which companies are compounding engagement, and which are cooling off. * **When to use it.** "Which accounts have attended 3 or more events?" * **Parameters.** `domain` (optional), `min_events` (optional, default 2), `limit` (optional, default 20), `include_own_domain` / `include_partner_accounts` (optional, default false). ### [get\_invite\_recommendations](/docs/mcp-tools/get-invite-recommendations) Ranked invite candidates for a specific upcoming event, drawing on ABM list membership, past attendance, and conversion history. Each candidate carries a plain-English `reasoning` string. Rank on response order: the numeric ranking scalar is withdrawn and deliberately undocumented, though contract v1 still emits it — see the [tool reference](/docs/mcp-tools/get-invite-recommendations) for exactly what is on the wire versus what to build on. * **When to use it.** "Who should we invite to this event?" once the event exists in heyBTW. * **Parameters.** `event_name` or `channel_id` (one required to name the target event), `limit` (optional, default 25), `include_own_domain` (optional, default false). ### [get\_event\_details](/docs/mcp-tools/get-event-details) The single-event deep dive: logistics and roster, attendance breakdown, seniority distribution, partner performance, top accounts, program comparison, and pipeline for one event. Meaningful before an event runs as well as after. * **When to use it.** "Give me a report on last month's Robotics Summit" or "Who's registered for next week's dinner?" * **Parameters.** `event_name` or `channel_id` (one required), `include_contacts` / `include_partner_breakdown` (optional, default false). * **Renamed.** Shipped as `get_event_summary`; renamed by HEY-2029. The old name is not registered and will not resolve. ### [query\_event\_intelligence](/docs/mcp-tools/query-event-intelligence) — deprecated Cross-event attendance grouped by company, with inline contacts. * **Deprecated, being retired** by HEY-1895 and absent from the v2 toolset (HEY-893). Still served on v1; do not build new integrations on it. Use `get_cross_event_patterns`, `get_account_relationship`, or `get_event_details` depending on the question — see [what to use instead](/docs/mcp-tools/query-event-intelligence#what-to-use-instead). * **Parameters.** `event_name` (optional), `domain` (optional), `limit` (optional, default 10), `include_own_domain` (optional, default false). An earlier version of this page also listed a `get_conference_summary` tool. It was never registered on this surface — it existed only as documentation text — so an integration built against it has nothing to call. There is no collection-level rollup on this surface today: call [`get_event_details`](/docs/mcp-tools/get-event-details) once per event in the collection. ## Response format Every tool response includes a metadata block with data provenance: which data sources were queried, what date range was applied, which filters were active, and a coverage note about data completeness. This helps the agent communicate data context to the user. When no data matches your filters, tools return empty results with a clear coverage note. They do not error. An agent should read the coverage note before concluding that something is zero, because a missing data source (for example, an Attio workspace without a deal-created date field) can limit what a query can see. ## Representing attribution honestly When an agent reports heyBTW attribution, it should phrase claims the way the model intends. Over-claiming Sourced is the fastest way to lose a sophisticated buyer. * **Lead with Influenced for in-flight pipeline.** It holds up under scrutiny, and it is safe to claim even when the source is null or owned by sales or another channel. * **Claim Sourced only with strong evidence and provenance.** Never infer Sourced from heyBTW driving the targeting, and never claim Sourced for a sales- or SDR-originated lead. If the source is unclear, the honest claim is Influenced. * **Always cite provenance.** Name the event, attendee, and timestamps behind a claim. * **Acceleration is correlation, not causation.** It is a weight on Influenced, in development today. When it ships, describe it as correlating with faster stage progression, never as having caused movement, and always pair it with the Influenced claim. See the [Attribution Model](/docs/concepts/attribution-model) for the full definitions. ## Schema stability The tool schemas and the response envelope are a stability commitment, not an implementation detail. The claim shape, dimension names, the Sourced and Influenced rule, and the exclusion rules are stable. Signal weighting nuances and partner sub-hierarchy refinements may evolve. If you build on a specific field, pin to the schema version. Schema discovery is exposed via the MCP and OpenAPI surfaces. See the [Attribution Model](/docs/concepts/attribution-model#stability) for what is stable versus what may change. Current MCP reads are workspace-scoped at the data-access boundary. The proposed versioned identity and privacy target adds opaque entity references, foreign-handle isolation, and deletion guarantees while bounding the existing `cmp_` compatibility behavior. It is documented in [MCP Standards](/docs/mcp-tools/standards). Fields described there as a target are not live until the architecture is accepted and the tool reference page names the supported response version. ## Contract versions Every tool accepts an optional `contract_version` parameter. * **Omit it.** Omission selects **v1**, and v1 is the only version advertised for every tool today. Unless you pass this parameter, v1 is what you receive. * **A newer response contract exists but is not advertised.** It is where the withdrawn scalars described on the tool reference pages are actually removed. It is deliberately not published as adoptable: it is incomplete until the opaque-identity work in [MCP Standards](/docs/mcp-tools/standards) lands, and its meaning will still change. Do not build against it. * **Any value that is not advertised may be rejected** with a structured `invalid_parameter` error. There is never a silent downgrade — you will not ask for one contract and quietly receive another. **"Withdrawn" and "absent from the response" are different claims, and the tool reference pages are careful about which one they make.** Several fields are withdrawn: `score` and the ABM priority band on `get_invite_recommendations`, `strength`/`strength_label` on `get_account_relationship`, `warmth_score` on `get_partner_insights`, and `avg_partner_warmth` on `get_workspace_overview`. Their removal is implemented in the unadvertised contract, so **v1 still emits them** and a live call today will show them. They are documented on no reference page on purpose. Seeing one in a response is not a reason to build on it. Each affected page states exactly what v1 puts on the wire versus what you should depend on. One field is genuinely gone at every version rather than withdrawn: `engagement_health` on [`get_workspace_overview`](/docs/mcp-tools/get-workspace-overview). Nothing returns it. ## Write tools One write tool is live on this surface. ### [activate\_list](/docs/mcp-tools/activate-list) Sends a saved [List](/docs/lists/overview) to its linked Luma event, behind a mandatory human confirmation round trip. * **This tool sends real invites to real people** on `action="confirm"`. It is registered `readOnlyHint=false` and `idempotentHint=false`, and both are accurate. Call `action="preview"` first, present the returned payload to a human, and only send on their explicit go-ahead. * **When to use it.** After a list-building tool such as `get_invite_recommendations` — never as the first call in a session. * **Parameters.** `action` (`preview` / `confirm` / `status` / `funnel`), `list_id`, `activation_id`, `message`, `client_request_id`, `typed_count`, `weekly_warning_acknowledged`. * **Access.** Requires a workspace-scoped key (admin and global keys are refused) and a plan including the `agent-connections-outbound` capability. Read the [full reference](/docs/mcp-tools/activate-list) before calling it, in particular [when a retry is safe](/docs/mcp-tools/activate-list#when-a-retry-is-safe). Earlier versions of this page listed `push_event_data`, `confirm_enrichment`, and `update_attendee_status` as Enterprise write tools. None of the three is registered on this surface — they are planned work, not shipped capability, and an integration built against them has nothing to call. ## Plans and access * **Free.** All eight read tools: workspace overview, account relationships, partner insights, attribution, cross-event patterns, invite recommendations, event details, and event intelligence. * **Growth.** Full MCP read access for Claude, ChatGPT, and AI assistants. * **Enterprise.** Everything in Growth, plus SSO/SAML on the MCP server. `activate_list` is gated on the `agent-connections-outbound` capability rather than on a plan tier by name. Check `get_workspace_overview` for what your workspace actually has, or ask your admin. The workspace-scoped API key (`hbtw_ws_...`) grants access to the tools your plan includes. Regenerating the key invalidates the old one immediately. ## Permissions The eight read tools are read-only and available on all plans, including Free. They query your workspace data without modifying it, and a repeated call is safe. `activate_list` is not one of them. It is a write tool whose effect leaves heyBTW entirely: `action="confirm"` sends real invites to real people through Luma. Do not reason about it as "creating or updating a record in your workspace," and do not assume a repeated call is free — see [when a retry is safe](/docs/mcp-tools/activate-list#when-a-retry-is-safe). It requires a workspace-scoped key (admin and global keys are refused) and a plan carrying the `agent-connections-outbound` capability. The API key is workspace-scoped and grants access to the tools your plan includes, so treat it like a shared credential. Admins generate and manage the key from **Account > API Keys**. ## Your workspace's domain By default, your own workspace's domain is excluded from company-level aggregation results. This prevents your own employees from skewing account-level analytics. # Lists Source: https://heybtw.com/docs/lists/overview Reusable, filtered groups of contacts. Build invite lists before an event, segment follow-up after it, and reuse both across every collab in your workspace. Lists is in preview. The **Lists** item in the left sidebar carries a PREVIEW badge while we finish the surface. A List is a saved, filtered group drawn from the contacts and accounts already in your workspace. One object serves both halves of an event: who to invite before it, and who to follow up with after it. Find Lists in the left sidebar under **Lists**. ## Dynamic vs. static Every list is one or the other, and you choose at creation. * **Dynamic.** The list is a saved set of filters, re-evaluated live. As new RSVPs arrive and CRM records change, membership changes with them. Nothing is frozen at save. * **Static.** The list captures a fixed selection at the moment you save it. Membership does not change on its own. Use dynamic for anything that should stay current, like "approved attendees with an open opportunity." Use static when you need a stable set, like the exact group you sent an invite to. The Lists page shows the split at a glance, for example **13 lists, 7 dynamic**, with **All**, **Dynamic**, and **Static** tabs above the grid. ## Creating a dynamic list Click **+ New list**. ### List name Name it after the predicate, not the occasion. `Approved · 2+ events` tells you what's inside six weeks from now. `Dinner list` does not. ### Basis **Basis** scopes where matches are drawn from. * **All workspace data.** Matches are drawn from every collab in this workspace. * **A single collab.** Pick one event from the searchable list to scope the list to its attendees. Basis is the difference between a follow-up list for one event and a list built across your whole event history. Cross-event lists are how you find the people who keep showing up, which is usually the strongest signal you have. The basis appears on the list card afterward as a **Basis:** chip. ### Filters Add filters with **+ Add filter**. **All filters must match (AND)**, so each filter you add narrows the result. **Account and CRM** | Filter | What it selects | | -------------- | ------------------------------------------------------------------ | | **CRM status** | Net-new, Prospect, Existing customer, or Unknown (no CRM match) | | **Vertical** | Your workspace verticals, configured in Partner Ecosystem settings | | **ICP fit** | | | **MQL** | | **Event signals** | Filter | What it selects | | ------------------- | --------------------------------------------------------------------- | | **RSVP status** | | | **Events attended** | | | **Enrichment** | | | **Ticket type** | Ticket tiers from the event platform, for example `Founders Pitching` | An incomplete filter blocks the save with a message naming it, for example **Complete or remove the CRM status filter to continue.** Click **Create list**. Filters read data that is already in your workspace. Adding a filter never triggers enrichment and never spends credits. ## Reading a list card Each card on the Lists page carries: * **Name and size**, counted in accounts or contacts depending on the list. * **Dynamic** or **Static**. * **Draft** while the list is still being worked on. * **Source**, showing where the list came from: Agent, ABM, Partner list, Partner Ecosystem, or manual. * **Basis**, the collab it was scoped to, if any. * **Filter chips** summarizing the predicate, for example `Attended ≥ 1 event`, `Has company`, `RSVP Approved`. * **Updated** date. Narrow the grid with the **All sources** and **All collabs** dropdowns, re-order with the sort control, or search by name. ## Where lists come from You do not have to build every list by hand. Lists arrive from four places and all of them produce the same object: * **Lists page.** Built directly, as above. * **Agents.** An agent proposes a list from your CRM and event history, and you review it before anything happens. * **Partner Ecosystem.** Click **Save as List** on a partner's account mapping view to turn the accounts you're looking at into a reusable list. * **ABM and manual upload.** Built from the account planning board, or uploaded. ## The list detail page Click any list to open it. The left side is the membership itself, with a count, a **Last checked** timestamp, and an **Update** button to re-evaluate on demand. The right side is the list's paperwork. * **Definition.** What the list actually is. A static list reads as a snapshot with the date it was saved and a note that it does not change. A dynamic list shows the filters it re-evaluates against. * **Linked to.** Every surface this list is attached to, each with a date: the collab, any ABM boards, Invite Builder, and the agent run that produced it. * **Activity.** What has been done with it, for example "Sent to attio, 5 sent, by ScaleUp Admin," with the date and the person. * **Provenance.** Where the members came from and who created the list. Provenance and Activity are the reason a list is safe to reuse months later. You can tell whether an agent built it or a person did, and whether it has already been sent somewhere, before you send it again. The **Live** toggle in the header controls whether the list keeps updating. **Export CSV** and **Archive** sit alongside it. ## Activating a list **Activate** is where a list stops being a saved query and does something. The dialog names the action and the target, for example *Activate "neo4j test upload invites" to neo4j test upload*, and splits the options in two. ### Use in heyBTW These open the list inside another surface. The list stays live, so it keeps updating while you work it. * **Invite Builder.** Work the list as an invite plan. * **ABM.** Load it onto the account planning board for the linked collab. * **Partner Ecosystem.** Work it against a partner's account mapping. This one opens from the required workspace context rather than from the dialog. ### Send externally Sending a list to an external destination is a paid feature. Working a list inside heyBTW is not. If you are on Free, you can build, filter, and use lists across Invite Builder, ABM, and Partner Ecosystem, and the send options prompt you to upgrade. * **Send Luma invites.** Beta. heyBTW calls the Luma API and Luma sends the invitation. Each recipient RSVPs themselves, so nobody lands on your guest list without acting. Luma is the sender of record, which means the invitation carries your event's branding and lives in the recipient's Luma history like any other invite. * **Add to an Attio list.** Delivers the members into an Attio list so your own sequences can enroll from it. This is a handoff, not an outreach act, and the sender of record stays your mailbox. * **Download as CSV.** For anywhere else. Each option shows how many members it would act on, and a receipt once it has run, for example "Sent 5 to attio, Jul 2." That receipt is what stops the same list being sent twice by two different people. HubSpot, Outreach, Apollo, and Splash are listed in the dialog as destinations still to come. ## Follow-up segmentation After an event, the same object becomes your follow-up routing. Build these as dynamic lists with a single-collab basis and they stay correct as CRM data moves: * **Attended and has an open opportunity.** The acceleration list. Route to the account owner. * **Attended and net-new.** The sourced list. Route to whoever works new logos. * **Registered but did not attend.** The re-invite pool for the next event. * **Partner-sourced attendees.** The co-sell list. ## Related * [Event Platforms](/docs/integrations/event-platforms): connect Luma so a list has somewhere to send * [Partner Ecosystem Dashboard](/docs/partner-ecosystem/partner-ecosystem-dashboard): account mapping and Coverage * [Event Attribution Funnel](/docs/features/event-attribution-funnel): what happened to the people you invited # activate_list Source: https://heybtw.com/docs/mcp-tools/activate-list Send a saved List to its linked Luma event. The only write tool on this surface — action=confirm sends real invites. This page documents the **Python MCP surface** (`mcp.heybtw.com`). It reflects `mcp-server/tools/activate_list.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). **This tool writes. `action="confirm"` sends real invites to real people.** It is the only non-read-only tool on this surface. It is registered with `readOnlyHint=false` and `idempotentHint=false`, and those annotations are accurate — do not treat this tool like the read tools, and do not retry a `confirm` freely. The one safe retry is narrowly defined below under [When a retry is safe](#when-a-retry-is-safe). ## Purpose `activate_list` sends a saved heyBTW [List](/docs/lists/overview) to the Luma event it is linked to, behind a mandatory human confirmation round trip. It wraps the same server-side send service as the Activate panel in the product, so eligibility rules, Luma dedupe, quota warnings, and the resulting funnel all agree with what the UI would do. This is the one action path for sending a List to Luma. For discovering who to invite in the first place, use [`get_invite_recommendations`](/docs/mcp-tools/get-invite-recommendations). ## The confirmation protocol This sequence is not a convention an agent may optimise away. Every invariant in it is re-enforced server-side, and a `confirm` that skips a step is refused. 1. **Call `action="preview"`** with the `list_id`. Nothing is sent. The response carries the eligible count, the excluded counts and their reasons, the named target event with its dates, and the workspace's trailing-7-day invite usage. 2. **Present that payload to the human** and obtain their explicit go-ahead. The preview response carries a `coverage_note` saying exactly this. Do not summarise the preview into a yes/no question that hides the target event or the count. 3. **Call `action="confirm"`** with the same `list_id` and a **fresh UUID** `client_request_id`. Two additional gates can apply, both surfaced on the preview: * **Sends over 2,500** require `typed_count` — the eligible count typed back by the human. `preview.requires_typed_count` tells you when this applies. * **A preview that exceeds the workspace's weekly reference** requires `weekly_warning_acknowledged=true`. `preview.exceeds_weekly_reference` tells you when this applies. Never call `action="confirm"` as the first call in a session, and never call it to "check whether it would work." There is no dry-run mode on `confirm`; `preview` is the dry run. ## Parameters | Name | Type | Required | Default | Description | Example | | ----------------------------- | ------------------------------------------------------ | --------------------------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------ | -------------------------- | | `action` | `"preview"` \| `"confirm"` \| `"status"` \| `"funnel"` | No | `"preview"` | Which operation to run. An unrecognised value is rejected as a structured `invalid_parameter` error. | `"preview"` | | `list_id` | string | For `preview`, `confirm`, `funnel` | `""` | The saved List to act on. | `"lst_4c19a"` | | `activation_id` | string | For `status` | `""` | The activation to report on, as returned by a `confirm`. | `"act_7d21b"` | | `message` | string | No | `""` | Optional message body accompanying the invite. | `"Hope to see you there."` | | `client_request_id` | string | For `confirm` | `""` | A fresh UUID per intended send. The server's dedupe key — see [When a retry is safe](#when-a-retry-is-safe). | `"3f2c…"` | | `typed_count` | integer \| null | For sends over 2,500 | `null` | The eligible count, typed back by the human. | `2700` | | `weekly_warning_acknowledged` | boolean | When the preview exceeds the weekly reference | `false` | Human acknowledgement of the weekly-volume warning. | `true` | Omitting a required argument for the chosen `action` is rejected as a structured `invalid_parameter` error **before** any network call, so a malformed `confirm` cannot reach the send service. ## Access requirements * **A workspace-scoped credential.** Admin and global keys are refused, on every action rather than only on `confirm` — a preview that a later confirm would refuse is a confirmation payload that can only mislead the human reading it. * **A plan including the `agent-connections-outbound` capability.** Without it the tool raises a structured `entitlement_required` error. ## Sample request ```json theme={null} { "tool": "activate_list", "arguments": { "action": "preview", "list_id": "lst_4c19a" } } ``` ## Sample response (`action="preview"`) ```json theme={null} { "tool": "activate_list", "query_time_ms": 132.5, "result_count": 1, "data": [ { "action": "preview", "result": { "status": "ok", "event_name": "Robotics Summit SF 2026", "event_starts_at": "2026-06-18T17:00:00+00:00", "event_ends_at": "2026-06-18T21:00:00+00:00", "eligible_count": 184, "excluded_count": 26, "total_count": 210, "excluded_by_reason": { "already_invited": 19, "no_consent": 5, "invalid_email": 2 }, "previously_sent_count": 19, "week_sent_count": 340, "weekly_reference": 500, "exceeds_weekly_reference": false, "requires_typed_count": false, "consent_filtered": true } } ], "metadata": { "data_sources_queried": ["List", "ListActivation", "ListActivationRecipient"], "filters_applied": { "action": "preview", "list_id": "lst_4c19a", "activation_id": "" }, "coverage_notes": [ "Nothing was sent. Present this preview to the user and obtain their explicit confirmation before calling action=confirm." ] } } ``` ## Response field reference ### Envelope | Field | Type | Description | | ------------------------- | ---------------- | ----------------------------------------------------------------------------------------------- | | `tool` | string | Always `"activate_list"`. | | `result_count` | integer | Always `1` — one action in, one result out. | | `data` | array (length 1) | `{ action, result }`. `action` echoes what you asked for; `result` is shaped per action, below. | | `metadata.coverage_notes` | array of strings | On `preview`, always carries the "nothing was sent" instruction. Empty on the other actions. | A `result` whose `status` is not `"ok"` (`invalid`, `unavailable`, `not_found`, `forbidden`) passes through as the service returned it, rather than being reworded here. ### `result` — `action="preview"` | Field | Type | Description | | ------------------------------------------------------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `event_name` / `event_starts_at` / `event_ends_at` | string | The target event, named and dated. Present it verbatim: this is what makes the human's confirmation informed. | | `eligible_count` | integer | How many recipients would be sent to. | | `excluded_count` / `total_count` | integer | Excluded and total list membership. | | `excluded_by_reason` | object | Counts keyed by exclusion reason. | | `previously_sent_count` | integer | How many were already sent to. **A count, never a roster** — recipient email addresses are deliberately not forwarded to the agent wire. | | `week_sent_count` / `weekly_reference` / `exceeds_weekly_reference` | integer, integer, boolean | The workspace's trailing-7-day usage against its reference volume. | | `requires_typed_count` | boolean | `true` when the confirm will require `typed_count`. | | `consent_filtered` | boolean | Whether consent filtering was applied. | ### `result` — `action="confirm"` | Field | Type | Description | | --------------- | ------- | --------------------------------------------------------------------------------------------------- | | `activation_id` | string | Pass to `action="status"` to follow progress. | | `state` | string | The activation's state. | | `counts` | object | Send counts. | | `idempotent` | boolean | `true` when this call matched an existing `client_request_id` and therefore did **not** send again. | ### `result` — `action="status"` | Field | Type | Description | | ------------------------------ | ------ | ---------------------------------------------------------------------- | | `activation_id` / `event_name` | string | Which activation, against which event. | | `state` | string | Send progress. | | `counts` | object | Per-recipient outcome counts (pending / submitted / failed / skipped). | ### `result` — `action="funnel"` | Field | Type | Description | | -------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------- | | `membership_mode` | string | How the List resolves membership. | | `members` / `invited` / `approved` / `no_response` | integer | The invited-to-approved funnel, from the same canonical resolver the Lists surface reads. | | `engaged_non_registrants` | integer | Engaged contacts who have not registered. | | `event_name` | string | The target event. | ## When a retry is safe **`confirm` is not idempotent in general.** The tool is registered `idempotentHint=false` on purpose: a dynamic List that has grown since the last activation re-sends the delta on a second confirm. Re-issuing a confirm with a **new** `client_request_id` is a new send, not a retry. There is exactly one safe retry, and it is bounded: * **A `confirm` that fails with `send_outcome_unknown`.** The transport failed and the send's true state is unknown. Retry with the **same** `client_request_id`. The server dedupes on that key, so the retry cannot double-send, and the response's `idempotent` field tells you whether the original had in fact landed. This is the only outcome the tool refuses to guess about, which is why it has a dedicated error rather than a generic one. Everything else — a fresh `client_request_id`, a re-run "just to be sure", a retry after a timeout you did not confirm was `send_outcome_unknown` — risks sending again. `destructiveHint` is `false` because an invite is additive and Luma dedupes repeats server-side. That is a statement about damage, not about repetition being free: a duplicate confirm still consumes the workspace's invite volume and can still put a second heyBTW-originated invite in front of a recipient. ## Errors * **`invalid_parameter`.** An unrecognised `action`, a missing per-action required argument, or a global/admin credential. Raised before any network call. * **`entitlement_required`.** The workspace's plan does not include `agent-connections-outbound`. * **`send_outcome_unknown`.** `confirm` only. See [When a retry is safe](#when-a-retry-is-safe). * **Generic sanitized error.** Every other failure, as on the read tools — see [`get_workspace_overview` — Errors](/docs/mcp-tools/get-workspace-overview#errors). ## Pagination and limits One call per invocation. No `limit` parameter, no cursor pagination. Rate limited per workspace at 30 requests/5s, 60/minute, and 1,000/day; counters are held per server instance rather than shared, so the effective ceiling scales with instance count. A 429 carries a `Retry-After` header naming the window you tripped — honor it rather than guessing a backoff. ## Related tools * [`get_invite_recommendations`](/docs/mcp-tools/get-invite-recommendations) — find candidates before building the List you activate here. * [`get_event_details`](/docs/mcp-tools/get-event-details) — check who is already registered for the target event. * [Lists](/docs/lists/overview) — how static and dynamic Lists resolve membership, which is what determines the delta a second confirm would send. # get_account_relationship Source: https://heybtw.com/docs/mcp-tools/get-account-relationship Full Context Graph profile for one account — event history, contacts, warm intro paths, and CRM pipeline context. This page documents the **Python MCP surface** (`mcp.heybtw.com`). It reflects `mcp-server/tools/account_relationship.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). ## Purpose `get_account_relationship` answers "tell me everything about this account" for a single company: every event they've attended, their contacts with seniority classification, which partners give you a warm intro path to them, an engagement trajectory, and (when HubSpot is connected) pipeline context. It is the primary AE-prep / account-research tool on this surface. ## When to use this * "What do we know about Zynga?" or "Give me a profile on stripe.com before my call." * Before drafting outreach — `warm_intro_paths` and `context_graph_summary.recommended_actions` give you a starting angle. * After [`get_cross_event_patterns`](/docs/mcp-tools/get-cross-event-patterns) surfaces an account worth investigating further. ## Parameters | Name | Type | Required | Default | Description | Example | | -------------- | ------- | ----------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------- | ------------- | | `domain` | string | One of `domain` / `account_name` required | `null` | Company domain. **Preferred** — more reliable matching than `account_name`. | `"zynga.com"` | | `account_name` | string | One of `domain` / `account_name` required | `null` | Company name, used only when `domain` is unknown. | `"Zynga"` | | `limit` | integer | No | `50` | Caps the underlying event-history row fetch (see [Pagination and limits](#pagination-and-limits)). Clamped to `[1, 500]`. | `100` | ## Default behavior At least one of `domain` or `account_name` is required — omitting both does not produce a helpful validation message today (see [Errors](#errors)). Given only `domain`, the tool returns everything on record for that account: full event history (no separate array cap beyond the `limit` used at the row level), up to the first 50 deduplicated contacts (`contacts_shown`/`contacts_total` tell you if more exist), and all warm intro paths found. Personal-email domains (`gmail.com`, `outlook.com`, etc.) are rejected up front — see [Errors](#errors) — because they cannot identify a single company. ## Sample request ```json theme={null} { "tool": "get_account_relationship", "arguments": { "domain": "lighthouserobotics.example" } } ``` ## Sample response ```json theme={null} { "tool": "get_account_relationship", "query_time_ms": 61.4, "result_count": 1, "data": [ { "domain": "lighthouserobotics.example", "company": "Lighthouse Robotics", "trajectory": "increasing", "event_history": [ { "event_name": "Robotics Summit SF 2026", "channel_id": "chn_88af1", "event_date": "2026-06-18T00:00:00+00:00", "role": "partner_sourced", "attendee_count": 3, "mql": true, "opportunity": true }, { "event_name": "Automation Roundtable Q1", "channel_id": "chn_71c02", "event_date": "2026-02-04T00:00:00+00:00", "role": "attendee", "attendee_count": 1, "mql": true, "opportunity": false } ], "contacts": [ { "email": "priya.nair@lighthouserobotics.example", "name": "Priya Nair", "title": "VP of Product", "seniority": "director_plus", "funnel_status": "opportunity" }, { "email": "sam.oduya@lighthouserobotics.example", "name": "Sam Oduya", "title": "Senior Software Engineer", "seniority": "individual_contributor", "funnel_status": "mql" } ], "contacts_total": 2, "contacts_shown": 2, "warm_intro_paths": [ { "partner_name": "Northwind Ventures", "event_name": "Robotics Summit SF 2026", "intro_basis": "co-attended event", "path_count": 3 } ], "context_graph_summary": { "narrative": "Lighthouse Robotics has attended 2 event(s). 1 senior contact(s) engaged (e.g. director_plus level). Warm intro paths via: Northwind Ventures. $0 pipeline identified (open).", "trajectory": "increasing", "recommended_actions": [ "Prioritise for next event invite", "Request intro via Northwind Ventures", "Check CRM for open opportunities" ] }, "agent_guidance": { "crm_join_key": "domain", "crm_enriched": true, "suggested_follow_up": ["Check HubSpot for open opportunities"] }, "pipeline": { "company": "Lighthouse Robotics", "revenue": 0.0, "is_won": false } } ], "metadata": { "data_sources_queried": ["EventSignUp", "Channel", "EventAttributionOpportunity"], "date_range_applied": null, "filters_applied": { "domain": "lighthouserobotics.example", "account_name": null, "crm_enriched": true }, "coverage_note": null } } ``` ## Response field reference ### Envelope | Field | Type | Description | | --------------- | --------------------- | --------------------------------------------------------------------------------------------------------------- | | `tool` | string | Always `"get_account_relationship"`. | | `query_time_ms` | number | Server-side execution time in ms. | | `result_count` | 0 \| 1 | `0` when the account has no event attendance on record, or the `domain` given is a personal-email provider. | | `data` | array (length 0 or 1) | The account object. | | `metadata` | object | See [Response format](/docs/integrations/mcp-tools#response-format). `coverage_note` explains a `0`-result response. | ### `data[0]` | Field | Type | Description | | ------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `domain` | string | Resolved company domain — prefers enrichment-resolved value over the raw input. | | `company` | string | Resolved display name — prefers enrichment over self-reported over `account_name` input, falls back to `"Unknown"`. | | `trajectory` | `"new"` \| `"increasing"` \| `"stable"` \| `"decreasing"` | Engagement direction over the account's event history. | | `event_history` | array of objects | One entry per distinct event, newest first. Each: `{ event_name, channel_id, event_date, role, attendee_count, mql, opportunity }`. `role` is `"attendee"`, `"partner"`, or `"partner_sourced"`. `attendee_count` counts this account's own attendees at that event, not total event attendance. | | `contacts` | array of objects | Up to 50 deduplicated contacts: `{ email, name, title, seniority, funnel_status }`. `seniority` ∈ `executive` \| `director_plus` \| `manager` \| `individual_contributor` \| `unknown`. `funnel_status` ∈ `opportunity` \| `meeting_booked` \| `mql` \| `registered`. | | `contacts_total` | integer | Total deduplicated contacts found (may exceed 50). | | `contacts_shown` | integer | `min(contacts_total, 50)` — how many are actually in the `contacts` array. | | `warm_intro_paths` | array of objects | `{ partner_name, event_name, intro_basis, path_count }`. Grouped by (partner, event) pair. Judge a path on `intro_basis` and `path_count` — see the version note below for what else is on the wire. | | `context_graph_summary.narrative` | string | Human-readable one-paragraph summary, generated server-side — not an LLM call, template-composed from the fields above. | | `context_graph_summary.recommended_actions` | array of strings | Up to 3 suggested next steps, derived server-side from the account's engagement history and which data is present. | | `agent_guidance.crm_join_key` | string | Always `"domain"` — the field to join against your CRM's own Account/Company record. | | `agent_guidance.crm_enriched` | boolean | Mirrors whether HubSpot is connected for this workspace. | | `pipeline` | object \| omitted | Present **only** when CRM is connected AND a matching pipeline record exists. `{ company, revenue, is_won }`. Omitted entirely otherwise — do not assume it is `null`; check for key presence. | **The sample above is not a verbatim capture. `warm_intro_paths` entries carry more on the wire than it shows.** Contract v1 is the default — omit `contract_version` and v1 is what you get — and a v1 intro path additionally carries `strength` (a float, one of `0.9` / `0.58` / `0.38`) and `strength_label` (`"strong"` / `"medium"` / `"light"`). Contract v2 replaces both with a `reasons` array carrying the observed facts the tier was derived from. v2 is defined but **not advertised**, so v1 is what a live call returns today. Both are withdrawn (HEY-1897): `strength` was an invented float and `strength_label` a claim-like tier. They are documented nowhere on this page on purpose. Judge a path on `intro_basis` and `path_count`, and migrate to `reasons` when v2 is advertised. ## Errors * **Missing both `domain` and `account_name`.** Raised as a registered `invalid_parameter` error (issue `required`, action `provide`) before any lookup runs — an actionable structured error, not the generic sanitized one. Always pass one of the two. * **`domain` is a personal-email provider** (e.g. `gmail.com`). This is handled explicitly and does **not** error — it returns `result_count: 0` with `metadata.coverage_note` explaining that a personal-email domain cannot identify one company, and suggesting `account_name` instead. * All other failures funnel through the same generic sanitized error as every tool — see [`get_workspace_overview` — Errors](/docs/mcp-tools/get-workspace-overview#errors) and [MCP Tools — Errors and troubleshooting](/docs/integrations/mcp-tools). ## Pagination and limits No cursor-based pagination. `limit` (default 50, clamped to `[1, 500]`) bounds the underlying event-attendance row fetch used to build `event_history` and `contacts` — it is not a direct cap on the number of events or contacts returned (those are built by grouping/deduplicating the fetched rows). `contacts` is separately hard-capped to the first 50 after dedup regardless of `limit`; use `contacts_total` to know if you're seeing everything. ## Related tools * [`get_cross_event_patterns`](/docs/mcp-tools/get-cross-event-patterns) — find candidate accounts before profiling one in depth here. * [`get_partner_insights`](/docs/mcp-tools/get-partner-insights) — the partner-centric view of the same warm-intro relationships. * [`get_event_details`](/docs/mcp-tools/get-event-details) — the event-centric view; use it to see everyone at an event, not just one account. # get_cross_event_patterns Source: https://heybtw.com/docs/mcp-tools/get-cross-event-patterns Multi-event account engagement trajectories — which companies are deepening engagement across your events over time. This page documents the **Python MCP surface** (`mcp.heybtw.com`). It reflects `mcp-server/tools/cross_event_patterns.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). ## Purpose `get_cross_event_patterns` groups event attendance by account (domain) and returns each account's full event history with a computed engagement trajectory — `increasing`, `stable`, `decreasing`, or `new`. It's the tool for "who's compounding engagement across our program," not just "who came to one event." ## When to use this * "Which accounts have attended 3+ events and are still open pipeline?" * Identifying accelerating accounts for a targeted follow-up or invite campaign — feed the output into [`get_account_relationship`](/docs/mcp-tools/get-account-relationship) for the ones worth a deeper look. * Any account-trajectory question. This is the **only** tool that classifies trajectories. `get_workspace_overview` used to carry an `engagement_health` rollup; HEY-1913 removed it precisely because it diverged from this tool, so route those questions here. ## Parameters | Name | Type | Required | Default | Description | Example | | -------------------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | `domain` | string | No | `null` | Filter to accounts whose domain contains this substring. | `"lighthouse"` | | `min_events` | integer | No | `2` | Only include accounts with at least this many distinct events attended. | `3` | | `limit` | integer | No | `20` | Max accounts returned. Clamped to `[1, 500]`. | `50` | | `include_own_domain` | boolean | No | `false` | Include the calling workspace's own domain (normally excluded as "not a customer/prospect"). | `true` | | `include_partner_accounts` | boolean | No | `false` | Include accounts identified as one of your own partner organizations (their staff attending co-hosted events otherwise inflates engagement signals). | `true` | ## Default behavior Called with no parameters, returns up to 20 accounts with **2 or more** distinct events attended, sorted by event count descending then most-recent activity, excluding the workspace's own domain and any known partner domains. This is the single most consequential default to know: an account with exactly 1 event attended will **never** appear unless you pass `min_events: 1`. ## Sample request ```json theme={null} { "tool": "get_cross_event_patterns", "arguments": { "min_events": 2, "limit": 20 } } ``` ## Sample response ```json theme={null} { "tool": "get_cross_event_patterns", "query_time_ms": 55.1, "result_count": 1, "data": [ { "company": "Lighthouse Robotics", "domain": "lighthouserobotics.example", "account_role": "external", "events": [ { "event_name": "Automation Roundtable Q1", "channel_id": "chn_71c02", "event_date": "2026-02-04T00:00:00+00:00", "attendee_count": 1, "checked_in_count": 1, "mql": true, "opportunity": false }, { "event_name": "Robotics Summit SF 2026", "channel_id": "chn_88af1", "event_date": "2026-06-18T00:00:00+00:00", "attendee_count": 3, "checked_in_count": 3, "mql": true, "opportunity": true } ], "total_events": 2, "first_seen": "2026-02-04T00:00:00+00:00", "last_seen": "2026-06-18T00:00:00+00:00", "trajectory": "increasing" } ], "metadata": { "data_sources_queried": ["Channel", "EventSignUp"], "date_range_applied": null, "filters_applied": { "domain": null, "min_events": 2, "limit": 20, "include_partner_accounts": false }, "coverage_note": "3 partner account(s) excluded from patterns (their staff attend co-hosted events, which inflates engagement signals — HEY-1735). Pass include_partner_accounts=true to include them, labeled account_role='partner'." } } ``` ## Response field reference ### Envelope | Field | Type | Description | | ------------------------ | -------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | `tool` | string | Always `"get_cross_event_patterns"`. | | `result_count` | integer | Number of accounts returned (after `min_events` filter, `limit` cap, and partner exclusion). | | `data` | array | One object per qualifying account. | | `metadata.coverage_note` | string \| null | Non-null when one or more partner accounts were excluded by the default `include_partner_accounts=false` — tells you how many and why. | ### `data[i]` | Field | Type | Description | | -------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `company` | string | Resolved display name for the account. | | `domain` | string \| null | Account's grouping domain (enrichment-resolved where available). | | `account_role` | `"partner"` \| `"external"` \| `null` | Classification against your own Partner list. `null` only in `is_global` (cross-workspace admin) mode, which is not reachable via the standard workspace-scoped API key. | | `events` | array of objects | Chronological (oldest first): `{ event_name, channel_id, event_date, attendee_count, checked_in_count, mql, opportunity }`. `attendee_count` is this account's headcount at that event; `mql`/`opportunity` are `true` if **any** attendee from this account hit that signal at that event. | | `total_events` | integer | `events.length`. | | `first_seen` / `last_seen` | string (ISO 8601) \| null | Bounds of this account's event history in the workspace. | | `trajectory` | `"new"` \| `"increasing"` \| `"stable"` \| `"decreasing"` | `"new"` if fewer than 2 events; otherwise compares MQL/opportunity signal density in the first half of the account's event history vs. the second half. | ## Errors Same generic-sanitized-error behavior as every tool on this surface — see [`get_workspace_overview` — Errors](/docs/mcp-tools/get-workspace-overview#errors). No parameter here can trigger a validation failure; an unmatched `domain` filter simply returns `result_count: 0` with no `coverage_note`. ## Pagination and limits No cursor-based pagination. `limit` (default 20, clamped to `[1, 500]`) caps the number of accounts returned, applied server-side after sorting by event count then recency — there is no way to fetch "the next 20" beyond raising `limit`. If you need a specific account regardless of rank, use the `domain` filter or call [`get_account_relationship`](/docs/mcp-tools/get-account-relationship) directly. ## Related tools * [`get_account_relationship`](/docs/mcp-tools/get-account-relationship) — full profile for one account this tool surfaces. * [`get_workspace_overview`](/docs/mcp-tools/get-workspace-overview) — program orientation and integration status. It no longer carries a trajectory rollup of its own (HEY-1913 removed `engagement_health`), and its `suggested_first_queries` routes trajectory questions here. * [`query_event_intelligence`](/docs/mcp-tools/query-event-intelligence) — a lighter-weight, contact-inclusive alternative when you want attendee detail, not trajectory classification. **Deprecated and being retired (HEY-1895)** — prefer this tool or [`get_account_relationship`](/docs/mcp-tools/get-account-relationship) in new work. # get_event_attribution Source: https://heybtw.com/docs/mcp-tools/get-event-attribution Sourced/influenced pipeline attribution per event, with an optional program-level cost-per-meeting rollup. This page documents the **Python MCP surface** (`mcp.heybtw.com`). It reflects `mcp-server/tools/event_attribution.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). ## Purpose `get_event_attribution` returns one row per event with signup/MQL/opportunity/meeting counts and, when HubSpot is connected, pipeline revenue broken down as [Sourced vs. Influenced](/docs/concepts/attribution-model) per company and per partner. All revenue figures come from heyBTW's canonical attribution resolver — the same numbers the in-app Funnel and Attribution dashboards show, never re-derived independently. ## When to use this * "Which deals can we attribute to the Berlin Fintech Dinner in March?" * Comparing event ROI across a date range, especially alongside `program_summary.cost_per_meeting` for paid events. * Read [Representing attribution honestly](/docs/integrations/mcp-tools#representing-attribution-honestly) before an agent reports these numbers to an end user — Sourced is a stronger claim than Influenced and should not be over-asserted. ## Parameters | Name | Type | Required | Default | Description | Example | | ------------ | ---------------------- | -------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | `event_name` | string | No | `""` | Restrict to a single event by its human-readable name. Case-insensitive; partial and close matches resolve. An ambiguous name returns the matching candidates with their `channel_id`s instead of data. | `"Robotics Summit"` | | `channel_id` | string | No | `null` | Restrict to a single event by id. The programmatic override; **takes precedence** when both are given. Omit both for all events. | `"chn_88af1"` | | `date_from` | string (ISO 8601 date) | No | `null` | Only include events starting on/after this date. | `"2026-01-01"` | | `date_to` | string (ISO 8601 date) | No | `null` | Only include events starting on/before this date. | `"2026-06-30"` | ## Default behavior Called with no parameters, returns **every** event in the workspace, sorted newest-first, with no result cap. When HubSpot is not connected, every row still returns (signup/MQL/meeting counts are always available) but omits `pipeline`, `attribution_breakdown`, and `partner_attribution` entirely — check `crm_enriched` per row before expecting those keys. ## Sample request ```json theme={null} { "tool": "get_event_attribution", "arguments": { "date_from": "2026-01-01" } } ``` ## Sample response ```json theme={null} { "tool": "get_event_attribution", "query_time_ms": 118.6, "result_count": 1, "data": [ { "event_name": "Robotics Summit SF 2026", "channel_id": "chn_88af1", "event_date": "2026-06-18T00:00:00+00:00", "total_signups": 210, "mql_count": 34, "opportunity_count": 9, "meeting_booked_count": 14, "partner_sourced_count": 68, "conversion_rate": 0.1619, "partner_sourced_pct": 0.3238, "crm_enriched": true, "pipeline": { "sourced_revenue": 128400.0, "won_revenue": 42000.0, "company_count": 19 }, "attribution_breakdown": [ { "company": "Lighthouse Robotics", "domain": "lighthouserobotics.example", "revenue": 38000.0, "is_won": false, "attribution_type": "sourced" }, { "company": "Vantage Fields Inc", "domain": "vantagefields.example", "revenue": 12500.0, "is_won": true, "attribution_type": "influenced" } ], "partner_attribution": [ { "partner": "direct", "sourced_revenue": 128400.0, "won_revenue": 42000.0, "company_count": 19 } ] } ], "metadata": { "data_sources_queried": ["Channel", "EventSignUp", "EventAttributionOpportunity"], "date_range_applied": "2026-01-01 to now", "filters_applied": { "channel_id": null, "date_from": "2026-01-01", "date_to": null, "crm_enriched": true }, "coverage_note": null }, "program_summary": { "cost_per_meeting": { "total_invested_usd": 24000.0, "paid_event_count": 3, "meetings_from_paid_events": 31, "cost_per_meeting_usd": 774.19 } } } ``` ## Response field reference ### Envelope | Field | Type | Description | | ----------------------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tool` | string | Always `"get_event_attribution"`. | | `result_count` | integer | Number of events returned. | | `data` | array | One object per event. | | `program_summary` | object \| **omitted** | Present only when at least one paid event with cost data exists in the filtered range. **This is the one place `program_summary` appears across all nine tools** — check for key presence, don't assume `null`. | | `metadata.date_range_applied` | string \| null | Human-readable range, e.g. `"2026-01-01 to now"`, or `null` if neither `date_from` nor `date_to` was given. | | `metadata.coverage_note` | string \| null | `"Connect HubSpot CRM to unlock pipeline values"` when CRM is not connected. | ### `data[i]` | Field | Type | Description | | ------------------------------------------------------------------------------------------------------ | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event_name` / `channel_id` / `event_date` | string | Event identity. | | `total_signups` / `mql_count` / `opportunity_count` / `meeting_booked_count` / `partner_sourced_count` | integer | Funnel counts for the event. | | `conversion_rate` | number (0–1) | `mql_count / total_signups`, `0.0` if no signups. | | `partner_sourced_pct` | number (0–1) | `partner_sourced_count / total_signups`. | | `crm_enriched` | boolean | `true` only when CRM is connected **and** the attribution resolver successfully returned data for this call — a resolver timeout degrades every row's `crm_enriched` to `false`, indistinguishable from "CRM not connected" in the row itself (the top-level `metadata.coverage_note` is your only signal to tell the two apart, and only fires for the "not connected" case — a resolver-timeout degrade is currently silent at the row level). | | `pipeline` | object, present iff `crm_enriched` | `{ sourced_revenue, won_revenue, company_count }`. `sourced_revenue` here is `sourcedPipeline + influencedPipeline` combined (a naming legacy — despite the field name, it is NOT sourced-only; use `attribution_breakdown[].attribution_type` for the actual sourced/influenced split per company). | | `attribution_breakdown` | array, present iff `crm_enriched` | One entry per company with attributed revenue at this event: `{ company, domain, revenue, is_won, attribution_type }`. `attribution_type` ∈ `"sourced"` \| `"influenced"` \| `null`. `domain` may be `null` when unresolved. Deduplicated by company. | | `partner_attribution` | array, present iff `crm_enriched` | Revenue grouped by partner: `{ partner, sourced_revenue, won_revenue, company_count }`. **Current limitation:** the canonical attribution resolver does not expose which partner sourced each deal, so every row's revenue is bucketed under a single `partner: "direct"` entry today — this array does not yet reflect real per-partner pipeline splits. Use [`get_partner_insights`](/docs/mcp-tools/get-partner-insights)`.pipeline_impact` for a partner-accurate revenue figure instead. | ### `program_summary.cost_per_meeting` (top-level, sibling of `data`) | Field | Type | Description | | --------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `total_invested_usd` | number \| null | Total event cost across paid events in the filtered range. | | `paid_event_count` | integer | Number of events with cost data. | | `meetings_from_paid_events` | integer | Meetings booked at those paid events. | | `cost_per_meeting_usd` | number \| null | `total_invested_usd / meetings_from_paid_events`. `null` means "not applicable," never `$0` or `Infinity` — sourced verbatim from the canonical resolver, not recomputed here. | ## Errors Same generic-sanitized-error behavior as every tool on this surface — see [`get_workspace_overview` — Errors](/docs/mcp-tools/get-workspace-overview#errors). An unmatched `channel_id` returns `result_count: 0`, not an error. ## Pagination and limits No caller-facing `limit` parameter and no cursor pagination — every matching event is returned. Internally the row fetch is capped at 500 events (a fixed server-side safety limit), well beyond any workspace's event count today. ## Related tools * [`get_event_details`](/docs/mcp-tools/get-event-details) — single-event deep dive (attendance, seniority, partner performance) with the same `pipeline` shape for one `channel_id`. * [`get_partner_insights`](/docs/mcp-tools/get-partner-insights) — the accurate per-partner revenue figure that `partner_attribution` cannot yet provide. * [`get_workspace_overview`](/docs/mcp-tools/get-workspace-overview) — `program_metrics.attribution_summary` is a workspace-wide, all-time rollup from the same resolver. # get_event_details Source: https://heybtw.com/docs/mcp-tools/get-event-details Comprehensive report for a single event — logistics, roster, attendance breakdown, seniority, partner performance, top accounts, and CRM pipeline. This page documents the **Python MCP surface** (`mcp.heybtw.com`). It reflects `mcp-server/tools/event_details.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). **Renamed.** This tool shipped as `get_event_summary` and was renamed to `get_event_details` by HEY-2029: "summary" read as retrospective-only, which this tool never was — it answers pre-event questions like roster and capacity just as well as post-event ones. `get_event_summary` is **not** a registered tool name and a call using it will not resolve. The response envelope's `tool` field is `"get_event_details"`. ## Purpose `get_event_details` is the single-event deep dive: logistics and roster, attendance broken into host/partner/external, seniority distribution, per-partner sourcing performance, top engaged accounts, how this event compares to the workspace's own program average, and (when HubSpot is connected) pipeline attribution for this one event. ## When to use this * "Give me a report on last month's Robotics Summit." * Before an event runs, to see who is registered and how the roster is filling against capacity. * Immediately after an event, to compare it against `program_comparison` and decide whether to repeat the format. * Before [`get_invite_recommendations`](/docs/mcp-tools/get-invite-recommendations) for a similar upcoming event, to see who attended last time. ## Parameters | Name | Type | Required | Default | Description | Example | | --------------------------- | ------- | -------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | `event_name` | string | One of the two | `""` | The human-readable event name. Case-insensitive; partial and close matches resolve. An ambiguous name returns the matching candidates with their `channel_id`s **instead of** event data, so you can re-call with a specific one. | `"Robotics Summit"` | | `channel_id` | string | One of the two | `""` | The event's channel id. The programmatic override for pipelines that already resolved an id; **takes precedence** when both are given. | `"chn_88af1"` | | `include_contacts` | boolean | No | `false` | Include the full attendee contact list. Adds `contacts`/`contacts_total`/`contacts_shown`/`contacts_raw_total` to the response. | `true` | | `include_partner_breakdown` | boolean | No | `false` | Include per-partner sourcing performance (`partner_performance`). | `true` | This tool needs one specific event, named either way. Supply `event_name` or `channel_id`; supplying neither is rejected before any lookup runs (see [Errors](#errors)). Both have a `""` default at the function signature level, so an omitting call does not raise a Python-level type error. ## Default behavior Given one event identifier, returns the full logistics/attendance/funnel/seniority/top-accounts/comparison report **without** the attendee-level contact list and **without** the partner performance breakdown — both are opt-in via their respective flags, keeping the default response smaller for the common "just show me the numbers" case. ## Sample request ```json theme={null} { "tool": "get_event_details", "arguments": { "channel_id": "chn_88af1", "include_partner_breakdown": true } } ``` ## Sample response ```json theme={null} { "tool": "get_event_details", "query_time_ms": 96.7, "result_count": 1, "data": [ { "event_name": "Robotics Summit SF 2026", "channel_id": "chn_88af1", "event_date": "2026-06-18T00:00:00+00:00", "event_context": { "location": "San Francisco, CA", "format": "in_person", "timezone": "America/Los_Angeles", "capacity": 250, "meeting_url": null, "visibility": "public" }, "attendance": { "total": 210, "breakdown": { "host": 12, "partner": 68, "external": 130 } }, "funnel": { "mql_count": 34, "opportunity_count": 9, "meeting_count": 14, "conversion_rate": 0.1619 }, "seniority_distribution": { "executive": 18, "director_plus": 47, "manager": 62, "individual_contributor": 71, "unknown": 12 }, "partner_performance": [ { "partner_name": "Northwind Ventures", "sourced_count": 22, "mql_count": 6, "conversion_rate": 0.2727 } ], "top_accounts": [ { "domain": "lighthouserobotics.example", "company": "Lighthouse Robotics", "attendee_count": 3, "mql": true, "opportunity": true } ], "program_comparison": { "vs_program_avg_signups": 1.34, "vs_program_avg_mql": 1.12 }, "pipeline": { "crm_enriched": true, "sourced_revenue": 38000.0, "won_revenue": 0.0, "company_count": 4 } } ], "metadata": { "data_sources_queried": ["Channel", "EventSignUp", "Partner", "EventAttributionOpportunity"], "date_range_applied": null, "filters_applied": { "channel_id": "chn_88af1", "include_contacts": false, "include_partner_breakdown": true, "crm_enriched": true }, "coverage_note": null } } ``` ## Response field reference ### Envelope | Field | Type | Description | | -------------- | ---------------- | ----------------------------- | | `tool` | string | Always `"get_event_details"`. | | `result_count` | integer | Always `1` on success. | | `data` | array (length 1) | The event report object. | ### `data[0]` | Field | Type | Description | | ------------------------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event_name` / `channel_id` / `event_date` | string | Event identity. | | `event_context` | object | `{ location, format, timezone, capacity, meeting_url, visibility }`. `format` is derived: `"hybrid"` (has both location and meeting URL), `"virtual"` (meeting URL only), `"in_person"` (location only), `"unknown"` (neither). | | `attendance.total` | integer | Total attendees. | | `attendance.breakdown` | object | `{ host, partner, external }` counts — classified per attendee by email domain against the workspace's own domain and its partners' domains. | | `funnel` | object | `{ mql_count, opportunity_count, meeting_count, conversion_rate }`. `conversion_rate` = `mql_count / attendance.total`. | | `seniority_distribution` | object | Attendee count per tier: `executive`, `director_plus`, `manager`, `individual_contributor`, `unknown`. | | `partner_performance` | array \| `[]` when not requested | `{ partner_name, sourced_count, mql_count, conversion_rate }` per partner, sorted by `sourced_count` descending. Only populated when `include_partner_breakdown: true` — otherwise always `[]`, not omitted. | | `top_accounts` | array (up to 10) | External domains ranked by opportunity → MQL → attendee count: `{ domain, company, attendee_count, mql, opportunity }`. Excludes the workspace's own domain. | | `program_comparison.vs_program_avg_signups` / `.vs_program_avg_mql` | number \| null | This event's count ÷ the workspace's own historical average across all its events. `null` when the workspace average is `0` (e.g. this is the first event). A value of `1.34` means "34% above average." | | `pipeline` | object \| **omitted** | Present only when CRM is connected **and** the attribution resolver returned matching data for this channel. Same shape as [`get_event_attribution`](/docs/mcp-tools/get-event-attribution)'s per-event `pipeline` block. | | `crm_enriched` | boolean, **only present when `pipeline` is absent** | `false`, explaining why there's no `pipeline` block. When `pipeline` IS present, this top-level `crm_enriched` key does not appear — check for `pipeline`'s presence first, not this flag. | | `contacts` | array, present iff `include_contacts: true` | Up to 200 deduplicated contacts: `{ email, name, title, company, context, seniority, funnel_status }`. `context` ∈ `"host"` \| `"partner"` \| `"external"`. | | `contacts_total` / `contacts_shown` | integer, present iff `include_contacts: true` | `contacts_shown` capped at 200. | | `contacts_raw_total` | integer, present iff `include_contacts: true` | Pre-dedup attendee count — useful to see how much deduplication happened. | ## Errors * **Neither `event_name` nor `channel_id` supplied.** Rejected before any lookup runs with a structured `invalid_parameter` error carrying an issue of `required` and an action of `provide`. This is a real structured error, not the generic sanitized one — an agent can act on it by supplying an identifier and re-calling. * **`channel_id` is malformed.** Validated before any lookup runs and rejected as a structured `invalid_parameter` error. * **`channel_id` refers to a nonexistent or out-of-workspace channel.** The tool raises `ValueError(f"Channel {channel_id!r} not found in workspace {workspace_id!r}")` internally, but like every tool on this surface, that specific message does **not** reach the client — it's caught by the generic handler and surfaces as `RuntimeError: Internal error executing get_event_details (error_id=...)`. There is currently no way for an agent to distinguish "channel not found" from any other internal failure from the error message alone. * **`event_name` matches more than one event.** Not an error. The response carries the matching candidates with their `channel_id`s instead of event data; re-call with the `channel_id` you want. ## Pagination and limits Not applicable to the report itself — one event in, one report out. `contacts` (when requested via `include_contacts`) is capped at 200 with no further pagination; use `contacts_raw_total`/`contacts_total` to know if you're seeing everyone. ## Related tools * [`get_event_attribution`](/docs/mcp-tools/get-event-attribution) — the same event's pipeline numbers in the multi-event comparison shape, plus sourced/influenced breakdown by company. * [`get_partner_insights`](/docs/mcp-tools/get-partner-insights) — a given partner's performance across **all** events, not just this one. * [`get_invite_recommendations`](/docs/mcp-tools/get-invite-recommendations) — who to invite to a similar future event. # get_invite_recommendations Source: https://heybtw.com/docs/mcp-tools/get-invite-recommendations Invite candidates for an upcoming event, with human-readable reasoning per account. This page documents the **Python MCP surface** (`mcp.heybtw.com`). It reflects `mcp-server/tools/invite_recommendations.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). ## Purpose `get_invite_recommendations` ranks companies as invite candidates for a specific event (identified by `channel_id`), drawing on ABM list membership, past event attendance, and historical conversion signals (opportunity/MQL/meeting). Each candidate carries a plain-English `reasoning` string naming the factors that surfaced it. ## When to use this * "Who should we invite to our upcoming event?" once the event exists in heyBTW as a channel. * Building or refreshing an invite list from ABM + attendance history rather than starting from a blank spreadsheet. Despite the name suggesting event-attribute targeting, this tool targets **one event** and nothing else. There is no `region`, `vertical`, `partners`, or budget/ROI parameter, and no account-tier filter. Name the event, then filter or segment the returned candidates in your agent. ## Parameters | Name | Type | Required | Default | Description | Example | | -------------------- | ------- | -------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- | | `event_name` | string | One of the two | `""` | The human-readable event name. Case-insensitive; partial and close matches resolve. An ambiguous name returns the matching candidates with their `channel_id`s instead of data, so you can re-call with a specific one. | `"Fintech Dinner Berlin"` | | `channel_id` | string | One of the two | `""` | The target event's channel id. The programmatic override for pipelines that already resolved an id; **takes precedence** when both are given. | `"chn_88af1"` | | `limit` | integer | No | `25` | Max candidates returned. Clamped to `[1, 500]`. | `50` | | `include_own_domain` | boolean | No | `false` | Include the workspace's own domain in results. | `true` | Name the event either way. `event_name` is the human-facing resolver; `channel_id` is the programmatic one. Both default to `""` at the function signature level, so a call omitting both does not raise a Python-level type error, but it cannot identify a target event and will not produce recommendations. ## Default behavior Given one event identifier, returns up to 25 candidates, strongest candidate first, excluding companies already signed up for that event and excluding the workspace's own domain. `metadata.coverage_note` always states the "excludes already-signed-up" exclusion so an agent doesn't misread a short list as "nobody qualified." An `event_name` that resolves to nothing yields no recommendations and says so in `metadata` — it never falls back to a workspace-wide list. An ambiguous one returns the candidate events with their `channel_id`s under an `ambiguous_event_name` coverage note; re-call with the `channel_id` you want. ## Sample request ```json theme={null} { "tool": "get_invite_recommendations", "arguments": { "channel_id": "chn_9a112", "limit": 25 } } ``` ## Sample response ```json theme={null} { "tool": "get_invite_recommendations", "query_time_ms": 47.3, "result_count": 1, "data": [ { "company": "Lighthouse Robotics", "domain": "lighthouserobotics.example", "reasoning": "Attended 3 past events (highly engaged); has generated opportunities; previously MQL'd", "past_events": 3, "is_customer": true, "industry": "Robotics & Automation" } ], "metadata": { "data_sources_queried": ["Channel", "EventSignUp", "ABMCompany"], "date_range_applied": null, "filters_applied": { "channel_id": "chn_9a112", "limit": 25 }, "coverage_note": "Excludes companies already signed up for target event" } } ``` ## Response field reference ### Envelope | Field | Type | Description | | ------------------------ | ------- | ----------------------------------------------------------------- | | `tool` | string | Always `"get_invite_recommendations"`. | | `result_count` | integer | Number of candidates returned. | | `data` | array | One object per candidate, strongest candidate first. | | `metadata.coverage_note` | string | Always `"Excludes companies already signed up for target event"`. | ### `data[i]` | Field | Type | Description | | ------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------ | | `company` | string | Candidate company name. | | `domain` | string \| null | Candidate domain. | | `reasoning` | string | Semicolon-joined list of the specific factors that surfaced this candidate; `"General prospect"` when no factor applied. | | `past_events` | integer | Count of this company's prior event attendance in the workspace. | | `is_customer` | boolean | `true` if this company has ever generated an opportunity or booked a meeting. | | `industry` | string \| null | Industry, when known. | **The sample above is not a verbatim capture. A live response carries more fields than it shows, and you should not build on them.** Contract v1 is the default — omit `contract_version` and v1 is what you get — and a v1 candidate additionally carries a numeric `score`. Contract v2 replaces `score` and `reasoning` with a structured `reasons` array. v2 is defined but **not advertised**, so v1 is what a live call returns today. `score` is withdrawn (HEY-1764, HEY-1897): it was a composite of invented weights. It is documented nowhere on this page on purpose — publishing it would teach an agent to depend on a number heyBTW has decided not to keep, and the removal is already implemented in v2. `priority` (values such as `"TOP_PRIORITY"`, `"INVITE"`) is a separate case: it is still emitted in **both** v1 and v2. It is omitted here on HEY-2067 tier-vocabulary grounds, not because it has left the wire. Do not read its absence from this page as absence from the response. **What to build on:** the order of `data`, and the fields documented in the table above. Rank on position, not on a scalar. ## Errors * **`channel_id` is malformed.** Raised as a registered `invalid_parameter` error before any lookup runs. * **`channel_id` names a channel that does not exist, or is outside your workspace.** Raised as a registered `entity_not_found` error (HEY-1906). It does **not** silently produce an empty list — a target event that resolves to nothing is an error, never a fabricated recommendation list. * **`event_name` resolves to nothing.** Not an error. Returns no recommendations with a `metadata` coverage note naming what failed to resolve. * **`event_name` is ambiguous.** Not an error. Returns the matching events with their `channel_id`s under an `ambiguous_event_name` coverage note. * **Everything else** funnels through the same generic sanitized error as every tool on this surface — see [`get_workspace_overview` — Errors](/docs/mcp-tools/get-workspace-overview#errors). ## Pagination and limits No cursor-based pagination. `limit` (default 25, clamped to `[1, 500]`) caps candidates returned after ranking — there is no offset/cursor to page past it. ## Related tools * [`get_event_details`](/docs/mcp-tools/get-event-details) — see who's already registered for the target event before deciding who else to invite. * [`get_cross_event_patterns`](/docs/mcp-tools/get-cross-event-patterns) — a broader view of accounts with repeat engagement, useful when you don't yet have a target `channel_id`. # get_partner_insights Source: https://heybtw.com/docs/mcp-tools/get-partner-insights Partner influence metrics — sourcing breakdown, seniority profile, funnel rates, and pipeline impact per partner. This page documents the **Python MCP surface** (`mcp.heybtw.com`). It reflects `mcp-server/tools/partner_insights.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). ## Purpose `get_partner_insights` returns one entry per partner with a full sourcing and funnel breakdown: how many signups/MQLs/opportunities/meetings they've driven, per-event detail, a seniority profile of the contacts they've brought, and (when HubSpot is connected) pipeline revenue impact. ## When to use this * "Which partners have a relationship with a target account we could leverage for a warm intro?" — pair with `get_account_relationship` for a specific account, or scan all partners here first. * "Which partner should we lean on more — who's actually converting, not just attending?" * Building a partner performance leaderboard or QBR deck. ## Parameters | Name | Type | Required | Default | Description | Example | | ------------------ | ------- | -------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `partner_name` | string | No | `null` | Filter to partners whose name contains this substring (case-insensitive). | `"Northwind"` | | `partner_domain` | string | No | `null` | Filter to partners whose domain contains this substring. | `"northwind"` | | `include_archived` | boolean | No | `false` | Include archived/inactive partner relationships. | `true` | | `time_range` | string | No | `"program_total"` | One of `last_30_days`, `this_quarter`, `last_quarter`, `ytd`, `program_total`. Scopes `event_count`, `event_names`, `pipeline_impact`, `sourcing_breakdown`, and `funnel_metrics` to the window. `program_total` (or any unrecognized value) applies no bound. | `"this_quarter"` | **`time_range` windows are anchored to the event's date, not to deal-creation date.** This tool answers "what did this partner's events produce in this window", not "what deals were created in this window" — a different question a CRM-facing tool would answer. Bounds are computed in UTC and carry an explicit offset on the wire, so parsing is unambiguous; the quarter and year boundaries themselves are anchored to UTC-now, so a workspace far from UTC can see a boundary land up to roughly 12 hours off its local one. ## Default behavior Called with no parameters, returns **every** partner in the workspace (archived ones excluded by default), strongest relationship first — no result cap, no pagination. Every partner entry is included even if they have zero sourced signups (`total_sourced: 0`); filter client-side on `sourcing_breakdown.total_sourced > 0` if you only want active partners. ## Sample request ```json theme={null} { "tool": "get_partner_insights", "arguments": {} } ``` ## Sample response ```json theme={null} { "tool": "get_partner_insights", "query_time_ms": 73.9, "result_count": 1, "data": [ { "partner_name": "Northwind Ventures", "partner_domain": "northwindventures.example", "event_count": 3, "event_names": ["Robotics Summit SF 2026", "Automation Roundtable Q1", "Founders Dinner NYC"], "status": "active", "sourcing_breakdown": { "total_sourced": 46, "by_event": [ { "event_name": "Robotics Summit SF 2026", "channel_id": "chn_88af1", "sourced": 22, "mql": 6, "opportunity": 2 }, { "event_name": "Automation Roundtable Q1", "channel_id": "chn_71c02", "sourced": 14, "mql": 3, "opportunity": 1 }, { "event_name": "Founders Dinner NYC", "channel_id": "chn_5b901", "sourced": 10, "mql": 2, "opportunity": 0 } ] }, "funnel_metrics": { "total_signups": 46, "mql_count": 11, "opportunity_count": 3, "meeting_count": 5, "mql_rate": 0.2391, "opportunity_rate": 0.0652, "meeting_rate": 0.1087 }, "seniority_profile": { "executive": 2, "director_plus": 9, "manager": 14, "individual_contributor": 18, "unknown": 3 }, "contacts": [ { "email": "priya.nair@lighthouserobotics.example", "name": "Priya Nair", "title": "VP of Product", "company": "Lighthouse Robotics", "seniority": "director_plus", "funnel_status": "opportunity" } ], "contacts_total": 46, "contacts_shown": 46, "contacts_has_more": false, "seniority_profile_sample_size": 46, "seniority_profile_is_sampled": false, "pipeline_impact": { "crm_enriched": true, "sourced_revenue": 128400.0, "won_revenue": 42000.0, "company_count": 19 }, "account_overlap": { "portfolio_reached": 34, "penetration": 0.28, "co_marketing_events": 3, "multi_touch": 11, "never_reached": 87, "unclassified": 4, "icp_scoped": true, "denominator_mode": "icp", "upcoming": 2 }, "custom_list_overlays": [], "trends": null } ], "metadata": { "data_sources_queried": ["Partner", "Channel", "EventSignUp", "EventAttributionOpportunity"], "date_range_applied": null, "filters_applied": { "partner_name": null, "partner_domain": null, "include_archived": false, "crm_enriched": true }, "coverage_note": null } } ``` ## Response field reference ### Envelope | Field | Type | Description | | --------------- | ------- | ----------------------------------------------------------------------------------------------------------------- | | `tool` | string | Always `"get_partner_insights"`. | | `query_time_ms` | number | Server-side execution time in ms. | | `result_count` | integer | Number of partners in `data`. | | `data` | array | One object per partner, strongest relationship first. | | `metadata` | object | `coverage_note` is `"Connect HubSpot CRM to unlock pipeline attribution"` when CRM is not connected, else `null`. | ### `data[i]` | Field | Type | Description | | ----------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `partner_name` | string | Partner display name. | | `partner_domain` | string \| null | Partner domain, when set. | | `event_count` | integer | Distinct events this partner has been associated with. | | `event_names` | array of strings | Names of those events. | | `status` | string \| null | Partner relationship status (e.g. `"active"`), from the `Partner` record. | | `sourcing_breakdown.total_sourced` | integer | Total signups attributed to this partner across all events. | | `sourcing_breakdown.by_event` | array of objects | Per-event `{ event_name, channel_id, sourced, mql, opportunity }`. | | `funnel_metrics` | object | `{ total_signups, mql_count, opportunity_count, meeting_count, mql_rate, opportunity_rate, meeting_rate }`. Rates are `0.0` when `total_signups` is `0`. | | `seniority_profile` | object | Count of contacts per tier: `executive`, `director_plus`, `manager`, `individual_contributor`, `unknown`. **Built from the returned `contacts` array, so it sums to `contacts_shown`, not `contacts_total`.** When more contacts exist than were returned, this is a sample — see the two flags below before computing a percentage. | | `seniority_profile_sample_size` | integer | How many contacts the profile was built from. Equals `contacts_shown`. | | `seniority_profile_is_sampled` | boolean | `true` when contacts were truncated and the profile therefore describes a subset. Do not present a sampled profile as the partner's full seniority mix. | | `contacts` | array of objects | Up to 50 deduplicated contacts: `{ email, name, title, company, seniority, funnel_status }`. | | `contacts_total` / `contacts_shown` | integer | Same convention as [`get_account_relationship`](/docs/mcp-tools/get-account-relationship#response-field-reference) — `contacts_shown` is capped at 50. | | `contacts_has_more` | boolean | `true` when `contacts_total` exceeds `contacts_shown`. | | `pipeline_impact` | object | `{ crm_enriched: false }` only, when CRM is not connected. When connected: `{ crm_enriched: true, sourced_revenue, won_revenue, company_count }` — dollar amounts summed across every opportunity this partner sourced, `company_count` is distinct companies. | | `account_overlap` | object \| `null` | `{ portfolio_reached, penetration, co_marketing_events, multi_touch, never_reached, unclassified, icp_scoped, denominator_mode, upcoming }`. The same canonical coverage values the Partner Ecosystem Dashboard's Coverage cards use — never recomputed here. **`null`** for a global/admin call, when the partner spans more than one collab channel (a known gap), or when the internal lookup failed soft. `null` means "not computed", never "no overlap" — do not report it as zero. | | `custom_list_overlays` | array | One entry per Custom List attributed to this partner. **`[]`** (not `null`) when there is none. `total_members` on an entry is the service-maintained account count, not a fresh count taken at call time. | | `trends` | object \| `null` | Trend detail for this partner. **`null` unless the call is scoped to a single `partner_domain`** — it is not computed for a whole-workspace listing. Ask for one partner if you need it. | **The sample above is not a verbatim capture. A live response carries one more field per partner than it shows.** Contract v1 is the default — omit `contract_version` and v1 is what you get — and a v1 partner additionally carries `warmth_score`, a composite between `event_names` and `status`. It is the **only** field the sample omits; everything else above is shown as emitted. Contract v2 drops `warmth_score` and adds an `intro_paths` array of ranked, source-backed paths. v2 is defined but **not advertised**, so v1 is what a live call returns today. `warmth_score` is withdrawn (HEY-1897) because it was an unbacked composite, and it is documented nowhere on this page on purpose. Rank on order, and compare partners on `sourcing_breakdown` and `funnel_metrics`. ## Errors Same generic-sanitized-error behavior as every tool on this surface — see [`get_workspace_overview` — Errors](/docs/mcp-tools/get-workspace-overview#errors). This tool has no parameter-validation failure modes of its own; every parameter is optional and any string value is a valid (possibly zero-match) filter. ## Pagination and limits No caller-facing `limit` parameter and no cursor pagination — every matching partner is returned in one call. Internally, the underlying rows are capped at 500 before aggregation (a fixed server-side safety limit, not adjustable); a workspace would need over 500 partner-event-partnership rows to hit it, well beyond any workspace observed today. `contacts` per partner is separately capped at 50 (see `contacts_shown`/`contacts_total` above). ## Related tools * [`get_account_relationship`](/docs/mcp-tools/get-account-relationship) — the account-centric view of the same warm-intro data. * [`get_workspace_overview`](/docs/mcp-tools/get-workspace-overview) — `program_metrics.partner_program` is a workspace-wide rollup of this tool's data. * [`get_event_details`](/docs/mcp-tools/get-event-details) — per-event partner performance (`partner_performance`), scoped to one event instead of across all events. # get_workspace_overview Source: https://heybtw.com/docs/mcp-tools/get-workspace-overview Program health and agent capability discovery — call this first to orient yourself before querying specific data. This page documents the **Python MCP surface** (`mcp.heybtw.com`, Claude Desktop and other MCP clients). It reflects the tool exactly as implemented in `mcp-server/tools/workspace_overview.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). ## Purpose `get_workspace_overview` returns a single-object snapshot of the calling workspace: its identity and plan, which integrations are connected, headline program metrics (signups, MQLs, pipeline), and agent guidance (which other tools are worth calling next, given what's actually configured). ## When to use this * The first call in any new agent session against a workspace you haven't queried before. * "What can I ask about this workspace?" or "Is HubSpot connected here?" * Before recommending a specific tool to the end user — `agent_guidance.data_limitations` tells you which tools will return degraded or empty data. ## Parameters | Name | Type | Required | Default | Description | Example | | ----------- | ---------------------------------- | -------- | ------- | ------------------------------------------------------------------------------------------------------- | -------------- | | `date_from` | string (ISO 8601 date or datetime) | No | `null` | Restrict `program_metrics` to signups/events on or after this date. When omitted, metrics are all-time. | `"2026-01-01"` | ## Default behavior Called with no parameters, this tool returns **all-time** program metrics (`program_metrics.period` is `"all_time"`) for the calling workspace — no result cap, no pagination, a single object (`result_count: 1`). `configuration.integrations` reflects live connection state at call time; it is not cached. ## Sample request ```json theme={null} { "tool": "get_workspace_overview", "arguments": {} } ``` ## Sample response ```json theme={null} { "tool": "get_workspace_overview", "query_time_ms": 84.2, "result_count": 1, "data": [ { "workspace_id": "ws_9f2a1c", "workspace_name": "Acme Events Co", "domain": "acmeevents.example", "industry": "Marketing Technology", "workspace": { "name": "Acme Events Co", "domain": "acmeevents.example", "plan": "growth", "created_date": "2025-03-11T00:00:00+00:00" }, "configuration": { "integrations": { "hubspot_crm": true, "luma_events": true, "splash_events": false, "zuddl_events": false, "enrichment": { "provider": "fullenrich", "connected": true, "credits_remaining": 4200 } }, "capabilities": { "pipeline_attribution": true, "partner_sourcing": true, "seniority_classification": true, "invite_recommendations": true, "event_cost_tracking": true, "enrichment": true }, "data_availability": { "event_count": 14, "partner_count": 6, "total_signups": 2310, "has_attribution_data": true } }, "program_metrics": { "period": "all_time", "period_start": null, "period_end": "2026-07-25T18:04:11+00:00", "event_count": 14, "total_signups": 2310, "total_mql": 318, "total_opportunity": 87, "total_meetings": 142, "partner_sourced_count": 640, "unique_companies": 812, "mql_rate": 0.1377, "partner_sourced_pct": 0.2771, "last_event_date": "2026-06-18T00:00:00+00:00", "first_event_date": "2025-04-02T00:00:00+00:00", "partner_program": { "total_partners": 6, "active_partners": 5, "partner_sourced_pct": 0.2771 }, "trends": { "attendance_trend": "increasing", "mql_trend": "stable", "partner_count_trend": "increasing" }, "attribution_summary": { "crm_connected": true, "total_sourced_pipeline": 412500.0, "total_influenced_pipeline": 891200.0, "total_closed_won": 156000.0, "total_opportunities": 87, "program_conversion_rate": 0.1377, "avg_cost_per_meeting": null, "avg_cost_per_mql": null } }, "agent_guidance": { "available_tools": [ { "tool": "get_event_details", "description": "Event logistics, roster, attendance mix, seniority, and partner performance - before or after it runs" }, { "tool": "get_account_relationship", "description": "Full Context Graph profile for any account by domain" }, { "tool": "get_partner_insights", "description": "Partner performance, warmth scores, and sourcing breakdown" }, { "tool": "get_cross_event_patterns", "description": "Multi-event engagement trajectories by company" }, { "tool": "activate_list", "description": "WRITE - send a saved List's invites to its linked Luma event. Requires action=preview first and explicit human confirmation before action=confirm" }, { "tool": "get_event_attribution", "description": "Pipeline attribution per event with sourced/influenced breakdown" }, { "tool": "query_event_intelligence", "description": "DEPRECATED, being retired — cross-event attendance patterns by account or event. Use get_cross_event_patterns, get_account_relationship, or get_event_details instead" }, { "tool": "get_invite_recommendations", "description": "Scored invite recommendations for a target event" }, { "tool": "get_workspace_overview", "description": "Program health, integration status, and agent orientation" } ], "suggested_first_queries": [ { "tool": "get_event_attribution", "description": "Get attribution summary across all events", "example_params": {} }, { "tool": "get_cross_event_patterns", "description": "Account engagement trajectories (new/increasing/stable/decreasing) per company, each anchored to the events behind it", "example_params": { "min_events": 2 } }, { "tool": "get_partner_insights", "description": "Understand partner sourcing performance", "example_params": {} } ], "data_limitations": [ "Invite recommendations: channel_id filter not yet implemented" ] } } ], "metadata": { "data_sources_queried": ["Workspace", "Channel", "EventSignUp", "Partner", "HubSpotConfig"], "date_range_applied": null, "filters_applied": { "workspace_id": "ws_9f2a1c", "date_from": null }, "coverage_note": null } } ``` ## Response field reference ### Envelope | Field | Type | Description | | --------------- | ---------------- | --------------------------------------------------------------- | | `tool` | string | Always `"get_workspace_overview"`. | | `query_time_ms` | number | Server-side execution time in milliseconds. | | `result_count` | integer | Always `1` on success — this tool returns exactly one object. | | `data` | array (length 1) | The workspace overview object. | | `metadata` | object | See [Response format](/docs/integrations/mcp-tools#response-format). | ### `data[0]` | Field | Type | Description | | ----------------- | -------------- | ----------------------------------------------------------------------- | | `workspace_id` | string | The calling workspace's id, resolved from the API key. | | `workspace_name` | string | Workspace display name. Duplicated at `workspace.name`. | | `domain` | string \| null | Workspace's own domain, when set. | | `industry` | string \| null | Workspace industry, when set. | | `workspace` | object | `{ name, domain, plan, created_date }`. `plan` is `"unknown"` if unset. | | `configuration` | object | See below. | | `program_metrics` | object | See below. | | `agent_guidance` | object | See below. | ### `data[0].configuration` | Field | Type | Description | | ----------------------------------------------------------------------- | ------------------------ | ---------------------------------------------------------------------------------------------- | | `integrations.hubspot_crm` | boolean | HubSpot connected and active. | | `integrations.luma_events` \| `.splash_events` \| `.zuddl_events` | boolean | Event platform connection status per provider. | | `integrations.enrichment.provider` | `"fullenrich"` \| `null` | `null` when no enrichment credits are configured. | | `integrations.enrichment.connected` | boolean | `true` when `credits_remaining > 0`. | | `integrations.enrichment.credits_remaining` | integer \| null | `null` when not connected. | | `capabilities.*` | boolean | Feature flags derived from `integrations` — e.g. `pipeline_attribution` mirrors `hubspot_crm`. | | `data_availability.event_count` \| `.partner_count` \| `.total_signups` | integer | Raw counts. | | `data_availability.has_attribution_data` | boolean | Mirrors `hubspot_crm`. | ### `data[0].program_metrics` | Field | Type | Description | | -------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `period` | `"all_time"` \| `"custom"` \| `"last_N_days"` | Derived from whether `date_from` was supplied. | | `period_start` | string (ISO 8601) \| null | Echoes `date_from`. | | `period_end` | string (ISO 8601) | Always "now" at call time. | | `event_count` | integer | Events in the period. | | `total_signups` | integer | Total signups in the period. | | `total_mql` | integer | Total MQLs in the period. | | `total_opportunity` | integer | Total opportunities in the period. | | `total_meetings` | integer | Total meetings booked in the period. | | `partner_sourced_count` | integer | Signups attributable to a partner. | | `unique_companies` | integer | Distinct companies represented. | | `mql_rate` | number (0–1) | `total_mql / total_signups`, `0.0` if no signups. | | `partner_sourced_pct` | number (0–1) | `partner_sourced_count / total_signups`. | | `last_event_date` / `first_event_date` | string (ISO 8601) \| null | Bounds of the workspace's event history. | | `partner_program` | object | `{ total_partners, active_partners, partner_sourced_pct }`. `active_partners` = partners with `total_sourced > 0`. On contract v1 (the default) this object carries a fourth key, `avg_partner_warmth`, which is withdrawn (HEY-1897) and deliberately undocumented — see the version note below. | | `trends` | object | `{ attendance_trend, mql_trend, partner_count_trend }`, each `"increasing"` \| `"stable"` \| `"decreasing"` \| `"new"` \| `"insufficient_data"`. Requires ≥3 events in the period; otherwise every field is `"insufficient_data"`. | | `attribution_summary` | object | See below. Sourced from the same canonical attribution resolver as [`get_event_attribution`](/docs/mcp-tools/get-event-attribution) — always workspace-wide/all-time, **independent of `date_from`**. | **The sample above is not a verbatim capture: `partner_program` carries one more key on the wire.** Contract v1 is the default — omit `contract_version` and v1 is what you get — and v1's `partner_program` additionally carries `avg_partner_warmth`, the mean of an unbacked composite. Contract v2 omits it, leaving three observable facts. v2 is defined but **not advertised**, so v1 is what a live call returns today. It is withdrawn (HEY-1897) and documented nowhere on this page on purpose. Do not build on it; the remaining keys are all independently observable. **`engagement_health` is a different case: it is gone outright, at every contract version.** HEY-1913 removed the block outright — `accounts_new`, `accounts_increasing`, `accounts_stable`, `accounts_decreasing`, and `top_engaged_account` — rather than deprecating it: its counts were bare scalars an agent could not re-derive, and a second path computing trajectories diverged from the anchored one (it reported 20 accounts where `get_cross_event_patterns` reported 83 on the same workspace). This tool no longer classifies account trajectories at all. [`get_cross_event_patterns`](/docs/mcp-tools/get-cross-event-patterns) is the one trajectory surface, and each of its rows carries the `events[]`, `first_seen`, `last_seen`, and `total_events` behind its classification. That is why this tool's `suggested_first_queries` now routes there unconditionally. Earlier versions of this page documented `engagement_health` as live. If you built a parser against it, it has been receiving nothing since that removal. **`program_metrics.attribution_summary`** — when `configuration.integrations.hubspot_crm` is `false`, this shrinks to `{ crm_connected: false, total_sourced_pipeline: null, total_influenced_pipeline: null, total_closed_won: null, recommendation: "" }`. When CRM is connected but the attribution service is unreachable, every dollar field is `null` and `coverage_note` explains why (the fuller shape shown in the sample omits `coverage_note` because it succeeded). `avg_cost_per_meeting` and `avg_cost_per_mql` are always `null` today — cost data is not yet wired into this rollup (see [`get_event_attribution`](/docs/mcp-tools/get-event-attribution) for the one place program-level cost-per-meeting IS live, under `program_summary`). ### `data[0].agent_guidance` | Field | Type | Description | | ------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `available_tools` | array of `{ tool, description }` | Static list of all nine tools — eight read tools plus the `activate_list` write tool — **not** filtered by what's actually usable for this workspace, and not filtered by what the caller is entitled to call. One entry (`activate_list`) is a write tool: read its description before acting on it. | | `suggested_first_queries` | array of `{ tool, description, example_params }` | Mostly conditional on `program_metrics` — e.g. `get_partner_insights` only when `partner_count > 0`. One entry is **unconditional**: `get_cross_event_patterns` ships on every response as the routing answer for account-trajectory questions, replacing the removed `engagement_health` rollup. | | `data_limitations` | array of strings | Plain-English gaps, e.g. missing HubSpot, no event platform connected, no enrichment. | **Two `available_tools` descriptions are stale on the wire.** The catalog is a static list compiled into the server, and it still describes `get_invite_recommendations` as returning "scored" recommendations and `get_partner_insights` as carrying "warmth scores". Both scalars are being removed from the contract (HEY-1764, HEY-1897); see those tools' reference pages, which are authoritative over this catalog string. The sample above transcribes the descriptions as actually emitted rather than quietly correcting them, so what you see here matches what you will receive. **`data_limitations` unconditionally includes `"Invite recommendations: channel_id filter not yet implemented"`,** on every response, and that string is inaccurate. `channel_id` on [`get_invite_recommendations`](/docs/mcp-tools/get-invite-recommendations) is one of the two ways to name the target event — the other is `event_name` — and both are implemented. It is not a missing optional filter. Do not report it to a user as a missing feature or a degraded capability. Correcting the string itself is a change to the MCP server, not to this page. ## Errors This tool raises no tool-specific structured errors today. Any failure (workspace not found, unexpected exception) is caught by the server's generic handler and surfaces to the client as: ``` RuntimeError: Internal error executing get_workspace_overview (error_id=<12-char hex>). ``` The `error_id` is logged server-side with the real exception — useful when filing a support request, but the client never sees which specific condition failed. This is current behavior across all nine tools; see [MCP Tools — Errors and troubleshooting](/docs/integrations/mcp-tools) for the transport-level errors (401, 429, 503) that can occur before a tool call is even attempted. ## Pagination and limits Not applicable — this tool always returns exactly one object. There is no `limit` parameter and no cursor-based pagination on any of the eight read tools today (see [Schema stability](/docs/integrations/mcp-tools#schema-stability)). ## Related tools * [`get_event_attribution`](/docs/mcp-tools/get-event-attribution) — the canonical source for `attribution_summary`'s numbers, with per-event granularity. * [`get_partner_insights`](/docs/mcp-tools/get-partner-insights) — full detail behind `partner_program`. * [`get_cross_event_patterns`](/docs/mcp-tools/get-cross-event-patterns) — the one place account trajectories are classified. This tool no longer computes them; see the `engagement_health` warning above. # query_event_intelligence Source: https://heybtw.com/docs/mcp-tools/query-event-intelligence DEPRECATED, being retired. Cross-event attendance patterns by account or event — attendee-level detail grouped by resolved company. This page documents the **Python MCP surface** (`mcp.heybtw.com`). It reflects `mcp-server/tools/event_intelligence.py` as of this page's publication — see [Schema stability](/docs/integrations/mcp-tools#schema-stability). **Deprecated — being retired. Do not build new integrations on this tool.** The tool is registered with the title "Event Intelligence (deprecated)", its own description on the wire opens `DEPRECATED — being retired`, and `get_workspace_overview`'s capability catalog describes it the same way. It is retired by **HEY-1895**, which drops it from the v2 toolset (HEY-893); it is deliberately v1-only, so a v2 request for it returns `invalid_parameter` rather than being silently served a v1 shape. It is still served on v1 and still answers correctly, so existing callers are not broken today. Migrate before v2. An earlier version of this page said it was "a live, supported tool, not deprecated." That was wrong when published and is corrected here. **Naming note.** This tool predates the `get_` naming convention used by the other read tools on this surface — it is registered and must be called as `query_event_intelligence`, not `get_event_intelligence`. ## What to use instead Pick the successor by the question you are actually asking. These are the canonical answers; this tool will stop being served in a future contract version. | Question | Use | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | Multi-event engagement for a company | [`get_cross_event_patterns`](/docs/mcp-tools/get-cross-event-patterns) — the same company/domain rows plus per-event signals and a trajectory | | Everything known about one account | [`get_account_relationship`](/docs/mcp-tools/get-account-relationship) — event history, contacts with seniority, CRM context | | Who attended one specific event | [`get_event_details`](/docs/mcp-tools/get-event-details) | The one remaining niche is that this tool accepts `event_name`, while the successors key on `channel_id` or `domain`. Resolve a name to a `channel_id` via [`get_event_attribution`](/docs/mcp-tools/get-event-attribution) — its rows carry both — and prefer the successors. ## Purpose `query_event_intelligence` groups event attendance by resolved company and returns, for each company, which events they attended, their contact list at those events, and a simple `is_customer`/`is_prospect` flag. It's a lighter-weight sibling to [`get_cross_event_patterns`](/docs/mcp-tools/get-cross-event-patterns) — no trajectory classification, but includes contact-level detail directly instead of requiring a follow-up call. ## When to use this * "What events has Chargebee attended?" or "Show me everyone from stripe.com who's engaged with us." * You want attendee contacts alongside event history in one call, and don't need trajectory/warm-intro data — for that, use [`get_account_relationship`](/docs/mcp-tools/get-account-relationship) instead. The published overview page for this surface has previously described this tool as taking `account_name`, `date_range_days`, and `event_id` parameters. Those do not exist on the live implementation — the actual parameters are `event_name`, `domain`, `limit`, and `include_own_domain`, documented below. This page is the corrected reference; treat any conflicting description elsewhere as stale. ## Parameters | Name | Type | Required | Default | Description | Example | | -------------------- | ------- | -------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------ | | `event_name` | string | No | `null` | Filter to attendance at events whose name contains this substring (case-insensitive). | `"Robotics Summit"` | | `domain` | string | No | `null` | Filter to a specific company domain (matches enrichment-resolved domain, or raw email domain). | `"lighthouserobotics.example"` | | `limit` | integer | No | `10` | Max **companies** returned (see [Pagination and limits](#pagination-and-limits) for how this interacts with the underlying row fetch). Effective range `[1, 500]`. | `25` | | `include_own_domain` | boolean | No | `false` | Include the calling workspace's own domain in results. | `true` | ## Default behavior Called with no parameters, returns up to **10 companies**, grouped from event attendance across the whole workspace with no date restriction — the underlying data is not date-filtered by this tool at all despite `metadata.date_range_applied` appearing in the envelope (it is always `null` here; unlike other tools, there is no `date_from`/`date_to` parameter on this one). ## Sample request ```json theme={null} { "tool": "query_event_intelligence", "arguments": { "domain": "lighthouserobotics.example" } } ``` ## Sample response ```json theme={null} { "tool": "query_event_intelligence", "query_time_ms": 39.8, "result_count": 1, "data": [ { "company": "Lighthouse Robotics", "domain": "lighthouserobotics.example", "events_attended": 2, "event_names": ["Automation Roundtable Q1", "Robotics Summit SF 2026"], "contacts": [ { "name": "Priya Nair", "title": "VP of Product", "email": "priya.nair@lighthouserobotics.example" }, { "name": "Sam Oduya", "title": "Senior Software Engineer", "email": "sam.oduya@lighthouserobotics.example" } ], "is_customer": true, "is_prospect": false } ], "metadata": { "data_sources_queried": ["Channel", "EventSignUp"], "date_range_applied": null, "filters_applied": { "event_name": null, "domain": "lighthouserobotics.example", "limit": 10 }, "coverage_note": null } } ``` **Personal-email domain example** (`domain: "gmail.com"`): ```json theme={null} { "tool": "query_event_intelligence", "query_time_ms": 1.1, "result_count": 0, "data": [], "metadata": { "data_sources_queried": ["Channel", "EventSignUp"], "date_range_applied": null, "filters_applied": { "event_name": null, "domain": "gmail.com", "limit": 10 }, "coverage_note": "'gmail.com' is a personal email provider, not a company domain — it cannot identify a single account." } } ``` ## Response field reference ### Envelope | Field | Type | Description | | ----------------------------- | ------------- | ------------------------------------------------------------------------------------------- | | `tool` | string | Always `"query_event_intelligence"`. | | `result_count` | integer | Number of companies in `data` (≤ `limit`). | | `data` | array | One object per resolved company. | | `metadata.date_range_applied` | `null` always | This tool has no date parameters; do not infer date scoping from this field on other tools. | ### `data[i]` | Field | Type | Description | | ----------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `company` | string | Resolved company name (enrichment-resolved where available). | | `domain` | string \| null | Resolved company domain. `null` when no enrichment resolution exists and every contact's raw email domain is a personal-email provider. | | `events_attended` | integer | Distinct events this company's attendees appear at. | | `event_names` | array of strings | Names of those events, unordered. | | `contacts` | array of objects | Deduplicated by email: `{ name, title, email }`. **No `limit` cap or `_total`/`_shown` pair on this array** — unlike every other tool on this surface, all contacts for a matched company are returned. | | `is_customer` | boolean | `true` if any attendee from this company ever hit `opportunity` or `meetingBooked`. | | `is_prospect` | boolean | Always the logical inverse of `is_customer` — not an independent signal. | ## Errors * **`domain` is a personal-email provider** (e.g. `gmail.com`, `outlook.com`). Handled explicitly, does not error — returns `result_count: 0` with `metadata.coverage_note` explaining why (shown in the sample above). * All other failures funnel through the same generic sanitized error as every tool — see [`get_workspace_overview` — Errors](/docs/mcp-tools/get-workspace-overview#errors). ## Pagination and limits No cursor-based pagination. `limit` (default 10) caps the number of **companies** in the response, but the underlying SQL row fetch is `clamp_limit(limit) * 10` (i.e. up to 10x more raw attendance rows than companies requested, capped at the shared server-side 500-row ceiling before the `* 10` multiplier) — this is an internal over-fetch to make sure grouping by company doesn't starve the requested company count, not a caller-facing knob. If you need more than 10 companies, raise `limit` directly; there is no way to fetch "the next 10." ## Related tools * [`get_cross_event_patterns`](/docs/mcp-tools/get-cross-event-patterns) — the trajectory-classified alternative, without inline contacts. * [`get_account_relationship`](/docs/mcp-tools/get-account-relationship) — deeper single-account profile including warm intro paths and CRM pipeline, once you've identified a company of interest here. # MCP Standards Source: https://heybtw.com/docs/mcp-tools/standards The identity, privacy, response, and compatibility rules for building against heyBTW MCP tools. This page describes the contract heyBTW is standardizing across its MCP tools. It separates the behavior available today from the versioned target so clients do not mistake planned fields for live fields. ## Current compatibility boundary The current Python MCP surface uses the response shapes documented on each tool reference page. When a versioned replacement is published, existing fields remain supported through the end of its published deprecation window. This page's opaque identity, privacy-projection, and deletion behavior is a proposed versioned target, not current production behavior. Stable opaque `company_id`, `contact_id`, and `event_id` fields are not present consistently on the current Python surface. Do not fabricate them from names, email addresses, or provider IDs. ## Stable entity references The versioned identity contract uses typed references: ```json theme={null} { "company_id": "hbtw_co_v1_AbCdEfGhIjKlMnOpQrStUv", "company_domain": "example.com", "company_name": "Example" } ``` ```json theme={null} { "contact_id": "hbtw_ct_v1_ZyXwVuTsRqPoNmLkJiHgFe", "contact_email": "person@example.com", "contact_name": "Person", "company_id": "hbtw_co_v1_AbCdEfGhIjKlMnOpQrStUv" } ``` ```json theme={null} { "event_id": "hbtw_ev_v1_0123456789_ABCDEFGHIJK", "event_slug": "customer-roundtable-2026-R4nd0mSfx_1", "event_name": "Customer Roundtable 2026" } ``` IDs are: * stable across tools and sessions inside one authorized workspace; * opaque and free of email, domain, CRM, and provider identifiers; * intentionally different for the same underlying entity in another workspace; * resolved only after workspace authorization; * revoked from public responses when the entity is deleted. The `_v1_` token in an ID is the handle-format version, not the MCP response contract version. MCP contract v2 can carry a v1-format handle. A response version change does not silently rotate entity IDs. Handle format v1 uses exactly 22 unpadded base64url characters after the entity prefix. Email, domain, CRM IDs, and event-platform IDs are lookup keys or provenance. They are not canonical public identity. All display attributes are optional, including company domains and names, contact emails and names, and event names and slugs. They appear only when the caller, entity, and tool purpose are authorized by heyBTW's field-disclosure policy. Event slugs include a random workspace-specific suffix and are not cross-workspace join keys. ## Company and contact matching Company matching uses a normalized registrable domain, rejects personal-email providers, and excludes the workspace's own domain. A workspace alias applies only after heyBTW verifies the required authority for both the alias and its canonical target. Verifying one endpoint cannot bind it to an arbitrary company. A personal-email contact has no company reference. Contact email matching trims surrounding whitespace and lowercases only the domain. The local part, including case and plus-addressing, remains distinct unless a verified provider-specific namespace rule proves two forms equivalent. `Person@example.com`, `person@example.com`, and `person+event@example.com` are not automatically merged. A job change preserves a contact ID only when verified continuity evidence supports the same person; otherwise the new email creates a separate contact and handle. A rebrand preserves company continuity only through verified two-sided alias authority or an audited merge. Similar names never establish identity by themselves. ## Privacy and deletion Workspace query scoping is live today. Foreign opaque-handle behavior and the HEY-818 deletion guarantees below are proposed targets and are not live. The global data-subject deletion endpoint remains unavailable until Legal and Security approve its authentication, evidence, notification, exception, appeal, and reversal runbook. Every read is workspace-scoped at the data-access boundary. A handle from another workspace is treated exactly like an unknown handle. When an authorized workspace deletes a contact, heyBTW immediately denies reads, fences in-flight writers, then removes that workspace's public handle, PII projection, CRM and provider mappings in scope. Imports, syncs, enrichment, webhooks, and retries cannot recreate the contact. A verified global data-subject request revokes all public handles and aliases in scope. Deleted contacts are excluded from MCP tools, heyBTW AI, exports, lists, search, and relationship endpoints. Person-level graph edges are removed. No aggregate derived from those edges remains unless a separately approved privacy contract defines and tests its re-identification protections. ## Versioning and the existing `cmp_` ID The in-app TypeScript implementation of `get_partner_overlaps` currently emits a deterministic `cmp_` company value. It is not available through the public `mcp.heybtw.com` Python gateway. That value is a v1 compatibility key, not the final opaque identity scheme, and will not be silently redefined in place. Because it is derived from the company domain, it is a temporary cross-workspace-correlation exception and does not satisfy the opaque-ID privacy guarantee. Do not adopt it in a new integration or treat it as durable identity. A new major response version will introduce the opaque identity references. HEY-393 owns the negotiation mechanism, supported values, default behavior, and discovery contract. Until that mechanism is published on the affected tool reference pages, the current response remains the default and clients cannot request the target version. After publication, selector-free requests continue to receive the current contract through the entire deprecation window. Clients selecting a supported new version use the documented mechanism and migrate before that window expires. The default cannot change silently; any post-deprecation fallback must be published before the window begins. This page does not invent a header, parameter, or tool-name convention. Response-version negotiation and handle-format versioning are separate compatibility axes. Identity lookup and handle allocation require a trusted server-derived authorization context that binds workspace membership, partner and sponsor visibility, and the allowed entity set. They also require a closed tool-purpose value. Request parameters cannot create or widen either value, and unauthorized entities fail closed before lookup or handle allocation. ## Response rules Versioned responses converge on: * an explicit status; * typed data; * metadata with workspace, tool version, generation time, freshness, Context Graph coordinates, pagination, and rate-limit state; * structured errors that state what failed, what to check, and what to do; * cursor pagination without silent truncation; * source-backed facts instead of unverifiable scores. ## Consumer rules for the versioned target The per-tool reference pages remain authoritative for current production behavior. Until a tool advertises the versioned response contract, do not assume that pagination, coverage, or structured recovery metadata is present. 1. Treat IDs as opaque. Do not parse or recreate them. 2. Scope cached IDs by workspace, entity type, and handle-format version. 3. When present, use `company_domain` only as an external CRM lookup input, not as a replacement for `company_id` or as a cross-tool identity. 4. Do not use email as a durable person ID. 5. Check pagination and coverage metadata before claiming that a result is complete or zero. 6. Read structured error recovery fields before retrying. 7. Never persist provider IDs as cross-platform identity. See [MCP Tools](/docs/integrations/mcp-tools) for setup and the current tool catalog. # Adding and Inviting Partners Source: https://heybtw.com/docs/partner-ecosystem/adding-and-inviting-partners Two ways to add partners: domain-based access per event, or email invite with co-host. ## Adding Partners to an Event (Domain-Based) The most common way to add partners. Click **+ Partner** in the top right of any collab to open the **Invite Partners** modal. 1. Enter a partner domain (e.g., `meta.com`) and click **Add**. 2. Add as many domains as you need. Each appears in the list below the input. 3. Click **Ok** when done. Users with email addresses from those domains will be automatically joined to this event when they log into heyBTW. No email is sent. The partner only sees this specific event, not your other collabs. You can remove a partner domain by clicking **Delete** next to it in the modal. ### How Domain Permissions Work Adding `stripe.com` to your Berlin Fintech Dinner means anyone with a `@stripe.com` email who logs into heyBTW will see that collab. They won't see your other events unless you've added `stripe.com` to those collabs too. Each event is scoped separately. ## Inviting a Partner with Email (Co-Host) Use this when you want to send a specific email invitation and set someone as co-host. 1. Open a collab and go to the **My Partners** tab. 2. Click **+ Partner** at the bottom of the partner list. 3. Enter the partner's domain and contact email. 4. Optionally set them as **Co-Host**. This still uses domain-based permissions, but also sends them an email invitation to join heyBTW. Use this for partners who aren't on the platform yet. ## Adding a Partner from the Ecosystem You can also add partners at the workspace level: 1. Go to **Partner Ecosystem** in the left sidebar. 2. Click **+ Add Partner** in the top right. 3. Enter the partner's name and domain. Partners added here appear in your ecosystem but aren't automatically added to any collab. You still add them to specific events using the methods above. ## Where Partners Appear Partners added to any event collab automatically show up in your workspace-level [Partner Ecosystem Dashboard](/docs/partner-ecosystem/partner-ecosystem-dashboard). You don't need to add them twice. ## Partner Status * **Active** - Partner has logged in and can see their events. * **Invited** - Email invitation sent, partner hasn't joined yet. (Only applies to email invites, not domain-only adds.) * **Inactive** - Partner exists in your ecosystem but has no active collabs. # My Partners Source: https://heybtw.com/docs/partner-ecosystem/my-partners Manage partners, assign tiers, and control visibility per collab. The **My Partners** tab lives inside each collab. It shows every partner involved in that event, their tier, co-host status, and sourced leads. ## Partner List Each partner row shows: * **Company** - Partner name, logo, and domain. * **Tier** - Dropdown to assign a sponsor tier (Platinum, Gold, Silver, Supporting, or custom). Only visible when [Sponsor Mode](/docs/partner-ecosystem/sponsor-mode) is enabled. * **Co-Host** - Whether this partner is a co-host on the event. * **Sourced** - Number of attendees sourced by this partner. * **Visibility** - Whether the partner can see other partners in the collab. * **Actions** - Edit or remove the partner. The workspace owner is labeled **Owner** and always appears at the top. ## Assigning Tiers With Sponsor Mode enabled, use the **Tier** dropdown next to each partner to assign them to a sponsor tier. This controls what attendee data they can see. See [Sponsor Mode](/docs/partner-ecosystem/sponsor-mode) for details on configuring tiers. ## Adding a Partner Click **+ Partner** at the bottom of the list to add a new partner to the collab. Enter their company name and a contact email. They'll receive an invitation to join. You can also add partners from the top nav bar using the **+ Partner** button. ## Editing a Partner Click the edit icon next to any partner to open the **Edit Partner** modal. Two sections: **UTM Source Attribution** (left side) Set the UTM source value for this partner (e.g., `utm_source=braze`). When attendees register through this partner's tracking link, they're automatically attributed to this partner in the Partner Source column. Click the auto-generate button to create a UTM value from the partner's name. The **Partner tracking link** is generated once a Luma or Splash event is connected to this collab. Copy and share it with the partner so they can promote the event with built-in attribution. **Co-Host Contact** (right side) Set the primary contact for this partner: * **Co-Host Name** and **Co-Host Email** * **Send new invitation email** checkbox - Check this to send (or re-send) an email invitation to the co-host. * **Custom Message (Optional)** - Add a personal message to include in the invitation email. The partner's domain is shown at the bottom of the modal. ## Partner Visibility The visibility column controls whether a partner can see other partners in the collab. Toggle this per partner. Some sponsors want to know who else is sponsoring. Others prefer privacy. ## Relationship to Other Views * **[Partner Ecosystem Dashboard](/docs/partner-ecosystem/partner-ecosystem-dashboard)** - Aggregate performance across all partners, all collabs. * **[Sponsor Mode](/docs/partner-ecosystem/sponsor-mode)** - Configure tier-level data access controls. * **[Adding and Inviting Partners](/docs/partner-ecosystem/adding-and-inviting-partners)** - Detailed guide on the invitation flow. # Partner Ecosystem Dashboard Source: https://heybtw.com/docs/partner-ecosystem/partner-ecosystem-dashboard Map accounts with partners, track portfolios without onboarding anyone, and see how much of a partner's list you have actually reached. The Partner Ecosystem is your workspace-level view of every partner relationship and every account you're tracking. It lives in the left sidebar under **Partner Ecosystem**. Partners added to any event collab appear here automatically. You don't need to add them twice. ## Two ways to work with a partner You do not need the other side to sign up before you get value. * **Invited partners.** The partner has their own heyBTW workspace. Each side maintains its own account list, and mapping reflects both. Overlap is confirmed by both parties. * **Portfolios.** You upload the company list yourself and work from it immediately. Nothing is required of the other side. Accounts brought in this way carry the **Portfolio** status. Portfolios are how you start. Click **Invite** on a partner at any point to bring them in properly, and the mapping you already built stays. A portfolio is a list you maintain on someone else's behalf, so it is only as current as your last upload. Once a partner is invited and maintaining their own list, mapping reflects what they actually have rather than what you believe they have. ## Partners tab Your partner list shows every company in your ecosystem. Each shows their name, domain, and logo. Use **Show Hidden** to reveal or hide inactive partners, and **+ Add Partner** to add one. Click any partner to open the account mapping view for that relationship. ## Account mapping The mapping view is one partner at a time. The header shows their list size and freshness, for example **Signalfire's account list: 114 companies, Updated 7/18/2026**, alongside **Last sync**, an **Activity** log, and an **Invite** button if they aren't in yet. ### Perspective The **Viewing as** badge names whose side you're looking from. Use the switcher in the top right to flip between your view and the partner's. Same accounts, different vantage point, which is what makes a joint account review possible in one screen. ### Working from **Working from** sets which accounts the whole view operates on. Pick any [List](/docs/lists/overview), or **View Global list** to work from your full workspace set. The selector groups lists by where they came from: **Partner Ecosystem**, **Agent**, and **Manual**. Every filter, column, and metric below scopes to whatever you pick, so this is the first control to set, not the last. ### Upload Portfolio **Upload Portfolio** brings in a set of companies you want to track against this partner without the partner uploading anything. This is the entry point for VC portfolios, accelerator cohorts, and any partner whose account list you can assemble yourself. ### Filters Open **Filters** above the table. **Play presets** are one-click filter combinations for the two most common jobs, **Shared prospects** and **Make intros**. Each shows its match count so you can see whether the play is live before you run it. **Dropdowns** * **View.** Which slice of the partner's accounts to show. * **Overlap.** Narrow to accounts appearing on both lists, or widen to all. * **Vertical** and **Region.** Your workspace taxonomy, configured in Settings. * **Next Step.** Pipeline progression status. * **Business Type.** Account relationship category. **Status toggles** * **Your status.** Customer, Prospect, Partner, Unqualified, and Portfolio, each with a live count. * **Partner status.** The same idea from their side, showing how they classify the same accounts. A footer shows how many filters are active and how many rows are showing, with **Clear all** to reset. ### The table Each row is a company. Columns: * **Company.** Name and domain. * **Your column.** How you classify the account, shown as a status badge. * **Partner column.** Their classification, with its own list selector so you can compare against a specific list of theirs. * **Status.** The overlap verdict for this account. **Confirmed** means both sides have it. **Theirs only** means it's on their list and not yours, which is the new-logo opportunity. * **Events.** Which of your events this account's contacts have attended. * **Next Step.** Editable inline. Click **Add status** to set one. Use **Manage Columns** to change which fields appear. ### Coverage and Pipeline The bar at the bottom of the table is the point of the whole screen. Toggle between two lenses. **Coverage** answers whether you have actually reached the accounts available to you: * **Penetration.** The share of the working set you've reached. * **Coverage.** How many accounts you've reached, out of the total. * **Multi-touch.** Accounts reached more than once. * **Never reached.** Accounts with no touch at all. This is usually the number that starts the conversation. **Pipeline** shifts the same accounts onto revenue. Coverage leads by default, because for most partnerships the honest first answer is that a large share of the partner's list has never been touched. ### Save as List **Save as List** turns whatever the table is currently showing into a reusable [List](/docs/lists/overview). Filter down to the accounts you care about, save, and the list is available for invites, follow-up, and agents without rebuilding the query. This is the loop: map accounts, filter to the play, save the list, send the invites, and the attribution comes back to the same partner record. ### Activity **Activity** shows recent changes and status updates on this relationship, so a joint review can start from what moved since last time. ## Common setups * **Partner manager at a startup.** You have a handful of partners and no leverage to make any of them adopt a tool. Upload each one's account list as a portfolio, work the Coverage lens, and invite the partners who engage. * **VC and accelerator ecosystems.** The portfolio is the account list. Upload it, map it against your customers and pipeline, and the Never reached number tells you which portfolio companies have never been in a room with you. * **Established co-marketing partnership.** Both sides invited, both maintaining lists, Confirmed overlap on both columns, and Pipeline as the working lens. ## Global Prospect List Your master list of target companies at the workspace level. This is how you know which event attendees to prioritize. If someone registers for your event and they're on your prospect list, you know they matter. Each row shows Company, Relationship, Source, Vertical, and Events. **Adding prospects.** Click **Sync Events** to pull in companies from your connected event platform, **Upload CSV** to import a target account list, or **+ Add Prospect** for individual companies. CSV format, max 5MB. Headers: `company_name`, `website_domain`, `vertical`, `region`, `relationship`. Click **Download Template** in the upload modal for a pre-formatted file. Upload your existing customer list here too. Tagging accounts as Customer versus Prospect is what lets you see at a glance whether an event attendee is a new logo or an existing account. ## Settings tab Configure your ecosystem taxonomy. These settings apply across the workspace and define the labels, colors, and categories used in account mapping and in the filters above. * **Verticals.** Industry categories, for example Fintech, Gaming, Health & Wellness. * **Regions.** Geographic regions, for example LATAM, NAM, EMEA. * **Business Types.** Account relationship categories with custom labels, codes, and colors. Defaults are New Business, Existing Customer, and Expansion. * **Next Step.** Pipeline progression statuses. Defaults are Not Contacted, Intro Sent, and In Conversation. Add steps to match your sales workflow. * **Relationships.** How you and your partners categorize accounts: Customer, Prospect, and Partner. These appear as the color-coded badges in the mapping table. ## Plan availability ## Related * [Lists](/docs/lists/overview): the object Save as List produces and Working from consumes * [Adding and Inviting Partners](/docs/partner-ecosystem/adding-and-inviting-partners) * [Sponsor Mode](/docs/partner-ecosystem/sponsor-mode): control what partners and sponsors can see * [Event Attribution Funnel](/docs/features/event-attribution-funnel): what the partner relationship produced # Sponsor Mode Source: https://heybtw.com/docs/partner-ecosystem/sponsor-mode Control exactly what data sponsors and partners see. No more spreadsheets. # Sponsor Mode Sponsor Mode replaces spreadsheet-based data sharing with sponsors. Instead of downloading attendee lists, filtering columns, and emailing different files to different sponsors, you configure tiers and each sponsor only sees what their package includes. ## Turning On Sponsor Mode Open a collab and go to the **My Partners** tab. Toggle Sponsor Mode on. Configure your sub-features and sponsor tiers. Sponsor Mode is per-collab. You can have it on for a conference with 50 sponsors and off for a small co-marketing dinner. Sponsor Mode works across all supported event platforms. Whether your event was imported from Luma, Splash, or Zuddl, the same tier configuration and data visibility controls apply. ## Sub-Features When Sponsor Mode is enabled, these controls become available. **UTM Attribution.** Partner visibility based on UTM source tracking. Sponsors can see which attendees came through their specific UTM links, so they know which of their promotional channels drove registrations. When active, partners holding the **Partner Source View-Only** permission see only leads whose UTM source matches their configured tracking value. **Signup Quota.** Partners must drive a minimum number of signups to unlock attendee data. Set a threshold (e.g., "drive 10 signups to see the list"). Incentivizes sponsors to actively promote the event. **Show Questions to Partners.** Allow partners to see registration question answers. If your event registration includes questions like "What's your biggest challenge?" or "Which sessions interest you?", enabling this lets sponsors see those answers alongside attendee data. **Approval Voting.** Partners vote to approve or reject attendees. See [Approval Voting](/docs/features/approval-voting). **Sponsor Tiers.** Configure what data each tier can see. ## Partner Attendee Visibility Sponsor Tiers control which *fields* a partner sees. Partner Attendee Visibility controls which *people* they see, by attendee status, for both viewing and export. Three settings, from most private to most open: * **Approved only.** The safe default. Invited and pending guests stay hidden. * **Approved + Pending.** Adds guests awaiting approval. Invited stays hidden. * **All, including Invited.** Partners see your full invite list, the way co-hosts do in Luma. Best when you are coordinating invites together. This setting matters most when heyBTW has co-host access to your Luma event, because then your workspace holds the **full invite list**, including everyone you invited who never responded. That list is often the most sensitive thing in the collab. It is your target account list, readable as a spreadsheet. **Approved only** is the default for exactly that reason. Move to **All, including Invited** deliberately, and only with partners you are genuinely co-planning the guest list with. ### Preview what a partner sees The banner at the top of the tab shows whose view you are in, for example **Viewing as Collab Creator**. Use **Select partner to preview** to see the collab exactly as a specific partner sees it, with their tier and visibility settings applied. Do this once before you share a collab. It is faster than reasoning through the permission matrix, and it catches the mistake that actually matters, which is sharing more than you meant to. ## Setting Up Sponsor Tiers Tiers control data visibility. Each tier defines which attendee fields sponsors in that tier can access. **Default Tiers.** heyBTW comes with four tiers: Platinum, Gold, Silver, and Supporting. You can customize these or create your own. **Configuring Field Visibility.** For each tier, toggle access to individual attendee fields. The available fields include Name, Email, Phone, Company, Title, Status, Checked In, Partner Source, UTM Source, MQL, Meeting Booked, and Opportunity. You decide what makes sense for your event. A Platinum sponsor might see everything. A Silver sponsor might only see Company and Title. There's no fixed rule. Configure it to match your sponsorship packages. **"See Other Partners" Toggle.** Each tier has a "See other partners" toggle. When on, sponsors in that tier can see who the other sponsors are. When off, each sponsor only sees their own data. This also controls whether other sponsors appear in the Partner Ecosystem sidebar for that partner. ## Assigning Partners to Tiers Go to the **My Partners** tab in your collab. Use the Tier dropdown next to each partner. Select their tier (Platinum, Gold, Silver, Supporting). Each partner sees only what their tier allows. ## Permission Enforcement Tier permissions are enforced everywhere, not just the attendee table. **AI Insights.** When a sponsor asks a question in AI Event Attendee Insights, the AI only returns data from columns their tier has access to. If a sponsor asks for a restricted field, the AI responds with available alternatives rather than an error. **Exports.** CSV and Excel exports respect tier column restrictions. A Silver tier sponsor who exports the attendee list only gets the columns their tier permits. The collab creator's exports always include full data. **Partner Ecosystem.** When Sponsor Mode is on and a tier has "See other partners" turned off, sponsors in that tier cannot see other sponsors in the Partner Ecosystem dashboard. They only see the collab creator. This prevents competitors from discovering each other. **ABM.** The Account-Based Marketing tab respects the same visibility rules. Deleted sponsors are removed from ABM and Partner Source. ## What Sponsors Experience When a sponsor logs into their view of the collab, they see attendee data filtered to their tier's permissions. They can track whether their invites are converting (if UTM Attribution is enabled). They can connect their own CRM to track ROI from the event. They cannot see other sponsors' data or tier assignments. ## Approval Voting Approval Voting can be used alongside Sponsor Mode. When both are active, tier visibility controls which attendee data columns partners see, while vote columns are always visible to partners with voting rights. See [Approval Voting](/docs/features/approval-voting) for setup details. ## Why This Matters **For event organizers.** No more managing separate spreadsheets per sponsor. Configure tiers once, assign partners, done. You control when data gets released. Nothing is shared until you grant it. **For sponsors.** Real data they can connect to their pipeline. When sponsors can prove ROI, they renew at higher tiers. ## Use Cases **Customer Conferences.** 50+ sponsors across multiple tiers? Configure tiers that match your sponsorship packages. Each sponsor logs into their own view and sees only what they are entitled to. **Multi-City Roadshows.** Each city is a separate collab with the same tier configuration. Multi-city sponsors see all their locations in one place instead of getting separate exports per city. **Partner Events with Tiered Data Sharing.** Even for smaller events with 5-10 partners, Sponsor Mode beats emailing spreadsheets. Configure once, done.