Connect Eventbrite with Salesforce

Implementation Guide

Overview: Connecting Eventbrite and Salesforce

Event-driven demand generation is one of the highest-intent lead acquisition channels available to B2B SaaS organisations. A registrant who signs up for a webinar, product demo event, or industry conference has self-selected into a high-consideration state. Yet in most organisations, the data from those registrations sits siloed in Eventbrite, disconnected from the Salesforce CRM where sales pipeline, lead scoring, and campaign attribution are managed. The result is a broken handoff: marketing teams manually export CSV files from Eventbrite and import them into Salesforce after each event, losing real-time context, creating data hygiene problems, and making it impossible to act on registrant intent while it is still fresh.

Connecting Eventbrite to Salesforce programmatically closes this loop. Registrations flow into Salesforce as Leads or Contacts in real time. Attendance status updates automatically. Campaign attribution is logged accurately. And post-event follow-up workflows can be triggered within minutes of an attendee checking in or an order completing. This guide provides the full implementation specification for a production-grade Eventbrite-to-Salesforce integration.

Core Prerequisites

Eventbrite Requirements:

  • An Eventbrite account with Organisation Admin access, which grants the ability to manage API keys and webhooks at the organisation level. Event-level access is insufficient for configuring webhooks programmatically.
  • An Eventbrite API Key (also referred to as a Private Token), generated at eventbrite.com/platform/api-keys. This key authenticates all REST API calls to the Eventbrite v3 API.
  • Familiarity with the Eventbrite API's core object model: Event (the event listing), Order (a completed ticket purchase), Attendee (an individual ticket holder within an order — one order can contain multiple attendees), and Webhook (an event-triggered HTTP notification).
  • Webhook endpoints registered via POST https://www.eventbriteapi.com/v3/webhooks/ must be HTTPS and must respond with HTTP 200 within 60 seconds.

Salesforce Requirements:

  • A Salesforce org with System Administrator profile, or a custom profile with the following permissions: API Enabled, Modify All Data (or granular create/edit permissions on Lead, Contact, Campaign, CampaignMember, and Task objects), and Manage Connected Apps (for OAuth configuration).
  • A Salesforce Connected App configured in Setup > App Manager, with the following OAuth scopes enabled: api (access and manage your data), refresh_token, offline_access (for long-lived integrations), and web (if using a web-based OAuth flow). For server-to-server integrations, configure the Connected App for JWT Bearer Flow, which requires uploading a certificate and avoids interactive OAuth consent.
  • The Consumer Key (Client ID) and Consumer Secret (Client Secret) from the Connected App, plus the Salesforce instance URL (e.g., https://your-org.my.salesforce.com).
  • Knowledge of the target Salesforce Campaign ID for event attendees. Leads or Contacts created from Eventbrite registrations should be added as Campaign Members to a corresponding Salesforce Campaign, enabling proper attribution reporting.
  • If using Salesforce's Duplicate Management rules, understand how your org handles potential duplicates on Lead/Contact creation — the integration must either use Salesforce's Find Duplicates API or implement its own deduplication logic (typically by querying on email address before creating a new Lead).

Data Mapping Prerequisites:

  • A documented field mapping between Eventbrite's attendee profile fields and Salesforce Lead/Contact fields. At minimum: Eventbrite first_name → Salesforce FirstName, last_name → LastName, email → Email, answers (custom question responses) → custom Salesforce fields. Custom questions configured on your Eventbrite event form will appear in the attendee's answers array in the API response.

Top Enterprise Use Cases

1. Real-Time Lead Creation from Event Registration The primary and most universally valuable use case. The moment an attendee completes an order on Eventbrite, the integration queries the Eventbrite API for the full attendee profile, maps the fields to a Salesforce Lead record, checks for an existing Lead or Contact by email address to avoid duplicates, and either creates a new Lead or updates the existing record with event participation data. This eliminates the post-event CSV import cycle entirely.

2. Campaign Member Attribution and Multi-Touch Reporting Each Eventbrite event maps to a Salesforce Campaign. When a Lead or Contact is created or identified from an Eventbrite registration, the integration creates a Campaign Member record linking them to the campaign, setting the Status field to Registered. When the attendee checks in at the event (via Eventbrite's check-in feature), the integration updates the Campaign Member status to Attended. This two-state model enables accurate multi-touch attribution reporting in Salesforce, distinguishing between registrants who attended and those who did not.

3. Opportunity Creation for High-Value Event Participants For enterprise sales events such as executive briefings or paid conference tiers, the integration can be configured to automatically create a Salesforce Opportunity when a specific ticket tier is purchased. The Opportunity is created with a stage of Event Qualified Lead, linked to the Account (if one exists for the attendee's email domain), and assigned to the relevant Account Executive based on territory mapping rules.

4. Post-Event Follow-Up Task Automation After an event concludes, the integration can query Eventbrite for the complete list of checked-in attendees and create a Salesforce Task (activity) on each corresponding Lead or Contact, assigned to the owning Sales Rep, with a subject of Follow up: [Event Name] and a due date of 2 business days post-event. This replaces manual post-event follow-up assignment by sales management.

5. No-Show Re-Engagement Campaigns By comparing the list of Eventbrite registrants against the list of attendees who actually checked in, the integration can identify no-shows and add them to a Salesforce Campaign with a No-Show status, which triggers an automated re-engagement email series (via Salesforce Marketing Cloud or Pardot) offering on-demand event content or a reschedule invitation.

Step-by-Step Implementation Guide

Phase 1: Authenticate with Eventbrite and Register a Webhook

All Eventbrite API calls use the private token in the Authorization header. To register a webhook that fires when a new order is completed, make the following API call. Replace YOUR_EVENTBRITE_TOKEN with your private token and YOUR_EVENT_ID with the numeric Eventbrite event ID:

curl -X POST https://www.eventbriteapi.com/v3/webhooks/ \
  -H 'Authorization: Bearer YOUR_EVENTBRITE_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "endpoint_url": "https://integrate.yourdomain.com/webhooks/eventbrite",
    "actions": "order.placed,attendee.updated,barcode.checked_in",
    "event_id": "123456789"
  }'

Eventbrite webhooks send a minimal notification payload — they do not include the full order or attendee data. Instead, they include a api_url field that you must use to fetch the complete resource from the Eventbrite API. This is a pull-on-push pattern that is common in webhook architectures.

A sample Eventbrite webhook notification payload for an order.placed event looks like this:

{
  "api_url": "https://www.eventbriteapi.com/v3/orders/9988776655/",
  "config": {
    "action": "order.placed",
    "endpoint_url": "https://integrate.yourdomain.com/webhooks/eventbrite",
    "user_id": "111222333",
    "webhook_id": "44455566"
  }
}

Upon receiving this payload, your middleware must immediately return HTTP 200, then asynchronously make a GET request to the api_url to retrieve the full Order object, including the attendees expansion:

curl -X GET "https://www.eventbriteapi.com/v3/orders/9988776655/?expand=attendees,event" \
  -H 'Authorization: Bearer YOUR_EVENTBRITE_TOKEN'

This returns the complete Order with nested attendees array, each containing a profile object with the registrant's name, email, and custom question answers.

Phase 2: Authenticate with Salesforce Using OAuth 2.0

For a production integration, use the JWT Bearer Flow to obtain a Salesforce access token without interactive login. This flow requires a Connected App configured with a certificate and a service account user authorised for that Connected App. The JWT assertion is signed with the private key corresponding to the uploaded certificate:

const jwt = require('jsonwebtoken');
const axios = require('axios');

const claim = {
  iss: process.env.SF_CLIENT_ID,
  sub: process.env.SF_SERVICE_ACCOUNT_USERNAME,
  aud: 'https://login.salesforce.com',
  exp: Math.floor(Date.now() / 1000) + 300
};

const token = jwt.sign(claim, process.env.SF_PRIVATE_KEY, { algorithm: 'RS256' });

const response = await axios.post('https://login.salesforce.com/services/oauth2/token', null, {
  params: {
    grant_type: 'urn:ietf:params:oauth:grant-type:jwt-bearer',
    assertion: token
  }
});

const accessToken = response.data.access_token;
const instanceUrl = response.data.instance_url;

Store the accessToken and instanceUrl values. Salesforce access tokens obtained via JWT Bearer Flow are valid for a session duration defined by your org's session settings (typically 2 hours). Re-execute the JWT exchange when you receive a 401 response.

Phase 3: Deduplicate and Upsert the Salesforce Lead

Before creating a new Lead, query Salesforce for an existing Lead or Contact with the same email address. Using the Salesforce REST API's SOQL query endpoint:

curl -X GET "https://your-org.my.salesforce.com/services/data/v59.0/query/?q=SELECT+Id,+FirstName,+LastName,+Email,+RecordTypeId+FROM+Lead+WHERE+Email+=+'[email protected]'+AND+IsConverted+=+false+LIMIT+1" \
  -H 'Authorization: Bearer YOUR_SF_ACCESS_TOKEN'

If a matching Lead exists, perform a PATCH (update) to add event data to custom fields. If no match is found, perform a POST to create a new Lead. Using Salesforce's Upsert operation with an external ID field is the cleanest approach if you add a custom Eventbrite_Order_ID__c field to the Lead object and mark it as an External ID in Salesforce:

curl -X PATCH "https://your-org.my.salesforce.com/services/data/v59.0/sobjects/Lead/Eventbrite_Order_ID__c/9988776655" \
  -H 'Authorization: Bearer YOUR_SF_ACCESS_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "FirstName": "Jane",
    "LastName": "Doe",
    "Email": "[email protected]",
    "Company": "Acme Corporation",
    "LeadSource": "Event",
    "Eventbrite_Event_Name__c": "ArcIntegrate Summit 2026",
    "Eventbrite_Registration_Date__c": "2026-04-21T09:00:00Z",
    "Eventbrite_Ticket_Class__c": "VIP"
  }'

The upsert endpoint uses HTTP 204 (No Content) for updates and HTTP 201 (Created) for new records, allowing your middleware to distinguish between the two outcomes for logging purposes.

Phase 4: Create Campaign Member Record

After the Lead upsert, add the Lead to the corresponding Salesforce Campaign:

curl -X POST "https://your-org.my.salesforce.com/services/data/v59.0/sobjects/CampaignMember/" \
  -H 'Authorization: Bearer YOUR_SF_ACCESS_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "CampaignId": "7013X000001AbCdEAB",
    "LeadId": "00Q3X000002XyZaUAC",
    "Status": "Registered"
  }'

If the Lead has already been converted to a Contact, use ContactId instead of LeadId. Note that a Campaign Member record cannot have both LeadId and ContactId populated simultaneously — Salesforce enforces this constraint at the platform level and will return a validation error if both are provided.

Phase 5: Make (Integromat) Module Configuration

In Make, implement this integration using the following module chain. Begin with a Webhooks > Custom Webhook trigger. Set the webhook URL in Eventbrite's webhook configuration as described above. Follow with an HTTP > Make a Request module configured as GET to the api_url value parsed from the webhook body, with the Eventbrite Authorization: Bearer header set. Pass the resulting JSON through a JSON > Parse JSON module scoped to the Order and Attendees schema. Use an Iterator module to loop over the attendees array (handling multi-ticket orders). Connect to a Salesforce > Search Records module querying for existing Leads by email. Use a Router to branch: one path for existing records using Salesforce > Update a Record, another for new records using Salesforce > Create a Record. Terminate both branches with a Salesforce > Create a Record module for the CampaignMember object.

Common Pitfalls & Troubleshooting

Eventbrite Webhook Not Firing for Specific Events Eventbrite webhooks are registered at either the organisation level or the individual event level. If you registered the webhook with a specific event_id, it will only fire for orders on that event. For new events created after the webhook was registered, you must either register a new webhook for each event or switch to an organisation-level webhook that covers all events under your account. Organisation-level webhooks are created by omitting the event_id field from the registration payload.

HTTP 401 Unauthorized from Salesforce After Initial Success Salesforce access tokens obtained via JWT Bearer Flow expire based on your org's session timeout settings. If your middleware runs continuously and caches the token in memory, the token will eventually expire. Implement a token refresh interceptor that catches any 401 response, re-executes the JWT Bearer Flow to obtain a fresh token, updates the cache, and retries the failed request automatically.

Salesforce Duplicate Rule Blocking Lead Creation (HTTP 400) If your Salesforce org has active Duplicate Rules configured on the Lead object, attempting to create a Lead whose email matches an existing record will return HTTP 400 with an error code of DUPLICATES_DETECTED. Your integration must either set allowSave: true in the request body to override the rule (if your org policy permits), implement pre-creation deduplication via SOQL query (as described in Phase 3), or use the Upsert pattern with an external ID field, which naturally handles the create-vs-update decision.

Multi-Attendee Orders Creating Duplicate Campaign Members Eventbrite supports group registrations where one order contains multiple attendees (e.g., one purchaser buying 5 tickets). If your integration processes the order-level event and creates one Lead per order rather than one Lead per attendee, you will miss individual attendees. Process the attendees array from the expanded Order object, creating one Lead and one Campaign Member per attendee. Conversely, if you subscribe to both order.placed and attendee.updated webhooks, you risk processing the same attendee twice. Choose one event type as your canonical trigger for Lead creation.

HTTP 429 Rate Limiting from Eventbrite API Eventbrite's REST API enforces rate limits of approximately 1,000 requests per hour per token. For large events with thousands of registrants where you are fetching full Order objects for each webhook notification, you can approach this limit. Implement request queuing with a rate limiter that caps outbound Eventbrite API calls to no more than 15 per minute, providing comfortable headroom below the hourly limit.