This document serves as the authoritative technical reference for the implementation, configuration, and maintenance of the native integration between the InEvent Virtual & Hybrid Event Platform and Adobe Marketo Engage. The primary objective of this integration is to establish a robust, automated data pipeline that eliminates manual CSV handling, ensures data integrity across the marketing technology stack, and enables granular attribution reporting.
In the modern marketing technology ecosystem, event data is often siloed, leading to fragmented customer profiles and inaccurate Return on Investment (ROI) calculations. This integration resolves these issues by establishing a clear data topology: InEvent functions as the Data Collection Layer, capturing high-fidelity interaction data (registrations, session attendance, poll responses, and physical booth visits), while Marketo functions as the System of Record and Orchestration Engine, responsible for lead lifecycle management, scoring, and multi-touch attribution.
The integration does not rely on a simple, flat-file transfer. Instead, it utilizes a sophisticated, bi-directional synchronization protocol leveraging the Marketo REST API and, where appropriate for high-volume data, the Bulk Import API.
The synchronization frequency is hybrid, designed to balance data immediacy with API quota governance:
Identity Resolution Events (Real-Time): Critical actions that require immediate automation—specifically Registration, Waitlisting, and initial Event Check-In—are triggered via real-time API calls. This ensures that when a user registers, they exist in Marketo within seconds, allowing "Confirmation" and "Know Before You Go" emails to be deployed immediately via Marketo Smart Campaigns.
Metadata & Engagement Logs (Batched): High-volume data points that are less time-sensitive—such as individual poll responses, Q&A submissions, and granular session view duration metrics—are processed in scheduled batches (typically hourly). This architectural decision prevents the exhaustion of the Marketo daily API quota (standard limit: 50,000 calls per day) during peak event activity.
By moving beyond binary "Registered/Attended" data points, this connector enables the "Success" attribution required for advanced reporting in Marketo’s Revenue Cycle Explorer (RCE). The integration automatically maps specific InEvent behavioral triggers to Marketo Program Member Statuses. This allows the attribution engine to distinguish between a "No Show," a passive "Attendee," and a highly engaged "Delegate," assigning appropriate revenue credit to the event based on the depth of interaction.
This section details the technical architecture of the data ingress and egress. The integration acts as a middleware layer that translates InEvent’s internal object structure into Marketo-compatible JSON payloads.
The connection is secured using industry-standard OAuth 2.0 protocol. The integration does not use Basic Auth. It requires the configuration of a "Custom Service" within Marketo’s LaunchPoint interface.
Token Exchange: The InEvent connector exchanges a Client ID and Client Secret for a Bearer Access Token.
Token Lifecycle: The Access Token is valid for 3,600 seconds (1 hour). The InEvent connector includes an automated token refresh mechanism. If a call fails due to an expired token (Error Code 601 or 602), the system automatically requests a new token and retries the operation without manual intervention.
Transport Security: All data in transit is encrypted via TLS 1.2 over HTTPS.
The inbound pathway is primarily utilized for Audience Segmentation and Streamlined Registration. It allows event managers to utilize Marketo’s complex filtering capabilities to define the invite list.
Mechanism: List Polling
The integration periodically polls specific Marketo Static Lists defined in the configuration. It is important to note that the API cannot efficiently poll "Smart Lists" in real-time due to the computational load required to calculate Smart List membership on the fly. Therefore, the architectural requirement is that audiences must be pushed to a Static List for ingestion.
Data Mapping Logic:
When a record is pulled from Marketo to InEvent, the system maps the following core attributes:
Marketo: FirstName maps to InEvent: First Name
Marketo: LastName maps to InEvent: Last Name
Marketo: Email maps to InEvent: Email (Primary Key)
Marketo: Company maps to InEvent: Company
Marketo: Title maps to InEvent: Job Title
The "Magic Link" Feedback Loop:
Upon importing a lead, InEvent generates a unique, tokenized URL known as a "Magic Link." This link contains an embedded authentication token specific to that user. The connector writes this URL back to a custom field on the Marketo Lead record (e.g., InEvent_Magic_Link__c). This allows Marketo to send email invitations where the Call-to-Action (CTA) is "One-Click Login," significantly reducing friction and increasing attendance rates.
The outbound pathway is the primary vector for data transfer, handling Lead Management and Activity Logging.
Deduplication Strategy:
The integration strictly uses Email Address as the unique identifier for deduplication. The system does not rely on the Marketo ID (mkto_id) for initial matching, as the InEvent platform captures users who may not yet exist in the Marketo database.
Scenario A (Existing Lead): The system queries Marketo for the email address. If a match is found, the system performs an Update operation.
Scenario B (New Lead): If no match is found, the system performs a Create operation.
Scenario C (Multiple Matches): If Marketo returns multiple records for a single email (possible in workspaces without strict dedupe rules), the connector updates the record with the most recent UpdatedAt timestamp, ensuring the active record is enriched.
The Upsert Payload:
The connector utilizes the syncLead REST API endpoint. The payload is constructed to respect Marketo’s "Block Field Updates" settings. If a field in Marketo is set to block updates from the API (to protect data from trusted sources like a CRM), the InEvent connector will fail gracefully on that specific field while successfully updating the remaining allowed fields.
Acquisition Program Association:
For every new lead created by InEvent, the system automatically sets the Acquisition Program attribute to the connected Marketo Program. This is a critical step for First-Touch Attribution. If the lead already exists, the Acquisition Program field remains untouched to preserve the historical source of the lead, complying with standard attribution best practices.
The accuracy of Marketo’s attribution reporting is entirely dependent on the Program Member Status. A simple binary status of "Member" or "Not Member" is insufficient for modern analytics. The InEvent connector utilizes a granular State Management Engine to map user behaviors to specific statuses in the Marketo Program Channel.
Before enabling the sync, the Marketo Architect must ensure the Program is using a Channel (e.g., "Webinar" or "Live Event") that has been configured with the necessary statuses. We recommend a channel strategy that separates "Registration" phases from "Attendance" phases.
The following details the logic governing how InEvent Actions translate to Marketo Statuses. This mapping is fully configurable within the InEvent integration dashboard, but the default configuration below is recommended for optimal Revenue Cycle analytics.
1. Registration Phase
InEvent Action: Form Submit
Description: User completes the registration form on the InEvent landing page.
Marketo Status: Registered
Step ID: 10
Success: False
System Logic: The system checks if the user is already on the list. If not, it adds them. If they are (e.g., they were "Invited"), it changes their status to "Registered."
InEvent Action: Waitlist Join
Description: The event capacity is reached, and the user opts to join the queue.
Marketo Status: Waitlisted
Step ID: 15
Success: False
System Logic: This status is crucial for suppressing "Confirmation" emails and triggering "You are on the list" emails via a Smart Campaign trigger Data Value Change: Status is Waitlisted.
2. Attendance Phase (The Success Trigger)
InEvent Action: Virtual Login
Description: User authenticates into the Virtual Lobby via the website or mobile app.
Marketo Status: Attended
Step ID: 20
Success: TRUE
System Logic: This is the primary "Success" event. When this status change occurs, Marketo’s attribution engine assigns credit to the program. This trigger should be used to stop "Reminders" and start "Thank You for Attending" workflows.
InEvent Action: Physical Check-In (QR Scan)
Description: User scans their unique QR code at a kiosk or is scanned by staff using the InEvent Access Control app.
Marketo Status: Attended (or Attended - In Person if granular tracking is desired)
Step ID: 20
Success: TRUE
System Logic: The sync latency for this action is prioritized to near real-time to ensure that if a user checks in, their status is updated immediately.
InEvent Action: Physical Check-Out
Description: User scans out of the venue.
Marketo Status: No change (typically), or Checked Out if tracking dwell time.
System Logic: Usually used for internal analytics rather than marketing status, but can be mapped if required for Continuing Education (CE) credit tracking.
3. Engagement Phase (Deep Analytics)
InEvent Action: Session View Duration (Threshold < 10%)
Description: User logs in but watches less than 10% of the content.
Marketo Status: Attended - Bounced
Success: True (Technically attended, but low value)
System Logic: Allows marketers to segment follow-up emails. "Bounced" users might receive a "Watch the Recording" email, while engaged users receive a "Download the Whitepaper" email.
InEvent Action: Session View Duration (Threshold > 75%)
Description: User watches the majority of the content.
Marketo Status: Attended - Engaged
Success: TRUE
System Logic: These are high-intent leads. This status change should trigger a "Lead Score" increase (e.g., +20 points).
4. Post-Event Reconciliation
InEvent Action: No Activity
Description: The event has concluded, and the user status remains at "Registered."
Marketo Status: No Show
Step ID: 30
Success: False
Standard Lead fields are flat; they describe the person (Who). They are incapable of describing complex, one-to-many behavioral data (What they did). If a lead attends a three-day conference with 15 sessions, overwriting a "Last Session Viewed" field 15 times results in a massive loss of intelligence.
To address this, the InEvent connector utilizes Marketo Custom Objects. This creates a relational database structure where a single Lead Record (Parent) is linked to multiple Activity Records (Children).
We recommend creating a unified Custom Object to house various interaction types. This reduces the administrative overhead of managing multiple object definitions.
Schema Definition:
Object Name: InEvent_Activity
API Name: InEventActivity_c
Link Field: Lead ID (The foreign key connecting the object to the person)
Deduplication Field: Activity_ID (A unique alphanumeric hash generated by InEvent, e.g., evt_123_sess_456_usr_789)
Field Specifications:
|
Field Friendly Name |
API Name |
Data Type |
Description |
|
Activity Type |
activityType |
String |
Categorizes the record (e.g., "Poll Response", "Session View", "Booth Scan"). |
|
Activity Name |
activityName |
String |
The human-readable title (e.g., "Keynote: Future of AI", "Booth: Adobe"). |
|
Activity Date |
activityDate |
Datetime |
The UTC timestamp of the interaction. |
|
Activity Value |
activityValue |
String |
The content of the interaction (e.g., the answer to the poll "Option B", or duration "45 mins"). |
|
Session ID |
sessionId |
String |
The system ID for the specific session. |
|
Event Name |
eventName |
String |
The name of the parent event. |
|
URL Asset |
assetUrl |
URL |
A direct link to the recording or resource (if applicable). |
Velocity Scripting in Email: By using Custom Objects, you can utilize Velocity Scripting (#foreach loops) in Marketo emails to print a dynamic list of every session a user attended in their "Post-Event Recap" email.
Example: "Hi John, here are the links to the 4 sessions you watched yesterday..."
Advanced Filtering: You can construct "Cross-Filter" logic.
Logic: Find all Leads who (Attended Event A) AND (Have an InEvent_Activity where Type is "Poll Response" and Value contains "Ready for Demo").
Lead Scoring 2.0: You can build scoring models that assign points based on the volume of Custom Objects.
Automation within Marketo is driven by the "Smart Campaign" engine. The InEvent connector enables two primary types of triggers: Program Status Changes and Data Value Changes. This section outlines the specific logic blocks required to operationalize the event data.
Behavioral scoring should reflect the intensity of engagement. A user who simply registers is less valuable than a user who attends, who is in turn less valuable than a user who asks a question.
Scenario: The Engagement Ladder
Logic Block 1: Registration (Interest)
Smart List Trigger: Program Status is Changed
New Status: Registered
Program: [Current Event]
Flow Step: Change Data Value
Attribute: Demographic Score
New Value: +5
Logic Block 2: Attendance (Action)
Smart List Trigger: Program Status is Changed
New Status: Attended
Program: [Current Event]
Flow Step: Change Data Value
Attribute: Behavior Score
New Value: +20
Logic Block 3: High Intent (Engagement)
Smart List Trigger: Added to Custom Object
Object: InEvent_Activity
Constraint: activityType is "Poll Response"
Constraint: activityValue contains "Sales"
Flow Step 1: Change Data Value
Attribute: Behavior Score
New Value: +50
Flow Step 2: Sync Person to SFDC
Action: Assign to Queue "Hot Leads"
Flow Step 3: Send Alert
Recipient: Lead Owner
Content: "Lead {{lead.LastName}} requested sales contact via Event Poll."
The connector supports the synchronization of custom attributes that can be utilized as tokens in Marketo assets. Using standard Marketo token syntax ({{my.token}} or {{lead.field}}), you can create a seamless user experience.
The "One-Click" Strategy:
To maximize attendance, authentication barriers must be removed.
InEvent Generation: InEvent generates a secure autologin link: https://event.inevent.com/login?token=abc123xyz
Sync: This string is synced to the Marketo field InEvent_Magic_Link.
Marketo Asset: The "Starting Now" email uses the token in the HTML button: <a href="{{lead.InEvent_Magic_Link}}">Join Session</a>.
Result: The user clicks the email and is immediately dropped into the video player, bypassing the password screen. This workflow historically increases attendance rates by 15-20%.
QR Code Integration:
For hybrid events, the check-in process can be streamlined by embedding the user's QR code directly in the email.
Sync: InEvent syncs the image URL of the QR code to InEvent_QR_URL.
Marketo Asset: The "Know Before You Go" email contains: <img src="{{lead.InEvent_QR_URL}}" alt="Your Ticket">.
For Enterprise Marketo instances, governance of the API pipeline is critical. An uncontrolled integration can consume the daily API quota, causing critical failures in other connected systems (e.g., Salesforce, Drift, Tableau).
Marketo enforces a strict daily limit on API calls, typically set at 50,000 calls per rolling 24-hour period for standard instances.
The "Throttling" Strategy:
The InEvent connector employs a sophisticated throttling and batching mechanism to respect these limits.
Priority Queue: "Program Status" updates (Registration/Check-In) are flagged as High Priority. These are sent immediately (1 call per lead) to ensure operational continuity.
Bulk Queue: "Activity Data" (Polls, Q&A, detailed analytics) are flagged as Low Priority. The connector aggregates these records into a CSV buffer. Once the buffer reaches a threshold (e.g., 1,000 records) or a time limit (e.g., 60 minutes), the connector utilizes the Marketo Bulk Import API.
Efficiency Gain: Creating 1,000 Custom Object records via the standard REST API requires 1,000 calls. Doing so via the Bulk Import API requires only 2 calls (1 to upload the file, 1 to trigger the import). This results in a 99.8% reduction in API consumption for high-volume datasets.
Network instability and API timeouts are inevitable. The connector includes robust error handling:
50x Server Errors: If Marketo returns a 502 (Bad Gateway) or 503 (Service Unavailable), the connector implements an "Exponential Backoff" strategy. It waits 30 seconds, retries. If it fails, it waits 60 seconds, then 120 seconds, up to a maximum of 5 attempts before logging a permanent failure.
6xx Token Errors: As mentioned in Section 2.1, 601 (Token Expired) triggers an automatic refresh flow.
1004 Lead Not Found: If an update is attempted on a lead that has been deleted in Marketo, the system logs the error but does not retry, preventing an infinite loop of failed calls.
The integration is designed to comply with global privacy regulations.
Unsubscribe Propagation (Bi-Directional):
Marketo to InEvent: If Unsubscribed is set to True in Marketo, the user is flagged in InEvent. The InEvent mailer will suppress any marketing-related communications to this user. Note: Transactional emails (Password Reset, Payment Confirmation) are generally exempt from this suppression under GDPR "Legitimate Interest" clauses, but this is configurable.
InEvent to Marketo: If a user unchecks the "Marketing Permissions" box during the InEvent registration process, the Unsubscribed field is updated to True in Marketo instantly.
Right to Be Forgotten:
If a user submits a deletion request:
Action: The Admin deletes the user in Marketo.
Sync: This does not automatically cascade to InEvent by default (to prevent accidental mass deletions). The Admin must manually anonymize or delete the record in the InEvent Data Privacy dashboard.
This section provides a step-by-step guide for the technical implementation. This procedure should be executed by a Marketo Admin and an InEvent Admin working in tandem.
Prerequisites:
Admin access to Marketo (ability to create LaunchPoint Services).
Admin access to InEvent (Organization Level).
A finalized list of custom fields to be mapped.
Navigate to Admin > Users & Roles.
Click Roles > New Role.
Role Name: InEvent API Role.
Permissions: Check the boxes for:
Access API
Read/Write Assets (for Program access)
Read/Write Person (for Lead access)
Read/Write Custom Object (if using Component 2)
Read/Write Activity
Click Create.
Navigate to Users > Invite New User.
Email: api-inevent@yourdomain.com (This should be a dummy email).
First Name: InEvent; Last Name: Integration.
Role: Select InEvent API Role.
API Only: Check this box (critical).
Click Invite.
Navigate to Admin > Integration > LaunchPoint.
Click New Service.
Display Name: InEvent Native Connector.
Service: Select Custom.
Description: Bi-directional sync for events.
API Only User: Select the user created in Step 1 (api-inevent@yourdomain.com).
Click Create.
Click View Details on the newly created service.
Copy the Client ID and Client Secret to a secure notepad.
Navigate to Admin > Integration > Web Services.
Copy the REST API Endpoint (usually ends in /rest).
Log in to InEvent and navigate to Account > Integrations.
Select Marketo from the CRM list.
Paste the Client ID, Client Secret, and Endpoint URL.
Click Link Account.
Wait for the confirmation message: "Connection Established Successfully."
In the Integration settings tab, locate the Field Mapping section.
Standard Fields: Ensure First Name, Last Name, and Email are mapped to their direct counterparts.
Custom Fields: Map any event-specific data (e.g., Ticket Type to Marketo Field: Event Ticket Type).
Warning: Ensure data types match. Do not map an InEvent "Text" field to a Marketo "Date" field, as this will cause sync errors.
Locate the Status Mapping tab.
For the specific event, ensure the dropdowns align with the matrix defined in Section 3.2.
Form Submit maps to Registered.
Check-In maps to Attended.
No Show maps to No Show.
In Marketo, go to Admin > Munchkin and copy the Munchkin ID (Format: 123-ABC-456).
In InEvent, paste this ID into the Tracking Pixel field. This enables web activity tracking on registration pages.
Select the target Marketo Program from the dropdown list. If the list is empty, click "Refresh Programs" to trigger an API call to fetch the list of available programs from Marketo.
Never turn on a sync for a live event without a dry run.
Create Test User: Register a user with email test.user+01@yourdomain.com on the InEvent landing page.
Verify Lead Creation: Search for this email in Marketo. It should appear within 60 seconds.
Verify Program Status: Check the "Members" tab of the Marketo Program. The user should be there with status Registered.
Simulate Check-In: In the InEvent backend, manually change the user status to "Checked In."
Verify Status Change: Refresh Marketo. The status should change to Attended.
1. How does the system handle "Partitions" and "Workspaces" in Marketo?
Answer: Marketo Workspaces are strict boundaries. The API User created in Step 1 is assigned a Role. That Role has access to specific Workspaces. If your event program lives in the "EMEA Workspace," but the API User only has access to the "North America Workspace," the connector will not be able to see the program or sync leads to it.
Solution: Ensure the API Role is granted access to all relevant Workspaces where event programs will reside. Alternatively, create separate API Users for different regional workspaces if strict data segregation is required.
2. What happens if I manually change a status in Marketo? Will InEvent overwrite it?
Answer: InEvent treats itself as the "Source of Truth" for event activity. If a user scans a QR code, InEvent will push the Attended status. If a marketer manually changes that person back to Registered in Marketo, InEvent will not automatically revert it unless a new trigger event occurs (e.g., they scan the code again). However, the next time a full sync runs (if "Force Sync" is selected), the status may be overwritten to match the reality of the event data. It is recommended to avoid manual status manipulation in Marketo during the active event window.
3. How are "Cookies" and "Known Web Activity" handled?
Answer: The connector supports the Munchkin association. When a user registers on an InEvent page, the InEvent form submits the data along with the browser's cookie info (if Munchkin is enabled). This allows Marketo to associate previous anonymous web activity (e.g., visiting the pricing page 3 times last week) with the newly created known lead. This is vital for "Lead Lifecycle" reporting.
4. Can we map one InEvent event to multiple Marketo Programs?
Answer: No. The architecture is strictly 1:1 (One InEvent Project to One Marketo Program). This ensures data cleanliness. If you have a complex event structure (e.g., a Parent Event with 5 sub-tracks), we recommend syncing to a single Parent Program in Marketo and utilizing "folders" or "categories" within Custom Objects to distinguish between tracks, rather than creating 5 separate programs which complicates the sync logic.
5. What is the maximum file size for the Bulk Import?
Answer: Marketo’s Bulk Import API has a hard limit of 10MB per file. The InEvent connector automatically segments data. If a batch of poll responses exceeds 10MB, the connector splits it into multiple files (Chunking) and queues them sequentially. No configuration is required by the user to handle this; it is native to the connector's logic.
6. Does the connector support "Person Partitions" (Lead Partitions)?
Answer: Yes. When a new lead is created via the API, Marketo’s internal "Lead Partition Assignment Rules" will automatically route the lead to the correct partition based on the data provided (e.g., Country or Domain). The connector does not force a partition; it respects the logic defined in your Marketo instance. However, the API User must have visibility into the partition where the lead lands, or it will return a "Lead Not Found" error on subsequent updates.
7. Can I sync "Guest" data (people who did not register but attended)?
Answer: Yes. If you allow "Walk-Ins" at a physical event who register at the kiosk, InEvent captures their data and pushes it to Marketo as a New Lead with the status Attended immediately. The Acquisition Date will be the timestamp of their walk-in.
