.png)
MoEngage Integration Guide
Connect MoEngage customer profiles, behavioral events, campaigns, and engagement data with enterprise systems through REST APIs, selected webhook scenarios, and scheduled workflows.
MoEngage integration options at a glance
MoEngage primarily integrates through REST APIs for creating and updating Users, sending Events, managing user attributes, and performing selected campaign or engagement operations. Selected MoEngage features also provide webhook-style notifications or callbacks, although coverage is not universal across users, events, campaigns, and segments. Batch or bulk ingestion may be available for particular workloads and account configurations. APIs commonly use an API ID and API key with HTTP authentication, and endpoints can vary by region. Martini can consume these APIs, receive supported callbacks, schedule reconciliation workflows, transform payloads, apply business rules, and route throttling or validation failures for controlled retry.
| Integration point | Supported by MoEngage? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Create or update Users and user attributes, send Events, delete user data, and perform selected campaign or engagement operations. | Martini can consume MoEngage REST endpoints, map request and response payloads, apply business rules, and route errors for retry or review. |
| Webhooks and outbound callbacks | Limited | Selected campaign, engagement, or feature-specific scenarios may provide webhook-style notifications or callbacks. | Martini can expose an API endpoint to receive documented callbacks, validate requests, correlate them, and invoke downstream workflows. |
| Bulk, asynchronous, and batch APIs | Limited | Selected data-ingestion or profile-update workloads may support batch or bulk processing, subject to API and account configuration. | Martini can orchestrate batches, control concurrency, track partial results, and retry failed items without resubmitting completed work. |
| Authentication | Yes | MoEngage APIs commonly use an API ID and API key with HTTP authentication; endpoint and credential requirements vary by API and region. | Martini can keep credentials and regional base URLs in secrets or environment configuration and apply them to outbound API calls. |
| Scheduled synchronization | Yes | Polling, reconciliation, campaign-result retrieval, and batch ingestion can be scheduled when an outbound event is unavailable or incomplete. | Martini can run scheduled workflows, persist pagination or extraction checkpoints, and coordinate repeatable synchronization. |
| File import/export | Limited | File-based imports or exports may exist for particular products or account configurations, but no general-purpose file API was confirmed. | Martini can process documented files when the selected MoEngage feature supports them, while keeping the file contract explicit and testable. |
| Database access | Not confirmed | Direct customer-facing database access was not confirmed; integrations should use MoEngage APIs or documented export mechanisms. | Martini should use supported APIs or exports rather than attempting direct database connectivity to MoEngage. |
How MoEngage exposes data and business events
MoEngage REST APIs
REST is MoEngage’s primary confirmed integration mechanism. Its APIs support user-profile updates, user attributes, behavioral Events, deletion operations, and selected campaign or engagement functions. Exact operations depend on the API family, version, region, and account configuration.
Martini implementation pattern
Martini implementation pattern: Martini workflows receive source changes or scheduled work, normalize identifiers and timestamps, map data into MoEngage payloads, call the regional REST endpoint with protected credentials, and route responses according to status, retryability, and business rules.
Implementation sequence
MoEngage webhook-style callbacks
MoEngage supports webhook-style capabilities in selected engagement, campaign, or feature-specific scenarios. This is not confirmed as a universal notification mechanism for every User, Event, Campaign, or Segment change.
Martini implementation pattern
Martini implementation pattern: expose a controlled Martini API endpoint for the documented callback, authenticate and validate the request according to the applicable contract, correlate the notification, and invoke a workflow for downstream synchronization or business processing.
Implementation sequence
MoEngage batch and scheduled synchronization
MoEngage may provide batch or bulk ingestion for selected profile and data-import workloads, while scheduled retrieval is useful for reconciliation and campaign or engagement reporting. Availability and limits vary by API and account configuration.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that reads source batches or paginated MoEngage results, transforms each item, controls concurrency, records checkpoints, and isolates failed items for retry without replaying completed work.
Implementation sequence
Common MoEngage integration patterns
Pattern 1: Synchronize customer profiles to MoEngage
When to use this pattern
Use this pattern when Salesforce, Shopify, NetSuite, or another customer system is the system of record for profile data and MoEngage needs current Users and user attributes for segmentation and engagement.
Integration direction
Example Mapping
| MoEngage Field | Canonical Field | Target Field |
|---|---|---|
| customer_id | customerId | User customer identifier |
| emailAddress | User email | |
| subscription_status | consentStatus | User attribute subscription status |
| updated_at | profileUpdatedAt | Profile update timestamp |
Martini implementation pattern
A Martini workflow receives a source change or runs on a schedule, normalizes identity and consent fields, validates required data, and calls the MoEngage REST API. Business rules suppress ineligible updates, while correlation keys and retry state prevent duplicate processing after timeouts.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- secrets management
Pattern 2: Send behavioral events from commerce or applications
When to use this pattern
Use this pattern when application, commerce, support, or event-stream activity should drive MoEngage segmentation and customer engagement.
Integration direction
Example Mapping
| MoEngage Field | Canonical Field | Target Field |
|---|---|---|
| order_id | transactionId | Event transaction identifier |
| customer_id | customerId | Event User identifier |
| completed_at | eventTimestamp | Event timestamp |
| total_price | amount | Event amount property |
Martini implementation pattern
Martini consumes a webhook, message, or API result, validates the event name and customer identity, normalizes timestamps and properties, and submits the Event to MoEngage. Stable source event IDs support duplicate detection, while throttling and transient failures are handled with bounded retries.
Martini capabilities used
- workflows
- API consumption
- JSON handling
- data transformation
- validation
- retry handling
Pattern 3: Trigger eligible MoEngage campaign activity
When to use this pattern
Use this pattern when a business application needs to start a post-purchase, onboarding, renewal, or re-engagement action through a supported MoEngage campaign-related API.
Integration direction
Example Mapping
| MoEngage Field | Canonical Field | Target Field |
|---|---|---|
| account_id | customerId | Campaign User identifier |
| lifecycle_state | eligibilityState | Campaign eligibility input |
| campaign_code | campaignReference | MoEngage campaign identifier |
| request_id | correlationId | Integration audit key |
Martini implementation pattern
A Martini API or workflow receives the business request, verifies identity, consent, campaign eligibility, and required campaign references, then invokes the documented MoEngage operation. The workflow records the correlation ID and separates validation failures from retryable transport errors.
Martini capabilities used
- APIs
- workflows
- business rules
- data mapping
- authentication
- error handling
Pattern 4: Reconcile campaign and engagement results
When to use this pattern
Use this pattern when available MoEngage campaign or engagement information must be synchronized to a CRM, warehouse, service platform, or reporting store.
Integration direction
Example Mapping
| MoEngage Field | Canonical Field | Target Field |
|---|---|---|
| campaign_id | campaignId | Campaign reference |
| user_id | customerId | Customer key |
| engagement_status | engagementStatus | Lifecycle or engagement status |
| event_time | occurredAt | Interaction timestamp |
Martini implementation pattern
A scheduled Martini workflow retrieves available results through the relevant MoEngage API, follows documented pagination, transforms records into the target model, and writes them to the destination. Checkpoints, idempotent upserts, and reconciliation reports make restarts safe and expose incomplete extraction.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data mapping
- database or API writes
- monitoring
Applications commonly integrated with MoEngage
MoEngage commonly participates in customer-data, commerce, support, analytics, and event-driven architectures. Martini can mediate these flows using each application’s supported APIs, webhooks, files, or messaging interfaces rather than requiring a dedicated MoEngage connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer profiles, lifecycle status, sales activity, and engagement outcomes. | Salesforce → Martini → MoEngage | Use Salesforce-triggered or scheduled workflows to normalize customer data, map it to MoEngage Users and user attributes, and optionally send campaign or engagement outcomes back to Salesforce with correlation and retry handling. |
| Shopify | Send customer, product, order, and purchase activity to MoEngage for segmentation and engagement. | Shopify → Martini → MoEngage | Receive supported Shopify events or poll Shopify APIs, validate customer identity and consent, transform order activity into MoEngage Events, and use bounded retries for transient API failures. |
| Segment | Forward normalized customer profiles and behavioral events into MoEngage from a centralized event pipeline. | Segment → Martini → MoEngage | Expose or consume the applicable Segment event interface, apply event-name and attribute governance, deduplicate by source event ID, and invoke the relevant MoEngage REST API. |
| Snowflake | Centralize MoEngage customer and engagement data for analytics and prepare governed audience or profile updates. | MoEngage → Martini → Snowflake | Run scheduled Martini workflows to retrieve available MoEngage results, transform them into warehouse models, and write them to Snowflake while tracking pagination and extraction checkpoints. |
| BigQuery | Support campaign, user, and event analytics, attribution, and reporting. | MoEngage → Martini → BigQuery | Retrieve available campaign or engagement data, normalize timestamps and identifiers, and load analytical tables through the supported BigQuery interface with restartable batch processing. |
| Zendesk | Use support interactions and ticket status to personalize engagement or suppress inappropriate campaigns. | Zendesk → Martini → MoEngage | Consume relevant Zendesk changes, map support status and customer identifiers to MoEngage Events or user attributes, and apply consent and suppression rules before submission. |
| NetSuite | Use customer, order, invoice, or subscription information to drive lifecycle messaging and transactional engagement. | NetSuite → Martini → MoEngage | Retrieve NetSuite changes through its supported API, normalize commerce and subscription data, and send eligible profile updates or Events to MoEngage with validation and retry routing. |
| Kafka | Stream application and transaction events through an enterprise event backbone before forwarding selected events to MoEngage. | Kafka → Martini → MoEngage | Consume messages from Kafka, validate event schemas and customer identifiers, transform approved events into MoEngage payloads, and isolate poison messages or throttled requests for operational handling. |
How to build a MoEngage integration in Martini
Objective
Establish the MoEngage API connection using the correct regional endpoint and application credentials without embedding secrets in workflow logic.
Instructions in Martini
- Configure the MoEngage base URL for each environment.
- Store the API ID and API key in Martini secrets or environment configuration.
- Apply the documented HTTP authentication requirements for the selected API.
- Confirm permissions for Users, Events, Campaigns, Segments, or reporting operations.
Objective
Select an event-driven, callback, API-led, or scheduled starting point based on the MoEngage capability and source-system contract.
Instructions in Martini
- Use a source webhook, message, or application API when near-real-time processing is required.
- Use a documented MoEngage callback only for supported feature-specific scenarios.
- Use a scheduler for polling, reconciliation, or batch synchronization.
- Define correlation and checkpoint fields before processing data.
Objective
Receive or retrieve the source payload and obtain additional MoEngage data when the notification or source record is incomplete.
Instructions in Martini
- Validate the incoming request or message before processing.
- Follow MoEngage pagination using its documented page, cursor, or offset model.
- Persist the last successful page, cursor, or batch checkpoint.
- Avoid treating a timestamp alone as a pagination mechanism.
Objective
Coordinate validation, enrichment, API calls, routing, and persistence in a maintainable Martini workflow.
Instructions in Martini
- Separate transport, transformation, business rules, and target writes into clear stages.
- Use reusable workflow logic for common identity and event handling.
- Control concurrency for high-volume ingestion.
- Attach correlation IDs to each significant operation.
Objective
Convert source customer, profile, event, campaign, and engagement models into the MoEngage API contract.
Instructions in Martini
- Map authoritative customer identifiers to MoEngage Users.
- Normalize timestamps, event names, data types, and consent fields.
- Validate required attributes and event properties.
- Keep versioned mappings for changes to the MoEngage API family or source schema.
Objective
Ensure only valid, permitted, and eligible information is sent to MoEngage or downstream systems.
Instructions in Martini
- Apply consent, suppression, deletion, and eligibility rules.
- Reject malformed identifiers and unsupported event payloads.
- Use stable keys to make profile updates and target writes idempotent.
- Prevent campaign actions when required account or campaign references are unavailable.
Common MoEngage data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Users | Represent customer profiles identified by a customer identifier. | Salesforce, Shopify, Zendesk, NetSuite, customer databases | Martini maps source identities and profile fields to MoEngage user requests, validates required identifiers, and supports safe repeated updates. |
| User attributes | Store profile properties such as name, email, location, subscription status, and application-specific attributes. | CRM, commerce, support, identity, analytics systems | Martini applies field mapping, type normalization, consent rules, and schema validation before sending attribute updates. |
| Events | Capture behavioral or transactional activities such as purchases, registrations, logins, and product interactions. | Shopify, Segment, Kafka, NetSuite, application services | Martini validates event names and timestamps, maps properties, deduplicates where possible, and submits events through the relevant REST API. |
| Campaigns | Represent customer engagement programs delivered through supported channels. | CRM, reporting stores, data warehouses, service platforms | Martini can invoke selected campaign-related operations and retrieve available campaign information, subject to account permissions and API coverage. |
| Segments | Represent audiences selected using profiles, events, and campaign criteria. | CRM, analytics platforms, data warehouses | Martini can synchronize available segment or audience information through documented endpoints and scheduled reconciliation workflows. |
| Devices and channel subscriptions | Associate mobile or web devices with messaging and notification information. | Mobile applications, identity systems, customer databases | Martini preserves device and subscription identifiers when exposed by the applicable API and applies consent and suppression rules during synchronization. |
Authentication and security considerations
Credential-based API access
MoEngage core API patterns commonly use an API ID and API key with HTTP authentication rather than a general end-user OAuth flow. Requirements vary by API family, account, and region.
Protecting credentials
- Store API IDs, API keys, and regional endpoints in Martini secrets or environment configuration.
- Do not embed credentials in mappings, source code, logs, or payloads.
- Use separate credentials and endpoints for development, test, and production where available.
- Grant only the MoEngage account and API permissions required by each workflow.
Operational considerations for MoEngage integrations
Throughput and pagination
Confirm rate limits for the selected MoEngage API, region, account, and plan. Use bounded concurrency, respect HTTP 429 responses, and follow the documented page, cursor, or offset model.
Identity and idempotency
Define the authoritative customer identifier and stable event or reconciliation keys. Repeated profile updates should be safe, and uncertain timeouts should not automatically create duplicate customer actions.
Schema and regional changes
Keep regional base URLs and API versions configurable. Test required fields, event properties, response formats, campaign references, pagination, authentication headers, and error payloads when contracts change.
Observability
Record endpoint operation, correlation ID, source identifier, status, vendor error details, retry count, and timestamps while excluding API keys, authorization headers, and unnecessary personal data.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond point-to-point calls
Martini separates triggers, API consumption, transformation, business rules, target writes, and operational handling in reusable workflows. This is more maintainable than scattering MoEngage calls across scripts or application code.
Controlled enterprise processing
Martini can combine REST calls, supported callbacks, scheduling, queues, databases, and other enterprise interfaces while controlling concurrency, checkpoints, retries, and error routes.
Consistent security and operations
Secrets, regional configuration, validation, correlation, logging, and deployment practices can be managed consistently across environments. Developers retain the flexibility to add custom logic when mappings or business rules require it.
Frequently asked questions
MoEngage is primarily integrated through REST APIs for Users, user attributes, Events, selected campaign operations, and engagement data. Selected features may provide webhook-style notifications or callbacks, while scheduled workflows and batch capabilities can support reconciliation and ingestion workloads. Authentication commonly uses an API ID and API key with HTTP authentication, and regional endpoints may apply.
Yes. Martini can consume MoEngage REST APIs, transform customer and event data, send Users, user attributes, and Events, invoke supported campaign-related operations, and receive documented webhook or callback requests where the relevant MoEngage feature supports them.
No. A dedicated MoEngage connector is not required. Martini can integrate using MoEngage’s confirmed native REST APIs, supported webhook-style callbacks, scheduled synchronization, batch mechanisms, and API credential authentication.
Lonti does not charge an additional per-connector or per-vendor fee to integrate MoEngage. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from MoEngage, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs are the primary recommended mechanism for current integrations. Use webhook-style callbacks only for the specific MoEngage features that document them, and use scheduled or batch workflows for polling, reconciliation, or workloads better suited to controlled ingestion. No official MoEngage GraphQL or SOAP API was confirmed.
MoEngage supports webhook-style capabilities in selected engagement, campaign, or feature-specific scenarios. Coverage is not confirmed for every User, Event, Campaign, or Segment change, so each project should verify whether it has a webhook, callback, export, or polling requirement.
Martini can receive source changes, call MoEngage REST APIs, process supported callbacks, or run scheduled workflows for polling and reconciliation. It maps identifiers and attributes, follows documented pagination, persists checkpoints, and uses idempotent keys and controlled retries to make synchronization restartable.
Martini can transform source payloads into MoEngage Users, user attributes, Events, Campaigns, and related API models. Workflows can validate identifiers and schemas, classify authentication, validation, throttling, and transient failures, apply bounded exponential backoff, and track source event IDs or reconciliation keys to reduce duplicate processing.
Related Martini documentation
MoEngage APIs
Data handling
Connect MoEngage with your enterprise systems
Use Martini to build maintainable MoEngage integrations for customer profiles, behavioral events, campaign workflows, and engagement reconciliation.