.png)
mParticle Integration Guide
Integrate mParticle with enterprise systems through REST APIs, batch event ingestion, authenticated workflows, and selected webhook-style delivery patterns.
mParticle integration options at a glance
mParticle primarily supports REST-based integration through its Events API, Platform APIs, audience operations, and related configuration capabilities. Its Events API supports server-to-server event ingestion and bounded batch submissions, while platform access uses authenticated API requests with account permissions and, where applicable, OAuth-based access tokens. Selected mParticle integrations or features may provide webhook-style delivery or callbacks, but coverage must be verified for the specific object or destination. Martini can consume these APIs, expose receiving endpoints, validate and transform JSON payloads, submit event batches, orchestrate scheduled synchronization, and route failures for retry or replay.
| Integration point | Supported by mParticle? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | mParticle documents REST-based Events, Platform, audience, configuration, and related API operations. These APIs can support event ingestion, audience workflows, and account administration where enabled. | Martini can consume REST endpoints with HTTP methods, headers, JSON bodies, query parameters, authentication, response validation, and reusable workflow logic. |
| Bulk / async / batch APIs | Yes | The Events API supports server-to-server event submission, including batches of event data for backend ingestion, backfills, and replay workflows. | Martini can validate source events, construct bounded batches, submit them, classify failures, and retry eligible requests without blindly replaying successful data. |
| Webhooks / outbound callbacks | Limited | Webhook-style delivery or callback behavior may be available for selected mParticle integrations or features. It should not be assumed for every event or object. | Martini can expose an API or receive webhook-style requests through a workflow when the selected mParticle feature provides a supported callback, then validate and route the payload. |
| Authentication | Yes | Events API ingestion uses credentials associated with an mParticle input, commonly an API key and API secret. Platform APIs document token-based authentication, OAuth-based access, and account permissions. | Martini stores API keys, secrets, OAuth client credentials, and access tokens in protected secrets or environment configuration and applies them in REST workflows. |
| SDKs | Yes | mParticle provides SDKs for collecting data from supported application environments. SDK collection is generally implemented inside the application rather than by Martini. | Martini complements SDK collection by receiving server-side data, transforming payloads, orchestrating APIs, and applying governance before or after mParticle processing. |
| Database / analytics access | Limited | mParticle supports data warehouse and analytics destinations, but direct database access is not a general-purpose mParticle integration mechanism. | Martini can write transformed mParticle data to supported SQL databases after obtaining it through a documented API, export, or configured destination path. |
| File / attachment APIs | Not confirmed | No general-purpose file or attachment API was confirmed for mParticle core objects. | Martini can process files from other systems when required, but a file-based mParticle integration should be verified for the specific product feature before implementation. |
How mParticle exposes data and business events
mParticle REST APIs
mParticle’s primary integration model is REST-based. The documented API surface includes the Events API, Platform APIs, audience operations, and related configuration or operational functions, subject to account and product availability.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the selected mParticle endpoint, builds the request from canonical data, sends the REST call, validates the response, and routes authorization, validation, throttling, or service failures to appropriate handling paths.
Implementation sequence
mParticle Events API batches
The Events API supports server-to-server event ingestion and batch event submission. This is suitable for application activity, commerce events, historical backfills, reconciliation, and controlled replay.
Martini implementation pattern
Martini implementation pattern: an API-triggered or scheduled workflow collects source events, applies governance and schema rules, groups them into bounded batches, submits them to mParticle, and separates retryable failures from permanently rejected events.
Implementation sequence
Selected mParticle callbacks
mParticle may provide webhook-style delivery or callback behavior for selected integrations or features, but coverage is not universal across mParticle objects and events. Exact payloads, authentication, and retry behavior require feature-specific verification.
Martini implementation pattern
Martini implementation pattern: where a supported callback exists, Martini exposes a receiving API or webhook-triggered workflow, authenticates and validates the request, maps the payload to an internal model, and continues orchestration or downstream delivery.
Implementation sequence
Common mParticle integration patterns
Pattern 1: Send backend events to mParticle
When to use this pattern
Use this pattern when commerce, account, subscription, or application events originate in an internal system and must be collected in mParticle through server-to-server ingestion.
Integration direction
Example Mapping
| mParticle Field | Canonical Field | Target Field |
|---|---|---|
| eventName | event.name | event_name |
| customerId | user.customerId | user identity |
| occurredAt | event.occurredAt | event timestamp |
| properties | event.attributes | event attributes |
Martini implementation pattern
Martini exposes an API or receives source events, validates required identities and timestamps, normalizes names and attributes, applies consent rules, and submits the result to the Events API. Stable source identifiers and workflow state support safe retries and replay.
Martini capabilities used
- APIs
- workflows
- data mapping
- JSON handling
- business rules
- error handling
Pattern 2: Synchronize customer data in scheduled batches
When to use this pattern
Use this pattern for historical backfills, periodic reconciliation, migration from a legacy event platform, or reprocessing of data that previously failed.
Integration direction
Example Mapping
| mParticle Field | Canonical Field | Target Field |
|---|---|---|
| externalCustomerId | user.customerId | user identity |
| user.email | user identity | |
| lastActivityTime | event.occurredAt | event timestamp |
| activityType | event.name | event name |
Martini implementation pattern
A scheduled Martini workflow retrieves pages of source data, persists progress, transforms customer and activity structures, and submits controlled batches. It applies rate-aware scheduling, checkpointing, duplicate controls, and retry handling for transient failures.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data transformation
- batch orchestration
- monitoring
Pattern 3: Activate mParticle audiences downstream
When to use this pattern
Use this pattern when audience-related information must be moved from mParticle to a marketing, advertising, or analytics application, subject to the enabled account capabilities.
Integration direction
Example Mapping
| mParticle Field | Canonical Field | Target Field |
|---|---|---|
| audienceId | audience.id | segment or audience identifier |
| audienceName | audience.name | campaign audience name |
| userId | audienceMember.externalId | profile identifier |
| qualificationTime | audienceMember.qualifiedAt | membership timestamp |
Martini implementation pattern
Martini retrieves or receives supported audience data, checks consent and eligibility rules, maps identifiers to the downstream application, and submits activation requests. Destination errors are isolated from source retrieval failures and retained for review or retry.
Martini capabilities used
- REST API consumption
- workflow orchestration
- identity mapping
- business rules
- error handling
- audit logging
Pattern 4: Govern and fan out event data
When to use this pattern
Use this pattern when multiple applications send customer activity through a controlled integration layer before the data reaches mParticle or other destinations.
Integration direction
Example Mapping
| mParticle Field | Canonical Field | Target Field |
|---|---|---|
| sourceEventType | event.name | normalized event name |
| rawProperties | event.attributes | governed attributes |
| sourceCustomerKey | user.customerId | mParticle identity |
| consentStatus | privacy.consent | transmission decision |
Martini implementation pattern
Martini centralizes validation, field masking, consent enforcement, event normalization, source tagging, and routing to appropriate mParticle inputs. Rejected events are referenced safely for investigation, while retryable submissions follow controlled backoff and replay rules.
Martini capabilities used
- API façade
- workflows
- data governance
- mapping
- conditional routing
- retries
Applications commonly integrated with mParticle
mParticle commonly sits between digital data sources and customer engagement, advertising, analytics, and warehouse platforms. The exact destination capabilities depend on the enabled mParticle integrations, account configuration, and supported API operations.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer, account, lead, or campaign-related data with unified behavioral profiles and selected activation workflows. | Salesforce → Martini → mParticle | Martini consumes Salesforce data or receives source events, applies identity, consent, and field mappings, and submits compatible events or user data to mParticle. Responses and rejected payloads are logged for controlled replay. |
| Braze | Forward behavioral events, user attributes, and selected audience information to support lifecycle messaging and personalization. | mParticle → Martini → Braze | A Martini workflow retrieves or receives mParticle event and audience data where the account supports it, normalizes the engagement payload, applies destination rules, and calls Braze APIs with retry handling. |
| Google Ads | Activate qualified audiences and support advertising measurement using customer and behavioral data. | mParticle → Martini → Google Ads | Martini orchestrates audience retrieval or activation requests, validates identifiers and consent conditions, transforms the payload, and submits it to the configured Google Ads integration or API path. |
| Meta Ads | Support audience activation and conversion-related advertising measurement. | mParticle → Martini → Meta Ads | Martini applies audience eligibility and privacy rules, maps mParticle audience or event data to the required Meta Ads representation, and records delivery outcomes for retry or review. |
| Snowflake | Centralize customer and event data for analytics, governance, data engineering, and controlled replay workflows. | mParticle → Martini → Snowflake | Martini consumes a documented mParticle export or API response, transforms it into warehouse-ready structures, and writes it to Snowflake through supported database or API mechanisms. Direct mParticle database access is not assumed. |
| Segment | Coordinate or migrate event collection between customer-data platforms during modernization or consolidation projects. | Segment → Martini → mParticle | Martini receives Segment events, normalizes event names, identities, timestamps, and attributes, then submits bounded batches to the mParticle Events API while preserving source identifiers. |
| Iterable | Send behavioral data and audience attributes to support email, push, and lifecycle campaign orchestration. | mParticle → Martini → Iterable | Martini retrieves or receives supported mParticle data, applies campaign and consent rules, maps fields to Iterable requirements, and handles destination-specific failures separately from source ingestion errors. |
| Google Analytics 4 | Forward standardized behavioral events for analytics and campaign measurement. | mParticle → Martini → Google Analytics 4 | Martini transforms mParticle event names, parameters, timestamps, and identifiers into the configured analytics payload, applies filtering rules, and records responses for operational monitoring. |
How to build a mParticle integration in Martini
Objective
Establish authenticated access to the mParticle API or Events API input without embedding credentials in workflow definitions.
Instructions in Martini
- Identify the required mParticle API, input, account, and permission model
- Store API keys, API secrets, OAuth credentials, or access tokens in Martini secrets or protected environment configuration
- Configure the REST request with the required headers and authentication settings
- Confirm the account and endpoint permissions before processing production data
Objective
Select an event-driven, API-triggered, or scheduled entry point based on the synchronization requirement.
Instructions in Martini
- Use a Martini API or webhook-triggered workflow for incoming source events
- Use a scheduler for backfills, reconciliation, and periodic synchronization
- Use a supported callback only after verifying the selected mParticle feature provides it
- Define correlation identifiers and processing boundaries
Objective
Collect source events, mParticle API responses, audience information, or configuration data in a controlled manner.
Instructions in Martini
- Receive the source payload or retrieve data through the documented mParticle REST API
- Process pagination or continuation information for platform and audience operations
- Bound the amount of data held in a single workflow execution
- Persist checkpoints for long-running synchronizations
Objective
Coordinate validation, transformation, API calls, business rules, and downstream actions as a maintainable Martini workflow.
Instructions in Martini
- Separate ingestion, validation, mapping, submission, and error paths
- Use reusable workflow logic for common authentication, event normalization, or response handling
- Apply conditional routing for event categories, inputs, destinations, and failure classes
- Keep source and target concerns isolated through canonical data structures
Objective
Convert source data into mParticle event, identity, profile, audience, or configuration structures while preserving meaning and governance.
Instructions in Martini
- Map event names, attributes, timestamps, identities, devices, and application context
- Normalize time zones and identifier semantics
- Remove or mask fields that should not be transmitted
- Validate required fields and reject malformed data before submission
Objective
Enforce consent, eligibility, duplicate, routing, and replay policies before data is sent to mParticle or another destination.
Instructions in Martini
- Check consent and data-minimization conditions
- Apply stable source event identifiers and duplicate handling rules
- Route event categories to the appropriate mParticle input where configured
- Classify errors as retryable, permanent, or requiring operational review
Common mParticle data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Events | Behavioral or transactional activity containing event names, attributes, timestamps, identities, device data, and application context. | mParticle Events API, marketing platforms, analytics platforms, data warehouses | Martini validates and normalizes event schemas, applies consent and governance rules, constructs bounded batches, submits events, and records replay state. |
| User Profiles | User-level information assembled from identities, attributes, devices, and event activity. | mParticle, Salesforce, Braze, analytics platforms, data warehouses | Martini maps identity types and profile attributes carefully, removes or masks restricted fields, and synchronizes only the profile data supported by the target API. |
| Audiences | Groups of users qualified by behavioral, demographic, identity, or other criteria for downstream activation. | Advertising platforms, marketing platforms, analytics destinations | Martini can retrieve or receive audience-related data where supported, apply eligibility and consent rules, transform membership data, and call downstream APIs. |
| Connections | Configured destinations or integrations that receive data from mParticle. | Advertising, marketing, analytics, and data warehouse destinations | Martini can orchestrate configuration or operational workflows through documented platform APIs where the account exposes the relevant operations. |
| Inputs | Configured data ingestion sources, including server-to-server inputs and other collection sources. | Internal applications, mParticle Events API, mobile and web collection sources | Martini uses the appropriate input credentials for server-to-server ingestion and routes different event categories to the relevant input when configuration supports it. |
| Outputs | Delivery configurations that determine how mParticle sends data to downstream destinations. | Marketing, advertising, analytics, and warehouse systems | Martini can mediate, monitor, or supplement supported output workflows through APIs or callbacks, while treating destination-specific behavior as account-dependent. |
Authentication and security considerations
Authentication model
mParticle Events API ingestion commonly uses an API key and API secret associated with an input. Platform APIs use authenticated requests and may use OAuth 2.0 access tokens, account permissions, and API-specific authorization.
Martini security practices
- Store mParticle keys, secrets, OAuth credentials, tokens, and destination credentials in protected Martini secrets or environment configuration.
- Limit credentials to the API operations and account permissions required by the workflow.
- Apply consent and data-minimization rules before transmitting personal data.
- Avoid writing complete customer payloads or credentials to operational logs.
Operational considerations for mParticle integrations
Throughput and batching
Follow the documented mParticle Events API request, event-count, and payload-size limits. Use configurable batch sizes, controlled parallelism, and backoff after throttling or transient service responses.
State and duplication
Persist checkpoints, stable source event identifiers, and submission outcomes. Treat timeouts as unknown outcomes rather than automatically replaying an entire batch.
Pagination and schema changes
Platform and audience operations may paginate results. Persist progress and monitor for renamed attributes, changed identity semantics, new required fields, and destination configuration changes.
Testing and monitoring
Validate representative identities, timestamps, attributes, consent values, and batch behavior before production. Monitor workflow logs, rejected events, response classifications, and replay queues without exposing unnecessary personal data.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini provides a maintainable workflow layer for receiving source events, consuming mParticle REST APIs, submitting batches, applying governance rules, and coordinating downstream systems.
Reusable integration logic
Instead of duplicating authentication, mapping, retry, and validation code across point-to-point scripts, teams can reuse workflow assets and canonical transformations.
Operational control
Martini supports scheduled and event-driven execution, conditional routing, error paths, checkpoints, monitoring, and controlled replay for integration processes that must operate reliably over time.
Flexible API mediation
Martini can expose APIs for internal producers or supported callbacks, allowing mParticle integration behavior to be standardized without requiring a dedicated vendor connector.
Frequently asked questions
mParticle can be integrated primarily through REST APIs, including the server-to-server Events API for individual or batched event ingestion and Platform APIs for selected account, audience, and configuration operations. Selected integrations or features may also provide webhook-style callbacks, but availability must be verified for the specific use case.
Yes. Martini can integrate with mParticle by consuming its REST APIs, submitting authenticated event batches through the Events API, and orchestrating supported audience, configuration, or callback workflows. No native Martini mParticle connector is documented in the supplied materials.
No. A dedicated mParticle connector is not required. Martini can use mParticle’s confirmed native integration mechanisms, including REST APIs, Events API credentials, batch submission, and any verified webhook or callback endpoints.
Lonti does not charge an additional per-connector or per-vendor fee to integrate mParticle. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from mParticle, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
REST is the primary method for new mParticle integrations. Use the Events API for server-to-server event and batch ingestion, and use Platform or audience APIs for operations exposed by the account. mParticle SDKs are generally implemented inside applications, while Martini is suited to server-side orchestration and API mediation. GraphQL and SOAP are not confirmed or supported as general mParticle API models.
mParticle may provide webhook-style delivery or callbacks for selected integrations or product features, but it should not be assumed that every event or object produces a webhook. The exact event coverage, payload, authentication, and retry behavior must be verified for the selected feature. Martini can receive a supported callback through an API-triggered workflow.
Martini can receive or retrieve mParticle data, process pagination where applicable, map identities and event structures to a canonical model, apply consent and business rules, and write the result to another API, database, or supported destination. Scheduled workflows support reconciliation, backfills, and controlled replay.
Martini can classify authentication, validation, throttling, payload-size, service, and destination-specific errors; retry eligible transient failures with controlled backoff; and retain references to rejected data for review. Stable source event identifiers and persisted processing state help prevent unsafe duplicate submissions during timeout or replay scenarios.
Related Martini documentation
API Workflows
Workflows
Build a reliable mParticle integration with Martini
Use Martini to connect mParticle with enterprise applications through authenticated APIs, governed event workflows, batch synchronization, and reusable integration logic.