Ellipse Gradient for Header

Dynamic Yield Integration Guide

Connect Dynamic Yield personalization, catalog, campaign, and behavioral data capabilities with enterprise systems through REST APIs, feeds, events, and controlled workflows.

Dynamic Yield integration options at a glance

Dynamic Yield primarily integrates through REST APIs for platform administration, catalogs, personalization, events, and related data operations. Catalog feeds and structured file exchange may support CSV, XML, or JSON depending on the tenant configuration. Behavioral events can be submitted from commerce platforms, applications, or customer data pipelines, while webhook-style callbacks may be available for selected features rather than universally. Dynamic Yield uses API credentials or API keys for server-to-server access. Martini can consume these APIs, retrieve and validate feeds, map catalog and event payloads, schedule batch synchronization, expose APIs for storefronts, and apply retries, deduplication, and business rules around each integration.

Integration pointSupported by Dynamic Yield?Common use casesHow Martini supports it
REST APIsYesManage or retrieve campaign and experience configuration, submit events, exchange catalog data, and access personalization, recommendation, audience, or reporting operations where enabled by the tenant.Martini can consume Dynamic Yield REST endpoints, map request and response payloads, apply business rules, and expose reusable APIs or workflows around them.
Webhooks and outbound callbacksLimitedSelected Dynamic Yield features may provide outbound notifications or callbacks, but coverage is not universal across objects and lifecycle events.Martini can expose an API endpoint and process supported callback requests, with validation, authentication, deduplication, and retry-aware handling.
Bulk, asynchronous, or batch processingLimitedBulk catalog and data-ingestion scenarios are relevant, although no single bulk interface for every Dynamic Yield object was confirmed.Martini can run scheduled batches, paginate documented endpoints, checkpoint progress, and retry transient failures around the applicable API or feed.
Catalog feeds and file exchangeLimitedCatalog data may be supplied through structured CSV, XML, or JSON feeds delivered through an approved URL or transfer mechanism, depending on configuration.Martini can retrieve feeds, parse and validate structured data, transform product fields, and submit or route the result to Dynamic Yield or another system.
AuthenticationYesServer-to-server requests use Dynamic Yield API credentials or API keys, with account, environment, site, section, and permission context varying by API.Martini stores credentials in secrets or protected environment configuration and applies them to controlled API workflows without embedding them in source or client-side responses.
Behavioral event collectionYesDynamic Yield accepts signals such as page views, product views, add-to-cart actions, purchases, and custom events when the relevant endpoint and payload are enabled.Martini can receive events from commerce or customer-data systems, normalize identifiers and consent fields, deduplicate messages, and forward supported event payloads.
SDKs and client-side integration librariesLimitedDynamic Yield provides client-side integration guidance or libraries for some personalization and event-collection scenarios, with the appropriate implementation depending on the application environment.Martini integrations should generally use documented HTTP APIs and event payloads; custom application SDK usage is not assumed inside Martini.
Database and analytics accessNot confirmedDirect access to Dynamic Yield-managed operational data or JDBC connectivity was not confirmed; analytics data should use documented APIs, exports, or supported destinations.Martini can write retrieved or transformed Dynamic Yield data to supported databases, but it should not connect directly to an unconfirmed Dynamic Yield database.

How Dynamic Yield exposes data and business events

Dynamic Yield REST APIs

Dynamic Yield provides REST-based APIs for platform, catalog, data, personalization, and related operations. Exact resources, fields, permissions, and available actions depend on the API and tenant configuration.

Martini implementation pattern

Martini implementation pattern: Martini workflows authenticate with protected Dynamic Yield API credentials, retrieve or submit resources, transform payloads, apply validation and business rules, and expose reusable APIs when downstream applications need a stable internal contract.

Implementation sequence

Authenticate with a protected Dynamic Yield API credential
Receive a request or start a scheduled workflow
Call the documented Dynamic Yield REST endpoint
Validate and transform the response or request payload
Apply object-specific business rules
Write the result to the target system and record execution status

Dynamic Yield Catalog Feeds

Dynamic Yield supports catalog ingestion through APIs or configured feeds. Depending on the tenant, structured catalog data may use CSV, XML, or JSON and may be delivered through an approved URL or transfer mechanism.

Martini implementation pattern

Martini implementation pattern: Martini retrieves the source catalog, parses the selected format, validates product identifiers and required attributes, maps the source model to Dynamic Yield’s catalog structure, and submits or routes accepted records while isolating failures.

Implementation sequence

Start the catalog workflow on a schedule
Retrieve the configured catalog API or feed
Parse the CSV, XML, or JSON payload
Validate identifiers, prices, categories, and availability
Map source products to Dynamic Yield Products
Submit accepted data and record rejected products

Dynamic Yield Events

Dynamic Yield uses behavioral and transactional events such as page views, product views, add-to-cart actions, purchases, and custom events as part of its personalization model. Event availability and payload requirements depend on the relevant endpoint and account configuration.

Martini implementation pattern

Martini implementation pattern: Martini receives events from a commerce platform, mobile backend, or customer-data pipeline, normalizes visitor and transaction identifiers, filters data using consent rules, deduplicates messages, and forwards supported event payloads to Dynamic Yield.

Implementation sequence

Receive a commerce or application event
Validate the event type and required identifiers
Apply consent, privacy, and normalization rules
Check the processing ledger for duplicates
Forward the supported event payload to Dynamic Yield
Store the delivery result and route failures for retry

Dynamic Yield Callbacks

Dynamic Yield may provide outbound notifications or callbacks for selected integration features, but universal webhook coverage for all objects and lifecycle events was not confirmed.

Martini implementation pattern

Martini implementation pattern: Martini exposes a secured API endpoint for the documented callback types, validates the sender and payload, applies idempotency controls, and invokes a workflow that updates downstream systems or requests additional Dynamic Yield data.

Implementation sequence

Receive a supported Dynamic Yield callback
Authenticate and validate the callback payload
Check the event identifier for duplicate delivery
Retrieve additional data when the feature requires it
Map the result to the downstream system
Acknowledge or record the callback outcome

Common Dynamic Yield integration patterns

Pattern 1: Synchronize product catalogs with Dynamic Yield

When to use this pattern

Use this pattern when product information is maintained in a commerce platform, product database, or ERP and Dynamic Yield requires current catalog data for recommendations, merchandising, or targeting.

Integration direction
Shopify
Martini
Dynamic Yield
Example Mapping
Dynamic Yield FieldCanonical FieldTarget Field
product_idproductIdentifierDynamic Yield Product identifier
pricecurrentPriceDynamic Yield price
inventory_statusavailabilityDynamic Yield availability
category_pathcategoryDynamic Yield category
Martini implementation pattern

A scheduled Martini workflow retrieves products, validates required identifiers and commercial attributes, normalizes currency and availability, filters discontinued items according to business rules, and submits catalog updates through the documented Dynamic Yield API or feed mechanism. It checkpoints batches and retries transient failures without resubmitting confirmed records.

Martini capabilities used
  • workflows
  • scheduling
  • API consumption
  • data mapping
  • validation
  • business rules
  • error handling

Pattern 2: Forward behavioral events to Dynamic Yield

When to use this pattern

Use this pattern when commerce platforms, mobile backends, or customer-data pipelines produce page views, product views, add-to-cart actions, purchases, or custom events that Dynamic Yield must use for personalization and attribution.

Integration direction
Segment
Martini
Dynamic Yield
Example Mapping
Dynamic Yield FieldCanonical FieldTarget Field
anonymousIdvisitorIdentifierDynamic Yield visitor context
userIdcustomerIdentifierDynamic Yield customer context
eventbehavioralEventTypeDynamic Yield event type
properties.productIdproductIdentifierDynamic Yield Product identifier
Martini implementation pattern

Martini receives or consumes events, applies consent and privacy filtering, normalizes visitor and transaction identities, checks a processing ledger for duplicates, enriches currency or channel context, and forwards supported events. Timeouts and transient responses are retried while validation failures are isolated for review.

Martini capabilities used
  • API exposure
  • workflows
  • data mapping
  • privacy rules
  • deduplication
  • error handling
  • retries

Pattern 3: Orchestrate real-time recommendations for a storefront

When to use this pattern

Use this pattern when a storefront backend needs a controlled internal API that hides Dynamic Yield credentials, combines recommendation results with enterprise data, or supplies fallback behavior when the vendor service is unavailable.

Integration direction
Salesforce Commerce Cloud
Martini
Dynamic Yield
Example Mapping
Dynamic Yield FieldCanonical FieldTarget Field
visitorIdvisitorIdentifierDynamic Yield visitor context
productIdcontextProductIdentifierDynamic Yield recommendation context
localemarketLocaleDynamic Yield locale context
recommendationspersonalizedItemsstorefront recommendation response
Martini implementation pattern

A Martini API receives the storefront request, authenticates the caller, enriches it with visitor, product, locale, or channel context, calls the documented Dynamic Yield personalization or recommendation endpoint, and maps the response to a stable internal contract. Business rules can apply inventory or pricing checks and return a defined fallback on timeout or vendor failure.

Martini capabilities used
  • API exposure
  • API consumption
  • workflow orchestration
  • data transformation
  • authentication
  • business rules
  • fallback handling

Pattern 4: Synchronize campaigns and audiences

When to use this pattern

Use this pattern when selected Dynamic Yield Campaigns, Audiences, or Experiences must be reflected in Salesforce, Braze, a warehouse, or an internal campaign-management process.

Integration direction
Dynamic Yield
Martini
Salesforce
Example Mapping
Dynamic Yield FieldCanonical FieldTarget Field
campaignIdcampaignIdentifierSalesforce campaign reference
audienceIdaudienceIdentifierSalesforce audience reference
statusactivationStatusSalesforce campaign status
startTimeactivationStartSalesforce start date
Martini implementation pattern

A scheduled workflow retrieves selected Dynamic Yield objects, maps supported fields, validates status and time-window rules, and writes the result to the target system. The workflow records the last successful checkpoint where the API supports incremental retrieval; otherwise it uses controlled full or filtered retrievals and avoids assuming all fields are writable.

Martini capabilities used
  • scheduling
  • API consumption
  • pagination
  • mapping
  • validation
  • business rules
  • checkpointing
  • monitoring

Applications commonly integrated with Dynamic Yield

Dynamic Yield commonly sits within commerce, customer-data, marketing, and analytics architectures. The exact objects and direction of exchange depend on the Dynamic Yield API, tenant configuration, and the responsibilities assigned to each adjacent application.

Application Scenario Direction Martini Pattern
Shopify Synchronize product catalog attributes and behavioral events with Dynamic Yield for recommendations, targeting, and personalization. Shopify → Martini → Dynamic Yield A scheduled Martini workflow reads products and relevant commerce events, normalizes identifiers, prices, availability, currency, and consent fields, validates the payload, and submits catalog or event data through the documented Dynamic Yield interface.
Salesforce Commerce Cloud Combine storefront activity and product data with Dynamic Yield recommendations, campaigns, and experimentation experiences. Salesforce Commerce Cloud → Martini → Dynamic Yield Martini consumes commerce APIs or inbound events, maps storefront and visitor context to Dynamic Yield payloads, and can expose a normalized recommendation API for the storefront while handling fallback and retry behavior.
Adobe Commerce Send catalog and behavioral data to Dynamic Yield and return personalized recommendations or campaign decisions to the storefront. Adobe Commerce → Martini → Dynamic Yield Martini orchestrates scheduled catalog retrieval and real-time event forwarding, applies product and visitor identity rules, and records rejected records for controlled replay.
Salesforce Coordinate customer, campaign, or audience-related information with Dynamic Yield personalization and marketing experiences where the relevant APIs support the required objects. Salesforce → Martini → Dynamic Yield A Martini workflow retrieves selected Salesforce data, applies explicit object-level mappings and privacy rules, and synchronizes only supported Dynamic Yield fields; reverse synchronization can be implemented where the Dynamic Yield API permits writes.
Segment Forward behavioral events and audience signals through a centralized customer-data pipeline before sending them to Dynamic Yield. Segment → Martini → Dynamic Yield Martini receives or consumes normalized Segment events, maps visitor and transaction identifiers, filters by consent, deduplicates events, and forwards supported event payloads to Dynamic Yield.
Braze Coordinate personalization or recommendation signals with lifecycle messaging and customer engagement programs. Dynamic Yield → Martini → Braze Martini retrieves supported Dynamic Yield campaign, audience, or recommendation data, transforms it into Braze-compatible payloads, and applies routing, validation, and retry policies before delivery.
Snowflake Centralize Dynamic Yield event, campaign, or performance data for analytics, attribution, and reporting. Dynamic Yield → Martini → Snowflake Martini retrieves documented Dynamic Yield API or export data, converts it to warehouse-ready structures, and writes batches to Snowflake through a supported database or file-based workflow; direct Dynamic Yield database access is not assumed.
Google Analytics 4 Compare personalization and experimentation outcomes with web and conversion analytics. Dynamic Yield → Martini → Google Analytics 4 Martini consumes supported Dynamic Yield results or a shared event stream, normalizes campaign and conversion context, and forwards eligible analytics events while preserving consent and deduplication rules.

How to build a Dynamic Yield integration in Martini

Objective

Establish the Dynamic Yield API connection with tenant-appropriate credentials and environment context while keeping server-side secrets out of workflows and client responses.

Instructions in Martini

  • Store API keys in Martini secrets or protected environment configuration
  • Confirm the Dynamic Yield account, site, section, environment, and permissions
  • Use separate credentials for development, staging, and production where available
  • Configure the required endpoint headers and request context

Objective

Select the event, API request, or schedule that starts the integration according to the freshness and latency requirements of the data flow.

Instructions in Martini

  • Use an exposed Martini API for storefront or event-driven requests
  • Use a webhook-consuming workflow only for documented Dynamic Yield callback types
  • Use a scheduler for catalog, campaign, audience, or reporting synchronization
  • Define the processing checkpoint or time window for recurring jobs

Objective

Collect Dynamic Yield data or upstream source data while handling pagination, feed formats, and tenant-specific endpoint behavior explicitly.

Instructions in Martini

  • Call the documented REST endpoint or retrieve the configured catalog feed
  • Parse JSON, XML, or CSV according to the configured source
  • Implement endpoint-specific pagination or continuation handling
  • Capture request identifiers, source IDs, and response status for observability

Objective

Coordinate API calls, enrichment, validation, routing, and target writes in a maintainable Martini workflow rather than embedding the entire process in a single script.

Instructions in Martini

  • Separate retrieval, transformation, business rules, and delivery stages
  • Use reusable workflow logic for common Dynamic Yield request patterns
  • Route validation failures separately from transient vendor failures
  • Persist checkpoints or processing-ledger entries where replay safety requires them

Objective

Convert commerce, visitor, event, campaign, catalog, and recommendation structures into the target Dynamic Yield or enterprise model.

Instructions in Martini

  • Map stable product, visitor, customer, campaign, and event identifiers
  • Normalize currency, locale, timestamps, availability, and category values
  • Filter unnecessary personal information and apply consent rules
  • Validate required fields and supported enumerations before submission

Objective

Apply tenant and enterprise rules that govern eligibility, privacy, deduplication, fallback behavior, and supported object operations.

Instructions in Martini

  • Reject incomplete products or events before calling Dynamic Yield
  • Use stable transaction or event identifiers when available
  • Avoid writing Dynamic Yield fields that the relevant API does not support
  • Apply inventory, pricing, audience, and campaign activation rules where required

Common Dynamic Yield data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ExperiencesPersonalization or experimentation configurations delivered to visitors.Commerce storefronts, mobile applications, campaign platforms, analytics systemsMartini retrieves or submits supported Experience fields through documented APIs, validates configuration data, and maps it to downstream models.
CampaignsContainers for targeting, scheduling, experience delivery, and measurement behavior.Salesforce, Braze, data warehouses, campaign-management applicationsMartini synchronizes selected Campaign properties using explicit mappings and avoids assuming that every property is writable.
VariationsAlternative versions of an Experience used for personalization or A/B testing.Storefronts, content systems, analytics platformsMartini can transform supported Variation data for downstream reporting or API responses and preserve campaign and experience relationships.
ProductsCatalog items used by recommendations, merchandising, targeting, and product-data workflows.Shopify, Salesforce Commerce Cloud, Adobe Commerce, NetSuite, product databasesMartini retrieves product data, validates identifiers, price, category, currency, availability, and URLs, then submits catalog updates or feeds.
VisitorsAuthenticated or anonymous identities used for personalization and event attribution.Commerce platforms, Segment, customer-data platforms, analytics systemsMartini applies visitor, customer, device, and session identity rules while filtering unnecessary personal data and maintaining consistent identifiers.
EventsBehavioral or transactional signals such as views, add-to-cart actions, purchases, and custom events.Commerce platforms, Segment, mobile backends, data warehousesMartini receives, validates, deduplicates, enriches, and forwards supported Events, while recording outcomes for retry or replay.

Authentication and security considerations

API credentials and environment context

Dynamic Yield server-to-server APIs generally use tenant- or environment-specific API keys or credentials. Requests may also require account, site, section, environment, or deployment context, with permissions determined by the credential and operation.

Secrets and identity protection

Store Dynamic Yield credentials in Martini secrets or protected environment configuration. Do not expose server-side API keys in browser code or client-facing API responses, and use separate credentials for environments where available.

Visitor and privacy controls

Visitor identifiers, customer identifiers, device identifiers, and session context should be mapped deliberately. Apply consent, regional privacy, data-retention, and data-minimization rules before forwarding behavioral events.

  • Validate inbound requests and callback payloads before processing.
  • Limit credentials to the Dynamic Yield operations required by each workflow.
  • Keep vendor credentials separate from visitor or customer identifiers.

Operational considerations for Dynamic Yield integrations

Rate limits and retries

Confirm limits for each Dynamic Yield API. Use controlled retries with backoff and jitter for throttling and transient 5xx responses, and prefer catalog feeds or batch mechanisms for large updates when supported.

Pagination and checkpoints

Implement endpoint-specific pagination and persist page, continuation, last-processed identifier, or other checkpoint data where applicable. Do not assume that every Dynamic Yield endpoint uses the same pagination or incremental-sync model.

Idempotency and schema changes

Use stable event or transaction identifiers where available, maintain a processing ledger for replay-sensitive events, and key catalog updates by stable product identifiers. Validate required fields and monitor changes to event, catalog, campaign, audience, and recommendation schemas.

Testing and observability

  • Test visitor identity, consent filtering, catalog quality, campaign timing, and recommendation fallbacks in non-production environments.
  • Capture HTTP status, request identifiers, source IDs, response bodies, and Martini workflow execution IDs.
  • Separate rejected records from retryable vendor or network failures.
  • Monitor event acceptance, catalog rejection, response latency, and recommendation availability.

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

Reusable orchestration

Martini coordinates Dynamic Yield API calls, catalog feeds, event forwarding, downstream writes, and callback handling in workflows that can be reused across channels and environments.

Controlled transformation

Mappings, validation, privacy filtering, identity normalization, business rules, and fallback behavior are kept explicit rather than scattered across scripts or point-to-point implementations.

Operational resilience

Martini provides a place to implement scheduling, pagination, checkpoints, retries, error routing, monitoring, and replay controls around Dynamic Yield’s tenant-specific APIs and feed mechanisms.

Stable internal APIs

Martini can expose APIs that shield storefronts and internal applications from vendor credentials and changing vendor payloads while combining Dynamic Yield results with enterprise data such as pricing, inventory, or customer context.

Frequently asked questions

How can Dynamic Yield be integrated with enterprise systems?

Dynamic Yield can be integrated through its REST APIs for catalog, platform, personalization, event, campaign, audience, and related data operations. Catalog feeds may use configured CSV, XML, or JSON exchange, while behavioral events can be submitted from commerce, mobile, or customer-data systems. Selected features may also support callback-style notifications.

Can Martini integrate with Dynamic Yield?

Yes. Martini can consume Dynamic Yield REST APIs, retrieve and transform catalog feeds, forward supported behavioral events, process selected callback or webhook requests, and expose APIs that provide a controlled interface for storefronts and downstream systems.

Do I need a connector to integrate Dynamic Yield with Martini?

No. A dedicated Dynamic Yield connector is not required. Martini can use Dynamic Yield’s confirmed native integration mechanisms, including REST APIs, catalog feeds, event endpoints, API-key authentication, and supported callbacks.

Is there any extra Lonti cost to integrate Dynamic Yield with Martini?

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

Which Dynamic Yield integration methods should an enterprise use?

REST APIs are the primary method for current Dynamic Yield integrations. Catalog feeds or batch ingestion are appropriate for larger product-data loads, and event endpoints are appropriate for behavioral signals. Webhook-style callbacks should be used only for feature-specific event types confirmed by Dynamic Yield. GraphQL and SOAP were not confirmed as supported Dynamic Yield mechanisms.

Are Dynamic Yield webhooks or outbound events available?

Dynamic Yield supports behavioral event collection, and selected features may provide outbound notifications or callbacks. Coverage, payloads, retry behavior, and delivery guarantees are feature-specific, so webhook support should not be assumed for every Dynamic Yield object or event. Martini can receive confirmed callbacks through an exposed API endpoint.

How does Martini synchronize Dynamic Yield data?

Martini can run real-time API workflows for events and recommendations or scheduled workflows for catalogs, campaigns, audiences, and reporting data. Where an endpoint supports pagination, updated-since filters, or checkpoints, Martini can use them; otherwise, synchronization should use controlled full or filtered retrievals.

How does Martini handle Dynamic Yield mapping, errors, and duplicate events?

Martini maps vendor-specific payloads to canonical and target models, validates required fields, and applies privacy and business rules before delivery. Workflows can distinguish validation failures from authentication, throttling, network, and service errors, retry transient failures with backoff, and use stable event or transaction identifiers plus a processing ledger to reduce duplicates.

Related Martini documentation

APIs

Workflows

Data

Security

Operations

Connect Dynamic Yield to your enterprise systems

Use Martini to build maintainable Dynamic Yield integrations for catalogs, behavioral events, personalization, campaigns, audiences, and downstream analytics without locking business logic into point-to-point scripts.

EXPLORE MARTINI
BOOK A DEMO