Ellipse Gradient for Header

Omnisend Integration Guide

Connect Omnisend with commerce, CRM, ERP, support, and data platforms through REST APIs, selected webhooks, and Martini workflows.

Omnisend integration options at a glance

Omnisend’s primary integration mechanism is a JSON REST API secured with an API key in the X-API-KEY header. The API supports Contacts, Events, Orders, Products, Carts, Campaigns, and related marketing data. Omnisend also provides webhook-style notifications for selected events and object changes, although coverage is not universal. Martini can consume the REST API, expose an endpoint for supported webhook notifications, and orchestrate scheduled synchronization for resources without event coverage. Workflows can paginate through API results, apply consent and identity rules, transform payloads, throttle requests, and retry transient failures without embedding credentials in integration logic.

Integration pointSupported by Omnisend?Common use casesHow Martini supports it
REST APIsYesOmnisend’s principal integration interface supports creating, updating, and retrieving Contacts, sending Events, and managing Orders, Products, Carts, and related marketing objects.Martini can consume Omnisend REST endpoints from workflows, send JSON requests, paginate responses, transform payloads, and orchestrate downstream processing.
Webhooks and outbound callbacksLimitedOmnisend provides webhook-style notifications for selected events and object changes. Coverage should not be assumed for every object or lifecycle operation.Martini can expose an HTTP endpoint to receive supported notifications, validate and deduplicate them, then route the payload to enterprise workflows or applications.
AuthenticationYesDirect API access primarily uses an API key sent in the X-API-KEY HTTP header, with permissions appropriate to the required Omnisend objects and operations.Martini can store the API key in secure secrets or environment configuration and apply it to outbound API requests without embedding it in workflow logic.
Scheduled synchronizationYesScheduled retrieval is appropriate for objects or changes without suitable webhook coverage and for reconciliation, incremental loads, and larger migrations.Martini can schedule workflows, preserve cursors or last-successful synchronization markers, paginate results, throttle requests, and resume after failures.
Bulk, asynchronous, and batch APIsNot confirmedA general-purpose bulk or asynchronous API covering all major Omnisend objects was not confirmed. Large loads should use pagination and controlled request concurrency unless a specific endpoint documents bulk behavior.Martini can implement bounded batches, checkpointing, rate-limit handling, and retry logic without assuming a universal bulk endpoint.
File and attachment APIsNot confirmedA general Omnisend file-import, file-export, or attachment API was not confirmed. REST endpoints should be treated as the default integration path.Martini can process files from other enterprise systems when required, but the Omnisend exchange should use documented API mechanisms unless a specific feature confirms file support.
Database and analytics accessNoDirect database, JDBC, or general-purpose analytics warehouse access was not confirmed for Omnisend.Martini can retrieve reporting data through documented Omnisend APIs and write it to an approved data platform, rather than connecting directly to Omnisend’s database.

How Omnisend exposes data and business events

Omnisend REST APIs

Omnisend REST APIs are the principal integration mechanism for managing Contacts, sending Events, and working with Orders, Products, Carts, Campaigns, and related marketing objects. Requests and responses use JSON and are authenticated primarily with an API key in the X-API-KEY header.

Martini implementation pattern

Martini workflows call the required Omnisend endpoints, pass credentials from secure configuration, paginate list operations, map response data to canonical enterprise models, and apply business rules before writing to downstream systems or sending updates back to Omnisend.

Implementation sequence

Configure the Omnisend API base URL and API key secret
Invoke the required Omnisend REST endpoint
Read the paginated response and synchronization state
Validate and map the Omnisend JSON payload
Apply identity, consent, and eligibility rules
Write the transformed data to the target system and record the checkpoint

Omnisend Webhooks

Omnisend supports webhook-style notifications for selected events and object changes. The mechanism has partial coverage, so it should not be treated as a universal notification stream for Contacts, Orders, Products, Carts, Campaigns, or Segments.

Martini implementation pattern

Martini exposes an HTTP API endpoint or webhook-consuming workflow, validates the incoming request, records an event identifier or source payload where available, applies idempotency, and routes supported notifications to downstream systems. Scheduled reconciliation covers unsupported or missed changes.

Implementation sequence

Expose a Martini endpoint for the supported Omnisend notification
Receive and validate the webhook payload
Check the event identifier or deterministic duplicate key
Retrieve the current Omnisend resource when the notification is insufficient
Map the event to the target application model
Acknowledge successful processing and route failures for retry or reconciliation

Scheduled Omnisend synchronization

Scheduled synchronization is appropriate for resources without suitable webhook coverage and for reconciliation, migration, and incremental data loads. Omnisend list endpoints should be treated as paginated, and a universal bulk API was not confirmed.

Martini implementation pattern

Martini scheduler-triggered workflows retrieve Omnisend data in controlled pages, persist a cursor, timestamp, or last-successful marker, and use bounded concurrency and retry policies. The workflow can resume after a failure and compare results with downstream state.

Implementation sequence

Start the synchronization workflow on an approved schedule
Load the saved cursor or last-successful synchronization marker
Retrieve the next Omnisend page
Transform and upsert the returned objects
Persist the next checkpoint after successful writes
Continue until the API reports that no additional results are available

Common Omnisend integration patterns

Pattern 1: Synchronize commerce customers and orders to Omnisend

When to use this pattern

Use this pattern when a commerce platform is the source of customer, product, cart, and purchase data for Omnisend marketing automation. It supports purchaser onboarding, post-purchase journeys, and customer-property updates while maintaining stable source identifiers.

Integration direction
Shopify
Martini
Omnisend
Example Mapping
Omnisend FieldCanonical FieldTarget Field
customer.idcustomer.externalIdContact external customer identifier
customer.emailcustomer.emailContact email
order.idorder.externalIdOrder identifier
line_itemsorder.itemsOrder products and line items
Martini implementation pattern

Martini receives commerce changes or retrieves them on a schedule, normalizes customer identity, maps products and line items, and submits Contacts, Products, Orders, and Events through Omnisend REST APIs. Business rules exclude ineligible or unsubscribed profiles, while idempotent keys and bounded retries prevent duplicate orders.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • scheduled execution
  • error handling

Pattern 2: Synchronize abandoned carts

When to use this pattern

Use this pattern when cart activity must trigger or support Omnisend abandoned-cart automation. The design should preserve cart identity, avoid repeated submission of unchanged data, and distinguish an abandoned cart from a completed or expired cart.

Integration direction
WooCommerce
Martini
Omnisend
Example Mapping
Omnisend FieldCanonical FieldTarget Field
cart.idcart.externalIdCart identifier
customer.emailcustomer.emailCart contact
itemscart.itemsCart line items
updated_atcart.updatedAtCart update timestamp
Martini implementation pattern

A Martini workflow consumes cart changes or polls eligible carts, resolves the associated Contact, maps line items and product details to the Omnisend Carts model, and applies state-transition rules before submission. A synchronization marker and deterministic request key prevent repeated unchanged updates; transient failures are retried and unresolved carts are reconciled later.

Martini capabilities used
  • workflows
  • API consumption
  • JSON transformation
  • data mapping
  • idempotency
  • retry handling

Pattern 3: Process Omnisend webhook notifications

When to use this pattern

Use this pattern when selected Omnisend events or object changes need to update a CRM, customer data platform, service application, or internal process in near real time. Because webhook coverage is selective, pair it with scheduled reconciliation.

Integration direction
Omnisend
Martini
Salesforce
Example Mapping
Omnisend FieldCanonical FieldTarget Field
event.idsourceEventIdExternal event ID
contact.emailcustomer.emailEmail
contact.tagscustomer.labelsContact tags
event.typelifecycleEvent.typeLifecycle event
Martini implementation pattern

Martini exposes a secured endpoint, validates the notification, checks for duplicates, and retrieves the current resource when the webhook payload is incomplete. It maps the result to the target CRM, applies consent and ordering rules, and sends failures to retry or reconciliation processing.

Martini capabilities used
  • API exposure
  • webhook consumption
  • validation
  • data mapping
  • business rules
  • error handling

Pattern 4: Synchronize CRM or ERP lifecycle events to Omnisend

When to use this pattern

Use this pattern when customer status, purchases, refunds, renewals, product registration, or account milestones in a CRM or ERP should update Omnisend marketing profiles and automation inputs.

Integration direction
NetSuite
Martini
Omnisend
Example Mapping
Omnisend FieldCanonical FieldTarget Field
customer.internalIdcustomer.externalIdContact external identifier
customer.statuscustomer.lifecycleStatusContact custom property
transaction.idtransaction.externalIdOrder or Event identifier
consent.marketingconsent.marketingAllowedSubscription eligibility
Martini implementation pattern

Martini consumes approved CRM or ERP changes, maps lifecycle information to Contacts, Events, or Orders, and filters records according to marketing eligibility. It prevents stale data from re-subscribing contacts, handles out-of-order changes using timestamps where available, and records rejected records for review.

Martini capabilities used
  • workflows
  • API consumption
  • mapping and transformation
  • business rules
  • consent handling
  • error handling

Applications commonly integrated with Omnisend

Omnisend can be integrated with commerce, customer, service, and data platforms using its REST API and selected webhook notifications. The exact objects and direction should be confirmed for each implementation, particularly where consent, campaign eligibility, and reverse synchronization are involved.

Application Scenario Direction Martini Pattern
Shopify Synchronize customers, products, carts, and orders to support abandoned-cart, purchase, and lifecycle marketing. Shopify → Martini → Omnisend Martini receives commerce changes, maps customer and transaction data to Omnisend Contacts, Products, Carts, Orders, and Events, then applies consent and idempotency rules before submitting REST requests.
WooCommerce Send store customers, orders, products, and cart activity to Omnisend for segmentation and marketing automation. WooCommerce → Martini → Omnisend A Martini workflow consumes WooCommerce data, normalizes customer identity and line items, transforms JSON payloads, and uses scheduled reconciliation for changes not delivered by the source system.
Salesforce Synchronize leads, contacts, account attributes, and lifecycle events with Omnisend marketing profiles. Salesforce → Martini → Omnisend Martini maps Salesforce lifecycle changes to Omnisend Contacts, Events, and custom properties, while enforcing subscription rules and routing rejected or ambiguous updates for review.
NetSuite Send customer, order, and fulfillment-related events to Omnisend and selectively return marketing-relevant status information. NetSuite → Martini → Omnisend Scheduled or event-driven Martini workflows extract approved NetSuite data, transform it into Omnisend Orders, Events, and Contact updates, and checkpoint progress for retryable synchronization.
Microsoft Dynamics 365 Synchronize customer and sales lifecycle data with Omnisend Contacts and Events. Microsoft Dynamics 365 → Martini → Omnisend Martini consumes Dynamics 365 changes, applies field and consent mappings, sends eligible updates to Omnisend, and uses reconciliation workflows for missed or out-of-order events.
Zendesk Use support, customer-status, or service events to update marketing profiles or suppress inappropriate campaigns. Zendesk → Martini → Omnisend A Martini workflow filters approved Zendesk events, maps customer identifiers and service status to Omnisend Contact properties or Events, and prevents support-state changes from overriding consent decisions.
ServiceNow Synchronize customer or service lifecycle events when marketing communications depend on case or service status. ServiceNow → Martini → Omnisend Martini receives ServiceNow events or retrieves changes on a schedule, applies business rules for marketing eligibility, and submits selected Contact updates or Events to Omnisend.
Snowflake Consolidate Omnisend data with commerce and customer data for reporting, segmentation, and reconciliation. Omnisend → Martini → Snowflake Martini paginates through Omnisend REST endpoints, normalizes JSON objects, records synchronization checkpoints, and writes curated Contacts, Orders, Events, Products, or Campaign data to Snowflake through the approved database or API pattern.

How to build a Omnisend integration in Martini

Objective

Establish controlled access to Omnisend and any target applications without placing credentials in workflow logic.

Instructions in Martini

  • Configure the Omnisend API host and required REST endpoints
  • Store the API key in Martini secrets or secure environment configuration
  • Send the key in the X-API-KEY header
  • Use separate development, test, and production credentials where available
  • Confirm permissions for Contacts, Events, Orders, Products, Carts, or Campaigns

Objective

Select an event-driven or scheduled initiation method based on the Omnisend object and the confirmed coverage of its integration mechanism.

Instructions in Martini

  • Use a Martini API endpoint for supported Omnisend webhook notifications
  • Use a scheduler for resources without webhook coverage
  • Define a reconciliation schedule for missed or unsupported changes
  • Capture the source event ID, cursor, timestamp, or last-successful marker

Objective

Obtain the current Omnisend resource or source-system payload needed for reliable processing.

Instructions in Martini

  • Call the relevant Omnisend REST endpoint
  • Follow endpoint-specific pagination behavior
  • Retrieve the current resource when a webhook payload is incomplete
  • Throttle requests and handle HTTP 429 responses with bounded backoff
  • Avoid assuming a general-purpose bulk endpoint exists

Objective

Convert Omnisend JSON and source-system payloads into a stable canonical model and target schema.

Instructions in Martini

  • Normalize Contact identity using approved email, phone, or external identifiers
  • Map Orders, Products, Carts, Events, and Campaign data explicitly
  • Preserve source IDs, timestamps, consent fields, and line-item relationships
  • Handle optional and unknown JSON properties safely
  • Validate required fields before writing to the target

Objective

Ensure that only valid, eligible, and correctly ordered changes are propagated.

Instructions in Martini

  • Prevent stale data from re-subscribing suppressed Contacts
  • Apply marketing eligibility and consent rules
  • Detect unchanged Carts and duplicate Events
  • Compare timestamps or version fields when events can arrive out of order
  • Route rejected business states to an exception or review process

Objective

Persist transformed data in the target system and maintain synchronization state for repeatable processing.

Instructions in Martini

  • Use idempotent create, update, or upsert behavior where supported
  • Write Contacts, Orders, Events, Products, or Carts to the selected target
  • Record request keys and source identifiers
  • Persist checkpoints only after successful downstream writes
  • Separate partial failures from successfully processed items

Common Omnisend data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ContactsSubscriber and customer profiles containing email addresses, phone numbers, subscription status, tags, and custom properties.Salesforce, Microsoft Dynamics 365, Shopify, WooCommerce, SnowflakeMartini validates identity and consent fields, maps profile attributes, performs idempotent create or update operations, and protects suppression state from stale updates.
EventsBehavioral or transactional activity used to update customer activity or trigger Omnisend automation.Salesforce, NetSuite, Shopify, Microsoft Dynamics 365, SnowflakeMartini transforms source events into Omnisend JSON, applies eligibility and deduplication rules, and retries transient API failures with bounded backoff.
OrdersPurchase transactions associated with Contacts and Products, including order and line-item information.Shopify, WooCommerce, NetSuite, SnowflakeMartini maps stable order identifiers, customer references, products, totals, and status changes, using read-before-write or upsert logic where required.
ProductsCatalog products referenced by Orders and used in marketing automation.Shopify, WooCommerce, NetSuite, SnowflakeMartini normalizes product identifiers and attributes, sends only approved changes, and reconciles catalog updates through paginated workflows.
CartsShopping cart state and abandoned-cart information used by Omnisend automation.Shopify, WooCommerce, SnowflakeMartini preserves cart and line-item identifiers, avoids resubmitting unchanged carts, and handles expiration or completed-order transitions through business rules.
CampaignsEmail, SMS, or other outbound marketing campaigns managed through Omnisend.Snowflake, Salesforce, Microsoft Dynamics 365Martini can retrieve supported campaign information for reporting or downstream synchronization, while respecting endpoint availability and API permissions.

Authentication and security considerations

API-key authentication

Omnisend direct API access primarily uses an API key in the X-API-KEY HTTP header. Configure the key with only the permissions required for the integration.

Credential protection

Store Omnisend keys in Martini secrets or secure environment configuration rather than workflow logic or source code. Use separate credentials for non-production and production environments where possible.

Data protection

  • Protect Contact identity, subscription, consent, and customer transaction data during transformation.
  • Do not log API keys or unnecessary sensitive customer data.
  • Validate inbound webhook requests and apply authorization controls to exposed Martini endpoints.
  • Prevent stale source data from overriding Omnisend suppression or unsubscribe decisions.

Operational considerations for Omnisend integrations

Rate limits and pagination

Confirm the current Omnisend rate limits and treat list endpoints as paginated. Handle HTTP 429 responses with bounded exponential backoff, controlled concurrency, and scheduled batches.

Idempotency and ordering

Use stable source identifiers and event keys for Contacts, Orders, Products, Carts, and Events. Webhook and source-system events can arrive out of order, so compare timestamps or versions where available and use reconciliation workflows.

Schema and consent changes

Version mappings, validate required fields, and tolerate unknown JSON properties where appropriate. Treat subscription state as consent-sensitive data and prevent stale updates from re-subscribing Contacts.

Testing and monitoring

  • Test authentication, pagination, rate limiting, rejected business states, and duplicate delivery.
  • Separate transient failures from permanent validation or permission errors.
  • Store checkpoints only after successful writes.
  • Monitor workflow logs and preserve request context without exposing credentials.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate more than an API call

Scripts can call an Omnisend endpoint, but enterprise integrations also need identity resolution, consent rules, pagination, throttling, retries, reconciliation, and observability. Martini centralizes these concerns in maintainable workflows.

Support multiple integration modes

Martini can consume Omnisend REST APIs, expose an endpoint for selected webhook notifications, and run scheduled synchronization for unsupported or missed events. This avoids building separate point-to-point processes for each use case.

Reuse mappings and controls

Reusable workflows and mapping logic can standardize Contacts, Events, Orders, Products, and Carts across commerce, CRM, ERP, support, and data-platform integrations.

  • Apply business rules before marketing data is sent.
  • Handle retries and duplicate detection consistently.
  • Keep API keys and environment-specific settings outside implementation logic.
  • Provide operational checkpoints and error routes for long-running synchronizations.

Frequently asked questions

How can Omnisend be integrated with enterprise systems?

Omnisend integrates primarily through its JSON REST API, secured with an API key in the X-API-KEY header. The API supports Contacts, Events, Orders, Products, Carts, Campaigns, and related marketing data. Selected events and object changes can also be delivered through webhook-style notifications, while scheduled REST synchronization can cover unsupported or missed changes.

Can Martini integrate with Omnisend?

Yes. Martini can consume Omnisend REST APIs, send and retrieve supported JSON objects, expose an endpoint for selected Omnisend webhook notifications, and orchestrate mappings, consent rules, retries, and scheduled reconciliation workflows.

Do I need a connector to integrate Omnisend with Martini?

No. A dedicated Omnisend connector is not required. Martini can use Omnisend’s documented REST APIs, API-key authentication, selected webhook notifications, and scheduled workflows to implement the integration.

Is there any extra Lonti cost to integrate Omnisend with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Omnisend. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Omnisend, cloud infrastructure, or other third-party systems based on subscriptions, usage, and deployment model.

Which Omnisend integration methods should be used?

Use the Omnisend REST API as the primary mechanism for Contacts, Events, Orders, Products, Carts, Campaigns, and related objects. Use webhook-style notifications for supported events where near-real-time processing is useful, and scheduled paginated synchronization for objects or changes without suitable webhook coverage. No confirmed Omnisend GraphQL or SOAP API should be assumed.

Are Omnisend webhooks available for event-driven integrations?

Omnisend supports webhook-style notifications for selected events and object changes, but coverage is partial rather than universal. Martini can receive and validate those notifications through an exposed endpoint. Scheduled reconciliation should supplement webhooks for unsupported, missed, or out-of-order changes.

How should Omnisend synchronization and data mapping be handled?

Use stable identifiers for Contacts, Orders, Products, Carts, and Events, and map Omnisend JSON into a canonical model before writing to target systems. Martini can paginate API responses, preserve checkpoints, transform fields and line items, apply consent rules, and use idempotent upsert or read-before-write patterns.

How does Martini handle Omnisend errors, retries, and duplicates?

Martini workflows can distinguish authentication, validation, rate-limit, transient server, and permanent business errors. Transient failures can be retried with bounded backoff, while malformed or rejected payloads can be routed to exception or reconciliation processing. Stable source identifiers, event IDs, and deterministic request keys support duplicate detection and idempotent processing.

Related Martini documentation

API Integration

Workflows

Transformation

Security

Operations

Connect Omnisend with your enterprise systems

Use Martini to build secure, maintainable Omnisend integrations across commerce, CRM, ERP, support, and data platforms.

EXPLORE MARTINI
BOOK A DEMO