.png)
Insider Integration Guide
Connect Insider with enterprise applications through REST APIs, selected webhook-style callbacks, batch ingestion, and scheduled Martini workflows.
Insider integration options at a glance
Insider’s primary integration surface is its REST API, covering user profiles, behavioral and transactional events, product catalogs, audience operations, and selected campaign or personalization use cases. Selected Insider features also support webhook-style outbound callbacks, although coverage depends on the product, campaign, event type, and account configuration. Batch-oriented ingestion is available for some high-volume user, event, and catalog scenarios. Authentication uses partner- or endpoint-specific credentials, commonly supplied in request headers. Martini can consume these APIs, receive supported callbacks, schedule synchronization workflows, transform payloads, submit bounded batches, and store credentials securely in Secrets Management.
| Integration point | Supported by Insider? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Insider documents REST APIs for user profile updates, event ingestion, product and catalog synchronization, audience operations, and selected campaign or personalization use cases. | Martini can consume Insider REST APIs, generate reusable API-led workflows, transform payloads, and route responses or failures to downstream systems. |
| Webhooks / outbound callbacks | Limited | Selected Insider features and campaign workflows can issue outbound HTTP requests or webhook-style notifications. Coverage is not universal across profiles, events, campaigns, or segments. | Martini can expose a controlled API endpoint and use a webhook-triggered workflow to validate, acknowledge, normalize, and route supported callbacks. |
| Bulk / async / batch APIs | Limited | Batch-oriented ingestion is relevant for high-volume user, event, and catalog synchronization, subject to endpoint-specific limits and processing behavior. | Martini can partition source data into bounded batches, submit them, record individual results, and retry failed batches using a suitable deduplication strategy. |
| Authentication | Yes | Insider integrations use partner- or endpoint-specific credentials, commonly API keys or request tokens in headers, with partner identifiers required by some ingestion APIs. | Martini can reference credentials from Secrets Management and apply endpoint-specific authentication configuration without embedding secrets in workflows or mappings. |
| File / attachment APIs | Not confirmed | Product catalog or data-feed options may exist in particular Insider configurations, but no general-purpose file or attachment API was confirmed. | Martini can process files where a documented Insider feed or an intermediate file exchange is available, but the applicable product capability must be confirmed first. |
| Database / analytics access | Not confirmed | No general-purpose SQL or direct Insider database access was confirmed. Product-specific exports or warehouse integrations require separate evaluation. | Martini can consume documented exports or load approved data into databases, but it should not assume direct SQL access to Insider. |
| GraphQL APIs | Not confirmed | No official Insider GraphQL API was confirmed in the reviewed material. | Martini can consume GraphQL generally, but Insider integration planning should use documented REST APIs unless Insider confirms a GraphQL endpoint. |
| SOAP APIs | No | No official Insider SOAP integration was confirmed. | Martini can consume SOAP services generally, but SOAP should not be used as an expected Insider integration mechanism. |
How Insider exposes data and business events
Insider REST APIs
Insider’s primary integration mechanism is REST APIs for user profile creation and updates, event ingestion, product and catalog synchronization, audience operations, and selected campaign or personalization use cases. API paths, payloads, credentials, and permissions vary by product and account.
Martini implementation pattern
Martini implementation pattern: a workflow receives or retrieves source data, calls the applicable Insider REST endpoint with credentials from Secrets Management, transforms the response, and routes validation or transport failures for retry or review.
Implementation sequence
Insider webhook-style callbacks
Selected Insider features and campaign workflows can make outbound HTTP requests or provide webhook-style notifications. This support is partial and must be verified for the product, event type, payload, signing, retries, and delivery guarantees involved.
Martini implementation pattern
Martini implementation pattern: expose a controlled API endpoint, accept only supported callback requests, validate the documented authentication or signing information, acknowledge promptly, and process downstream actions asynchronously when appropriate.
Implementation sequence
Insider batch ingestion
Insider supports batch-oriented ingestion for selected high-volume user, event, and catalog scenarios. Limits, payload format, processing model, and response behavior vary by endpoint.
Martini implementation pattern
Martini implementation pattern: a scheduled or event-driven workflow divides source data into bounded batches, submits each batch to Insider, persists request and response status, and replays only failed or uncertain work according to an idempotency strategy.
Implementation sequence
Insider authentication
Insider uses account- or partner-specific API credentials, commonly supplied through request headers. Some ingestion APIs use a partner name or identifier alongside a request token, but exact header names and scopes vary by endpoint.
Martini implementation pattern
Martini implementation pattern: store endpoint credentials in Secrets Management, reference them from the REST API configuration, restrict access by environment and workflow, and prevent secrets or personal data from appearing in logs.
Implementation sequence
Common Insider integration patterns
Pattern 1: Synchronize CRM customers to Insider
When to use this pattern
Use this pattern when Salesforce or another customer system is the authoritative source for customer profiles, consent, and attributes that Insider needs for audience building and personalization.
Integration direction
Example Mapping
| Insider Field | Canonical Field | Target Field |
|---|---|---|
| Salesforce Contact.Id | customerId | Insider user identifier |
| Salesforce Email | Insider email attribute | |
| Salesforce Marketing Consent | marketingConsent | Insider consent attribute |
| Salesforce LastModifiedDate | sourceUpdatedAt | profile update checkpoint |
Martini implementation pattern
A scheduled Martini workflow retrieves changed customers, rejects incomplete identities, normalizes consent and attributes, submits bounded Insider user-profile batches, and stores source checkpoints and rejected payloads. Transient throttling or network failures are retried, while validation failures are routed for correction.
Martini capabilities used
- workflows
- scheduled execution
- API consumption
- data mapping
- business rules
- Secrets Management
- batch orchestration
- error handling
Pattern 2: Send commerce events to Insider
When to use this pattern
Use this pattern when a commerce platform or ERP produces product views, cart activity, purchases, registrations, cancellations, or returns that should inform Insider personalization and engagement.
Integration direction
Example Mapping
| Insider Field | Canonical Field | Target Field |
|---|---|---|
| Shopify order.id | orderId | Insider purchase event identifier |
| Shopify customer.id | customerId | Insider user identifier |
| Shopify line_items | items | Insider event products |
| Shopify financial_status | transactionStatus | Insider transaction attribute |
Martini implementation pattern
Martini receives or polls commerce activity, maps each event to the configured Insider event schema, validates required identifiers and consent, and submits it through the relevant REST API. Stable source IDs and a processing ledger prevent duplicate purchases when retries occur; invalid events are quarantined for review.
Martini capabilities used
- event-driven workflows
- API consumption
- JSON transformation
- data mapping
- validation
- deduplication
- retry handling
Pattern 3: Synchronize product catalogs to Insider
When to use this pattern
Use this pattern for initial catalog loads and incremental product, price, category, availability, or inventory-attribute synchronization from a commerce, ERP, or product-information source.
Integration direction
Example Mapping
| Insider Field | Canonical Field | Target Field |
|---|---|---|
| SAP Commerce Cloud product.code | productId | Insider product identifier |
| SAP Commerce Cloud name | productName | Insider product name |
| SAP Commerce Cloud price | price | Insider product price |
| SAP Commerce Cloud stockLevel | availability | Insider availability attribute |
Martini implementation pattern
A Martini scheduler retrieves catalog pages or change windows, validates the canonical product model, maps it to Insider catalog payloads, and submits bounded batches. The workflow stores a durable high-water mark, performs periodic reconciliation, and retries recoverable failures without advancing the checkpoint prematurely.
Martini capabilities used
- scheduler trigger
- workflows
- pagination handling
- data mapping
- batch processing
- validation
- checkpoint management
Pattern 4: Process Insider callbacks for downstream systems
When to use this pattern
Use this pattern where a configured Insider feature provides an outbound callback for a supported campaign, delivery, audience, or other platform event that must be routed to enterprise applications.
Integration direction
Example Mapping
| Insider Field | Canonical Field | Target Field |
|---|---|---|
| Insider user identifier | customerId | Salesforce Contact or Lead identifier |
| Insider campaign identifier | campaignId | Salesforce campaign reference |
| Insider event type | engagementType | Salesforce engagement activity |
| Insider event timestamp | occurredAt | Salesforce activity date |
Martini implementation pattern
Martini exposes a controlled API endpoint and uses a webhook-triggered workflow to validate the callback, detect replayed deliveries, normalize the payload, and enqueue or route downstream updates. The endpoint responds promptly, while downstream failures are logged and retried independently.
Martini capabilities used
- API exposure
- webhook consumption
- workflow triggers
- data mapping
- business rules
- duplicate detection
- asynchronous processing
- monitoring
Applications commonly integrated with Insider
Insider can be integrated with customer, commerce, engagement, and data-platform applications to coordinate profiles, behavioral events, catalogs, audiences, and campaign-related data. Exact endpoint and event coverage should be confirmed for each Insider product and account configuration.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize contacts, leads, customer attributes, consent, and engagement outcomes between CRM processes and Insider audiences. | Salesforce → Martini → Insider | A scheduled Martini workflow retrieves changed Salesforce data, normalizes identifiers and consent fields, maps it to Insider user profiles, submits bounded batches, and records rejected payloads for replay. |
| Shopify | Send customer, product, cart, and purchase activity to Insider for personalization and customer engagement. | Shopify → Martini → Insider | Martini consumes Shopify data or events, maps customer and commerce activity to Insider event and catalog payloads, applies duplicate-event rules, and retries transient API failures. |
| SAP Commerce Cloud | Synchronize enterprise product catalogs, customer activity, orders, and availability information with Insider. | SAP Commerce Cloud → Martini → Insider | A workflow retrieves incremental catalog and activity changes, validates required Insider attributes, partitions requests according to endpoint limits, and tracks synchronization checkpoints. |
| Adobe Commerce | Exchange product, customer, cart, and transaction events for personalization and customer engagement. | Adobe Commerce → Martini → Insider | Martini receives or polls Adobe Commerce data, converts commerce events into the configured Insider schema, enriches identifiers, and routes validation failures to operational handling. |
| Segment | Forward standardized customer profiles and behavioral events into Insider as part of a customer-data architecture. | Segment → Martini → Insider | Martini receives standardized Segment payloads, applies Insider-specific field and event mappings, filters consent-sensitive data, and submits accepted events while preserving correlation identifiers. |
| Braze | Coordinate engagement data between platforms where an organization uses both Insider and Braze. | Braze → Martini → Insider | Martini orchestrates event-specific exchanges, applies source precedence and consent rules, transforms engagement payloads, and prevents feedback loops through source markers and deduplication. |
| Snowflake | Centralize customer, event, campaign, and performance data for analytics, governance, and selected activation use cases. | Insider → Martini → Snowflake | Martini processes supported Insider exports or API responses, converts them into governed warehouse structures, validates schema changes, and loads data with checkpointed batches. |
| NetSuite | Synchronize customer, order, product, and transaction data from an operational source into Insider. | NetSuite → Martini → Insider | A scheduled workflow extracts changed NetSuite objects, maps them to Insider users, events, or products, applies identity and consent rules, and retries recoverable failures. |
How to build a Insider integration in Martini
Objective
Confirm the applicable Insider product API, credential model, headers, permissions, payload limits, and required identifiers before implementation.
Instructions in Martini
- Use the applicable Insider REST API documentation as the source of endpoint requirements.
- Store partner credentials, request tokens, and identifiers in Martini Secrets Management.
- Configure HTTPS requests and avoid placing credentials in mappings, URLs, source code, or logs.
Objective
Select a scheduled, source-event, or callback trigger based on the required synchronization latency and Insider feature coverage.
Instructions in Martini
- Use a scheduler for profile, catalog, reconciliation, and retry workflows.
- Use a source application event where reliable event delivery is available.
- Use an API endpoint and webhook-triggered workflow only for supported Insider callbacks.
Objective
Read source profiles, events, products, or callback payloads while preserving pagination, change windows, and correlation identifiers.
Instructions in Martini
- Implement the source system’s pagination or continuation model.
- Store a durable high-water mark or source change token.
- Retain source IDs and timestamps needed for deduplication and replay.
Objective
Coordinate API calls, validation, batching, routing, persistence, and downstream processing in a maintainable Martini workflow.
Instructions in Martini
- Separate ingestion, transformation, submission, and outcome handling into clear workflow stages.
- Partition high-volume data into bounded batches.
- Use conditional routing for validation, authentication, throttling, and server failures.
Objective
Convert source-specific profiles, events, catalogs, and campaign data into the Insider model required by the selected endpoint.
Instructions in Martini
- Create canonical mappings for user identifiers, consent, attributes, event names, and product fields.
- Validate required values and normalize dates, types, nulls, and identifiers.
- Keep mappings version-controlled as Insider schemas evolve.
Objective
Enforce identity, consent, privacy, event uniqueness, source precedence, and data-quality rules before submission.
Instructions in Martini
- Do not infer consent from campaign participation.
- Prevent null or lower-quality values from overwriting trusted identifiers.
- Use stable event, order, customer, and product IDs for idempotency.
Common Insider data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Users / user profiles | Store customer or visitor identifiers, contact details, consent information, profile attributes, and related behavioral context. | Salesforce, Shopify, SAP Commerce Cloud, Adobe Commerce, Snowflake | Martini normalizes identity and consent fields, validates required attributes, maps source profiles to Insider payloads, and submits updates individually or in bounded batches. |
| Events | Represent product views, cart activity, purchases, registrations, cancellations, returns, and other custom behavioral or transactional activities. | Shopify, Adobe Commerce, SAP Commerce Cloud, Salesforce, Snowflake | Martini transforms source events into the configured Insider event schema, applies event and identity rules, deduplicates retries, and records response outcomes. |
| Products / catalog items | Provide product attributes used for personalization, recommendations, merchandising, campaign targeting, availability, pricing, and category operations. | Shopify, SAP Commerce Cloud, Adobe Commerce, NetSuite, Snowflake | Martini performs initial or incremental catalog synchronization, validates schema and required fields, handles pagination, batches requests, and stores checkpoints. |
| Segments | Represent audiences based on user attributes, event behavior, engagement, or targeting criteria. | Salesforce, Braze, Snowflake, internal audience services | Martini can exchange supported audience or segmentation data through the applicable Insider API, applying consent, identity, and reconciliation rules. |
| Campaigns | Represent personalization, engagement, or messaging programs configured in Insider channels. | Salesforce, Braze, Snowflake, notification and reporting platforms | Martini can process supported campaign-related API responses or callbacks, normalize outcomes, and deliver selected engagement data to downstream systems. |
| Attributes | Describe user, product, or event properties used for segmentation, personalization, reporting, and decision logic. | Salesforce, commerce platforms, Snowflake, internal canonical data stores | Martini applies canonical mappings, type and null handling, consent rules, and schema validation before sending or storing attributes. |
Authentication and security considerations
Credential handling
Insider uses partner- or endpoint-specific API credentials, commonly supplied in request headers. Some ingestion APIs may require a partner name or identifier alongside a request token, but exact headers and scopes vary by API.
Store Insider credentials in Martini Secrets Management and reference them from API configuration. Do not embed keys in workflow definitions, mappings, URLs, source code, or logs.
Transport and access controls
- Use HTTPS/TLS for Insider API communication.
- Restrict credentials by partner, account, product, and API capability where supported.
- Minimize personal data and protect consent and profile information in logs.
- For callbacks, validate any documented token, signature, method, content type, and replay controls.
Operational considerations for Insider integrations
Throughput and synchronization
- Confirm request, daily, payload-size, and batch limits for each Insider endpoint.
- Use bounded batches and avoid unregulated parallel traffic.
- Implement pagination, change windows, high-water marks, and periodic reconciliation.
Reliability and data quality
- Separate validation, authentication, throttling, network, and server failures.
- Retry transient failures and preserve rejected payloads for replay.
- Use stable identifiers and a deduplication record for retryable events.
- Validate event names, required attributes, consent, catalog fields, and schema versions.
Observability and change management
Log correlation IDs and Insider response identifiers without exposing secrets or unnecessary personal data. Monitor rejection rates, authentication failures, throttling, callback delays, and synchronization lag. Keep mappings version-controlled and test changes to event names, attributes, catalog fields, and credentials before deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini provides a maintainable workflow layer around Insider APIs, source applications, callback endpoints, and operational stores. It can coordinate scheduled, event-driven, and batch processing without duplicating integration logic across separate scripts.
Reusable integration behavior
Workflows can centralize authentication, canonical mappings, consent rules, validation, batching, deduplication, retries, and error routing. Martini APIs can also expose controlled internal façades for applications that need governed access to Insider operations.
Operational control
Compared with point-to-point integrations, Martini provides a place to manage checkpoints, observability, replayable failures, environment-specific secrets, and downstream routing as the Insider implementation evolves.
Frequently asked questions
Insider is primarily integrated through REST APIs for user profiles, events, products and catalogs, audience operations, and selected campaign or personalization use cases. Selected features also support webhook-style outbound callbacks, and batch ingestion is available for some high-volume scenarios. Authentication and endpoint availability vary by Insider product and account.
Yes. Martini can consume Insider REST APIs, transform profile, event, catalog, and audience-related payloads, process supported batch requests, and receive selected Insider callbacks through a Martini API and workflow. No native Martini Insider connector is documented in the supplied materials.
No. A dedicated Insider connector is not required. Martini can use Insider’s confirmed native integration mechanisms, including REST APIs, endpoint-specific authentication, selected webhook-style callbacks, and batch ingestion.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Insider with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Insider, infrastructure providers, or other third-party systems based on subscriptions, usage, and deployment model.
Use Insider REST APIs as the primary mechanism for profiles, events, catalogs, and supported audience or campaign operations. Use batch ingestion for suitable high-volume workloads and webhook-style callbacks only when the applicable Insider feature explicitly supports them. GraphQL and SOAP should not be assumed because neither was confirmed for Insider.
Martini can expose an API endpoint and process Insider webhook-style requests. Insider callback coverage is partial and feature-specific, so the event types, payloads, authentication or signing, retry behavior, and delivery guarantees must be verified for the relevant product and configuration.
Martini can run scheduled or event-driven workflows that retrieve changed profiles, events, and products, map them to Insider payloads, submit bounded batches, and persist checkpoints. Periodic reconciliation should supplement incremental synchronization to account for late-arriving updates, clock differences, and rejected records.
Martini can map source data to canonical Insider models, validate required fields, apply consent and identity rules, classify failures, and retry transient network or throttling errors. Stable source identifiers and a Martini-side processing ledger can prevent duplicate events when an Insider endpoint does not provide an explicit idempotency key.
Related Martini documentation
Workflows
Connect Insider with your enterprise systems
Use Martini to build secure, observable Insider integrations across customer profiles, events, catalogs, audiences, and supported callbacks.