.png)
Bloomreach Engagement Integration Guide
Bloomreach Engagement integrates with enterprise systems through REST APIs, event tracking, batch data ingestion, file exchange, and selected webhook-style actions.
Bloomreach Engagement integration options at a glance
Bloomreach Engagement provides REST APIs for customer data, event tracking, imports, catalogs, and related project operations. Its event-oriented model supports behavioral and transactional activity such as purchases, product views, cart updates, and campaign interactions. Bulk and batch mechanisms support customer migrations, historical event loads, and product catalog synchronization, while file-based import and export can support larger scheduled data exchanges. Selected scenario and engagement configurations can invoke webhook-style outbound actions, but coverage is not universal. Martini can consume these APIs, expose endpoints for upstream events or callbacks, schedule synchronization workflows, transform payloads, manage secrets, and apply validation, retry, and monitoring logic.
| Integration point | Supported by Bloomreach Engagement? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Send customer events, update customer attributes, import data, work with product catalogs, and query or export supported project data. | Martini can consume Bloomreach Engagement REST APIs from workflows, map source objects to Bloomreach payloads, and expose APIs for upstream systems. |
| Event tracking endpoints | Yes | Transmit purchases, product views, cart updates, subscriptions, campaign interactions, and other behavioral or transactional events associated with customer identifiers. | Martini can receive normalized events, validate and enrich them, transform event properties, and submit them to the appropriate Bloomreach endpoint. |
| Bulk / async / batch APIs | Yes | Support customer migrations, historical event backfills, product catalog loads, scheduled updates, and reprocessing of records that failed validation. | Martini can partition payloads, schedule batch workflows, track outcomes, throttle requests, and retry transient failures. |
| Webhooks / outbound callbacks | Limited | Selected scenario and engagement configurations can invoke webhook-style outbound actions, subject to the configured feature, event, and payload options. | Martini can expose a REST endpoint for supported Bloomreach callbacks or invoke a Bloomreach-configured destination, with request validation and replay protection. |
| File import and export | Limited | Supported file workflows can handle scheduled CSV imports, product catalog loads, historical event ingestion, and downstream exports. | Martini can orchestrate file-based exchanges, parse and transform supported data, validate rows, and route rejected records for review. |
| Authentication | Yes | Project tokens, API keys, and HTTP authorization mechanisms authenticate requests; the exact scheme depends on the API family. | Martini can keep project-specific credentials in secrets or environment configuration and apply the required request headers without embedding credentials in workflows. |
| GraphQL APIs | Not confirmed | No official Bloomreach Engagement GraphQL API was confirmed for this research. | Martini should use the confirmed REST and file or batch mechanisms rather than assuming GraphQL availability. |
| SOAP APIs | Not confirmed | No official Bloomreach Engagement SOAP API was confirmed for this research. | Martini should use documented REST APIs, supported imports, exports, or webhook-style mechanisms instead. |
| Database / analytics access | Not confirmed | Direct database access to Bloomreach Engagement operational data was not confirmed. | Martini should consume documented APIs or supported export and delivery features rather than connecting directly to vendor databases. |
How Bloomreach Engagement exposes data and business events
Bloomreach REST APIs
Bloomreach Engagement REST APIs are the primary programmatic integration mechanism. They support customer data, event tracking, imports, catalogs, and related project operations, with available resources and permissions dependent on the project and API family.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with project-specific configuration, calls the relevant Bloomreach endpoint, validates the response, maps the result into a canonical model, and writes or forwards the outcome. Reusable API services can centralize request construction, throttling, and error classification.
Implementation sequence
Bloomreach Event Tracking
Bloomreach Engagement is event-oriented and accepts behavioral or transactional activity associated with customer identifiers. Common events include purchases, product views, cart updates, subscriptions, and campaign interactions.
Martini implementation pattern
Martini implementation pattern: an upstream commerce, CRM, or application system sends a normalized event to a Martini API or workflow. Martini validates the event contract, applies consent and identity rules, transforms properties, and submits the event to Bloomreach, with replay-safe handling for retries.
Implementation sequence
Bloomreach Batch and Bulk APIs
Bulk and batch-oriented ingestion supports initial customer migrations, historical event backfills, product catalog updates, scheduled source-system loads, and reprocessing of failed data.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow extracts an incremental or full source dataset, partitions it according to confirmed endpoint limits, transforms each batch, submits the batches, and records accepted and rejected results. Transient failures can be retried without replaying successfully completed partitions.
Implementation sequence
Bloomreach Webhook Actions
Bloomreach supports webhook-style outbound actions in selected scenario and engagement contexts. These actions are not a universal event stream, so the configured scenario, event coverage, authentication options, and payload must be confirmed before implementation.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured REST endpoint for the supported callback, verifies request authentication or signatures where available, validates the payload, adds internal context, and routes the result to a downstream application or workflow. Correlation IDs and replay controls support operational troubleshooting.
Implementation sequence
Bloomreach File Import and Export
File-based workflows can support supported customer, event, or product data imports and exports, particularly for larger scheduled datasets. Transport, schema, scheduling, and retention behavior depend on the relevant Bloomreach configuration.
Martini implementation pattern
Martini implementation pattern: a workflow obtains or receives the file, validates its format and schema, parses rows, maps them to Bloomreach import structures, and submits or delivers the data through the supported mechanism. Invalid rows are separated for correction without discarding the valid load.
Implementation sequence
Common Bloomreach Engagement integration patterns
Pattern 1: Synchronize commerce events to Bloomreach Engagement
When to use this pattern
Use this pattern when Shopify or another commerce application must send purchases, cart changes, product views, or subscription activity to Bloomreach for personalization and campaign orchestration. It supports real-time or near-real-time event intake through a Martini API or workflow.
Integration direction
Example Mapping
| Bloomreach Engagement Field | Canonical Field | Target Field |
|---|---|---|
| order.id | transactionId | event.transaction_id |
| customer.email | customerEmail | customer.email |
| order.total_price | orderValue | event.order_value |
| line_items[].product_id | productId | event.product_id |
Martini implementation pattern
Martini receives the commerce event, validates the customer and transaction identifiers, normalizes currency and timestamps, and maps the payload to the Bloomreach event structure. Business rules distinguish legitimate repeated behavioral events from duplicate order submissions. The workflow retries transient failures, records rejected payloads safely, and prevents replay of successfully processed transactions.
Martini capabilities used
- REST APIs
- API exposure
- workflows
- data mapping
- business rules
- validation
- error handling
Pattern 2: Synchronize CRM customers to Bloomreach Engagement
When to use this pattern
Use this pattern when Salesforce or another CRM is authoritative for customer profiles, consent, loyalty, or lifecycle fields that Bloomreach uses for segmentation and engagement. A scheduled incremental workflow is appropriate when the source does not provide a confirmed callback mechanism.
Integration direction
Example Mapping
| Bloomreach Engagement Field | Canonical Field | Target Field |
|---|---|---|
| Contact.Id | customerId | customer.id |
| Contact.Email | customer.email | |
| Contact.HasOptedOutOfEmail | emailConsent | customer.email_consent |
| Contact.Lifecycle_Status__c | lifecycleStatus | customer.lifecycle_status |
Martini implementation pattern
Martini retrieves changed CRM customers using a durable watermark, resolves field ownership, and transforms CRM-specific values into Bloomreach customer attributes. Consent and privacy rules are applied before transmission. The workflow records source and target identifiers, retries transient API failures, and routes invalid identities or schema mismatches to an exception path.
Martini capabilities used
- scheduled workflows
- API consumption
- incremental synchronization
- data mapping
- business rules
- secrets management
- monitoring
Pattern 3: Synchronize product catalogs in batches
When to use this pattern
Use this pattern when a commerce or ERP system supplies products, prices, categories, and availability indicators for Bloomreach recommendations, personalization, and commerce-related events. Batch processing is useful for initial loads and high-volume scheduled updates.
Integration direction
Example Mapping
| Bloomreach Engagement Field | Canonical Field | Target Field |
|---|---|---|
| item.internalId | productId | product.id |
| item.displayName | productName | product.name |
| item.basePrice | price | product.price |
| item.custitem_category | category | product.category |
Martini implementation pattern
Martini extracts a full or incremental product set, normalizes identifiers and monetary values, validates required catalog fields, and partitions the data within confirmed Bloomreach batch limits. Each partition is submitted independently, with accepted and rejected results recorded. Retries are limited to transient failures so completed batches are not duplicated.
Martini capabilities used
- scheduler triggers
- REST APIs
- batch orchestration
- mapping and transformation
- validation
- retry handling
- workflow logging
Pattern 4: Process Bloomreach engagement callbacks
When to use this pattern
Use this pattern when a configured Bloomreach scenario or engagement action can send a webhook-style callback to an internal application, CRM, service platform, or messaging process. It is suitable only after confirming that the required Bloomreach event and webhook action are available.
Integration direction
Example Mapping
| Bloomreach Engagement Field | Canonical Field | Target Field |
|---|---|---|
| customer_id | customerId | caller_id |
| event_name | engagementEvent | u_engagement_event |
| campaign_id | campaignId | u_campaign_id |
| event_timestamp | occurredAt | u_occurred_at |
Martini implementation pattern
Martini exposes a secured REST endpoint, validates the callback and any available authentication or signature, enriches the payload with internal context, and routes it to ServiceNow or another downstream system. Business rules determine whether the callback creates, updates, suppresses, or escalates work. Replay detection and exception handling prevent duplicate downstream actions.
Martini capabilities used
- API exposure
- webhook consumption
- workflows
- data validation
- business rules
- data mapping
- error handling
Applications commonly integrated with Bloomreach Engagement
Bloomreach Engagement can participate in customer-data, commerce, marketing, and service architectures. The following are practical adjacent applications that can exchange customer, event, product, or engagement information through APIs, scheduled workflows, or supported event mechanisms; they are not presented as confirmed native Bloomreach integrations.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Send product, customer, cart, and order activity to Bloomreach Engagement for personalization and campaign orchestration. | Shopify → Martini → Bloomreach Engagement | Martini receives or periodically retrieves Shopify data, normalizes customer and commerce identifiers, maps orders and behavioral activity to Bloomreach events, and applies duplicate protection and retry handling before submission. |
| Salesforce | Synchronize contacts, leads, lifecycle data, consent, and selected opportunity information with Bloomreach customer profiles and engagement programs. | Salesforce → Martini → Bloomreach Engagement | A scheduled or event-driven Martini workflow retrieves changed Salesforce objects, maps authoritative customer and consent fields, validates identity, and updates Bloomreach customer attributes while recording synchronization status. |
| NetSuite | Combine customer, order, invoice, and product information with marketing and customer engagement data. | NetSuite → Martini → Bloomreach Engagement | Martini extracts incremental NetSuite data, converts ERP identifiers, currencies, timestamps, and product attributes into Bloomreach payloads, then submits customer, event, or catalog updates in controlled batches. |
| ServiceNow | Use service status and customer-support activity to suppress or adapt engagement campaigns. | ServiceNow → Martini → Bloomreach Engagement | Martini retrieves relevant ServiceNow customer or service-status changes, applies campaign-suppression rules, and updates Bloomreach attributes or sends appropriate events. Failed records are isolated for replay. |
| Zendesk | Use support tickets, customer status, and service interactions to influence segmentation and communication. | Zendesk → Martini → Bloomreach Engagement | A Martini workflow consumes Zendesk changes through supported APIs, resolves the customer identity, maps ticket status and interaction attributes, and submits only the engagement events or profile updates required by the business rules. |
| Segment | Forward normalized customer and behavioral events into Bloomreach Engagement or coordinate event routing across engagement platforms. | Segment → Martini → Bloomreach Engagement | Martini exposes a normalized ingestion API or consumes available Segment delivery mechanisms, validates event names and properties, enriches identifiers, and routes accepted events to Bloomreach with replay-safe processing. |
| Google Analytics 4 | Reconcile behavioral measurement data with customer engagement activity and campaign analysis. | Google Analytics 4 → Martini → Bloomreach Engagement | Martini transforms selected analytics events and identifiers into the Bloomreach event model, applies privacy and consent rules, and separates measurement data from customer profile updates where appropriate. |
| Klaviyo | Coordinate audiences, customer attributes, and engagement activity when an organization uses both engagement platforms. | Klaviyo → Martini → Bloomreach Engagement | Martini mediates selected audience or profile exchanges, establishes field ownership and consent rules, maps platform-specific event schemas, and uses validation and duplicate controls before writing to either platform. |
How to build a Bloomreach Engagement integration in Martini
Objective
Establish the Bloomreach project configuration and the credentials required for the selected API family.
Instructions in Martini
- Create environment-specific configuration for the Bloomreach project token, API key, base endpoint, and project settings.
- Store credentials in Martini secrets or protected environment configuration.
- Confirm the authentication scheme and permissions for each Bloomreach API being used.
Objective
Select the event, schedule, file arrival, or API request that starts the integration workflow.
Instructions in Martini
- Use an API endpoint for upstream commerce or application events when near-real-time processing is required.
- Use a scheduler for customer, product, or historical data synchronization.
- Use a Martini REST endpoint for supported Bloomreach webhook-style callbacks.
Objective
Retrieve or accept source data while preserving identifiers and enough context for traceability.
Instructions in Martini
- Retrieve incremental source data using a durable timestamp, sequence, or cursor where supported.
- Accept inbound events or callbacks only after validating the request and payload structure.
- Keep source identifiers and correlation IDs available for duplicate detection and troubleshooting.
Objective
Coordinate API calls, batching, routing, and state management in a Martini workflow.
Instructions in Martini
- Separate extraction, transformation, Bloomreach submission, and result recording into clear workflow stages.
- Partition high-volume customer, event, or product loads according to confirmed Bloomreach limits.
- Route validation failures and transient platform errors through separate handling paths.
Objective
Convert source-specific customer, event, product, or campaign data into Bloomreach structures.
Instructions in Martini
- Map source identifiers to the Bloomreach customer, event, product, or catalog model.
- Normalize timestamps, currencies, product IDs, consent values, and enumerated statuses.
- Validate required fields before sending data to Bloomreach.
Objective
Apply identity, consent, ownership, deduplication, and routing rules before writing data.
Instructions in Martini
- Define which system is authoritative for customer attributes and consent.
- Use stable event or transaction identifiers to distinguish retries from legitimate repeated events.
- Suppress unnecessary updates and route privacy, identity, or schema exceptions for review.
Common Bloomreach Engagement data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Customers | Synchronize customer profiles and establish the identity used for events, segmentation, and engagement. | Salesforce, Shopify, NetSuite, Zendesk, customer data platforms | Martini resolves the authoritative customer identifier, maps profile fields, validates consent and required attributes, and submits changes through REST or batch APIs. |
| Customer attributes | Carry email, loyalty, consent, lifecycle, and other profile properties used by campaigns and personalization. | Salesforce, NetSuite, Shopify, Zendesk | Martini applies field ownership, normalization, privacy rules, and type conversions before updating only the required attributes. |
| Events | Represent purchases, page views, product interactions, cart changes, subscriptions, and campaign activity. | Shopify, Segment, Google Analytics 4, internal applications, data warehouses | Martini validates event names and properties, normalizes timestamps and identifiers, enriches context, and uses stable source identifiers to limit duplicates. |
| Products | Represent items used in recommendations, personalization, commerce-related events, and catalog synchronization. | Shopify, NetSuite, commerce platforms, product information systems | Martini maps product IDs, prices, categories, availability indicators, and other configured attributes, then submits updates through catalog or import mechanisms. |
| Product catalogs | Provide collections of product data and attributes for campaigns, recommendations, and customer experiences. | Shopify, NetSuite, commerce platforms, internal catalog services | Martini retrieves incremental or full catalog data, partitions large loads, transforms schemas, and monitors batch acceptance and rejected rows. |
| Campaigns and scenarios | Define engagement logic that uses customer data, events, segments, and actions. | CRM platforms, service platforms, messaging systems, internal applications | Martini can provide input events or receive selected scenario-driven webhook actions, while keeping business routing and downstream delivery in explicit workflows. |
Authentication and security considerations
Project-scoped credentials
Bloomreach Engagement uses project-specific tokens and API credentials. The exact authorization format can vary by API family, so each endpoint should be confirmed before implementation.
Secrets and environments
Store project tokens, API keys, endpoint configuration, and other credentials in Martini secrets or protected environment configuration. Use separate development, staging, and production values where applicable, and rotate credentials without changing workflow logic.
Data protection
- Limit credentials to the required project and operations.
- Do not place API keys in mappings, static payloads, or logs.
- Validate consent and avoid sending unnecessary personal data.
- Secure Martini callback endpoints and validate available webhook authentication or signatures.
Operational considerations for Bloomreach Engagement integrations
Throughput and limits
Confirm Bloomreach request, event-volume, payload-size, and batch-size limits. Use batching where supported and add throttling and backoff for rate-limit or transient responses.
Incremental synchronization
Use durable timestamps, source sequences, or export cursors rather than relying only on page numbers. Account for late-arriving records and clock differences between systems.
Identity and idempotency
Define a stable customer identifier and source event identifier. Distinguish legitimate repeated behavioral events from accidental replay of orders, payments, subscriptions, or batch records.
Schema and privacy controls
Version event contracts, validate required fields, and monitor for changed field types or project configuration. Define consent, suppression, deletion, correction, and retention behavior across systems.
Observability
Track accepted and rejected events, synchronization lag, retry attempts, rate limits, and batch outcomes. Persist failed payloads safely for replay without exposing sensitive customer data in logs.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini provides a structured workflow layer for receiving events, calling Bloomreach APIs, coordinating batch loads, applying business rules, and forwarding results to other enterprise systems.
Reusable integration assets
Teams can centralize authentication, request handling, mappings, validation, retry behavior, and error routing instead of duplicating those concerns across point-to-point scripts.
Controlled change and operations
Martini separates environment configuration and secrets from workflow logic, supports scheduled and event-driven execution, and provides logging and exception paths for operational support.
Flexible API-led architecture
Martini can consume Bloomreach REST APIs and expose controlled REST APIs for upstream applications or supported callbacks. This allows Bloomreach-specific schemas to remain behind a governed integration boundary.
Frequently asked questions
Bloomreach Engagement can integrate through its REST APIs, event tracking endpoints, bulk and batch ingestion mechanisms, supported file import or export workflows, and selected webhook-style actions. Enterprise systems can send customer, product, and behavioral data through Martini workflows, while supported Bloomreach callbacks can be received by Martini REST APIs.
Yes. Martini can integrate with Bloomreach Engagement by consuming its REST APIs, submitting event and batch data, orchestrating file-based exchanges, and exposing endpoints for supported webhook-style callbacks. A native Martini Bloomreach Engagement connector is not documented in the supplied context.
No. A dedicated Bloomreach Engagement connector is not required. Martini can use Bloomreach's confirmed REST APIs, event endpoints, batch mechanisms, file workflows, authentication methods, and selected webhook-style integrations.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Bloomreach Engagement. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Bloomreach, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs and event tracking endpoints are the primary mechanisms for new programmatic integrations. Bulk or batch APIs are appropriate for migrations and high-volume loads, while supported file workflows can handle larger scheduled exchanges. Webhook-style actions are secondary and should be used only after confirming the specific scenario and event coverage.
No. Bloomreach supports webhook-style outbound actions in selected scenario and engagement contexts, but they are not a universal event stream for every customer, campaign, catalog, or behavioral event. The configured feature, available event, authentication options, and payload must be verified before implementation.
Martini can run real-time, event-driven, or scheduled workflows. It retrieves or receives source data, maps customer, event, product, or catalog fields, applies identity and consent rules, submits REST or batch requests, and stores watermarks and processing outcomes for incremental synchronization.
Martini maps source-specific schemas into a canonical and Bloomreach-specific model, validates required fields, and applies business rules before submission. Workflows can classify validation, authentication, rate-limit, and transient failures, retry eligible requests, and use stable event identifiers or processing records to prevent accidental duplicate events.
Related Martini documentation
Workflows
Operations
Integrate Bloomreach Engagement with Martini
Use Martini to connect Bloomreach Engagement with commerce, CRM, ERP, service, and data platforms through governed APIs, workflows, mappings, and secure operational controls.