Ellipse Gradient for Header

inriver Integration Guide

Integrate inriver PIM with enterprise systems through REST APIs, selected webhook-style notifications, scheduled workflows, and controlled data synchronization.

inriver integration options at a glance

inriver’s primary integration mechanism is its REST API, which can be used to retrieve and update entities, fields, links, controlled vocabulary values, and channel-related configuration where exposed by the applicable tenant and API version. inriver also supports webhook-style notifications for selected events, although coverage and delivery behavior should be verified for each environment. API-key authentication is the confirmed primary security pattern. Martini can consume these APIs, receive selected notifications, orchestrate scheduled catalog synchronization, map localized and structured product data, apply validation and business rules, and expose controlled REST endpoints for downstream applications. Large catalogs can be processed with pagination, checkpoints, throttling, and retry handling.

Integration pointSupported by inriver?Common use casesHow Martini supports it
REST APIsYesThe primary inriver integration mechanism for retrieving and updating Entities and Fields, maintaining Links, querying Controlled Vocabulary Lists, and accessing tenant-exposed channel or publishing configuration.Martini can consume the inriver REST API from workflows, map request and response data, apply business rules, and expose a controlled API façade over inriver.
Webhooks / outbound callbacksLimitedinriver supports webhook-style notifications for selected changes and events. Coverage, payloads, retries, and configuration should be verified for the target tenant.Martini can expose an endpoint or use a webhook-consuming workflow to validate notifications, deduplicate them, retrieve current state through REST, and continue processing asynchronously.
AuthenticationLimitedAPI-key authentication is the confirmed primary pattern for the inriver REST API. OAuth 2.0, JWT, and Basic Authentication were not confirmed as standard current methods.Martini can store the API key in secrets management, inject it into requests, separate environment credentials, and prevent credentials from appearing in logs.
Scheduled synchronizationYesScheduled extraction is suitable for catalog synchronization, multi-channel exports, reconciliation, and recovery when event coverage is incomplete.Martini can start workflows on a schedule, paginate through REST results, persist progress or checkpoints, throttle requests, and resume failed runs.
Bulk / async / batch APIsNot confirmedA general-purpose inriver bulk or asynchronous API was not confirmed. Large-volume processing should be validated against the applicable API version and tenant configuration.Martini can implement controlled batches over standard REST operations with pagination, checkpointing, throttling, and retry handling where endpoint behavior permits.
File / attachment APIsNot confirmedProduct information may be associated with digital assets, but a generally available standalone file or attachment API was not verified.Martini can support file-based processing when an applicable inriver endpoint or external asset service is confirmed, but the mechanism should not be assumed.
Database accessNoDirect database or analytics access to inriver-managed product data was not confirmed and should not be used as the integration contract.Martini should consume supported inriver APIs instead; database capabilities in Martini do not imply direct access to inriver’s managed database.
GraphQL APIsNot confirmedNo official inriver GraphQL API documentation was verified in the supplied research.Martini can consume GraphQL APIs generally, but an inriver GraphQL integration should not be designed unless the tenant or vendor documentation confirms one.

How inriver exposes data and business events

inriver REST APIs

The inriver REST API is the primary confirmed mechanism for working with product information and related PIM objects. It can support retrieval and updates for Entities, Fields, Links, Controlled Vocabulary Lists, and tenant-exposed channel or publishing configuration.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with an API key stored as a Martini secret, calls the relevant inriver endpoint, handles pagination and response validation, transforms the result into a canonical model, and writes it to one or more target systems. For inbound updates, Martini validates the source request, applies business rules, and calls inriver only after dependency and vocabulary checks succeed.

Implementation sequence

Authenticate the request with an environment-specific inriver API key
Retrieve the current Entities, Fields, Links, or vocabulary values
Paginate through results and record progress where applicable
Map inriver data to the canonical integration model
Apply validation, ownership, channel, and publication rules
Write the transformed data to inriver or the downstream system and record the outcome

inriver webhook-style notifications

inriver supports webhook-style notifications for selected changes and events. Notifications should not be assumed to cover every entity, field, workflow, or publishing event, and the available payload and retry behavior must be confirmed for the tenant.

Martini implementation pattern

Martini implementation pattern: expose a controlled REST endpoint or webhook-consuming workflow, validate the incoming request, record an event identifier for replay protection, and retrieve the current inriver object through the REST API rather than relying solely on the notification payload. The workflow then maps and distributes the current state to downstream applications.

Implementation sequence

Receive the selected inriver notification
Validate the request and apply replay or idempotency controls
Retrieve the current Entity and related data through the REST API
Resolve Links, Channels, and Controlled Vocabulary values as required
Map and transform the current state for downstream systems
Retry transient failures and route unrecoverable events for investigation

Scheduled inriver synchronization

Scheduled workflows are appropriate for catalog extraction, multi-channel exports, reconciliation, and recovery when event coverage is incomplete. The exact filtering and pagination options depend on the applicable inriver API version and tenant.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that retrieves changed or in-scope Entities in pages, persists a checkpoint, applies channel and locale-specific mappings, and sends results to one or more targets. The workflow records item-level outcomes so a failed run can resume without reprocessing successful updates unnecessarily.

Implementation sequence

Start the catalog workflow on an agreed schedule
Load the last successful checkpoint and tenant-specific synchronization configuration
Retrieve the next page of inriver data
Transform localized fields, links, and vocabulary values
Upsert the result in each target system with idempotency controls
Persist progress and publish operational results for monitoring

Common inriver integration patterns

Pattern 1: Publish inriver products to Shopify

When to use this pattern

Use this pattern when inriver governs enriched product content and Shopify is responsible for storefront presentation. A scheduled workflow or selected inriver notification can initiate synchronization of approved, channel-specific products.

Integration direction
inriver
Martini
Shopify
Example Mapping
inriver FieldCanonical FieldTarget Field
Entity identifierproduct.externalIdShopify product handle or external reference
Localized product name Fieldproduct.titleShopify title
Localized description Fieldproduct.descriptionShopify description
Product-to-category Linkproduct.categoryShopify product category
Martini implementation pattern

Martini retrieves the current Entity, related Fields and Links, and applicable Channel configuration, then filters products by approval or publication status. It maps locales and structured values, validates mandatory storefront data, performs an idempotent Shopify update, and retries transient failures while reporting invalid products separately.

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

Pattern 2: Load ERP product master data into inriver

When to use this pattern

Use this pattern when SAP S/4HANA or NetSuite owns identifiers and commercial master data while inriver owns enriched descriptions, attributes, relationships, and channel content.

Integration direction
SAP S/4HANA or NetSuite
Martini
inriver
Example Mapping
inriver FieldCanonical FieldTarget Field
ERP material or item identifierproduct.externalIdinriver Entity identifier or external identifier
ERP product descriptionproduct.sourceDescriptioninriver description Field
ERP product statusproduct.lifecycleStatusinriver status Field
ERP product groupproduct.categoryCodeinriver category Link or CVL value
Martini implementation pattern

Martini retrieves source product changes, applies ownership rules so ERP-owned values are not overwritten by enrichment logic, translates source codes into inriver CVL values, validates required dependencies, and creates or updates Entities and Links. Failed records are isolated with source identifiers and can be retried after correction.

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

Pattern 3: Distribute event-driven product enrichment changes

When to use this pattern

Use this pattern when selected inriver changes should reach a commerce platform, CMS, or search index without waiting for a full catalog export.

Integration direction
inriver
Martini
Sitecore or Shopify
Example Mapping
inriver FieldCanonical FieldTarget Field
inriver event identifierevent.idworkflow idempotency key
Changed Entity identifierproduct.idTarget product identifier
Localized Fieldsproduct.localizedContentTarget localized product properties
Linksproduct.relationshipsTarget category or related-product references
Martini implementation pattern

Martini receives the selected notification, validates and deduplicates it, retrieves authoritative current state from inriver, and applies channel, status, locale, and dependency rules before updating the target. Retryable transport failures are retried; invalid mappings and unsupported events are recorded for correction or replay.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflow orchestration
  • data mapping
  • idempotency
  • error handling

Pattern 4: Export a multi-channel catalog

When to use this pattern

Use this pattern when the same inriver product model must be transformed into different schemas for regional storefronts, marketplaces, or content platforms.

Integration direction
inriver
Martini
Shopify, Adobe Commerce, and Sitecore
Example Mapping
inriver FieldCanonical FieldTarget Field
Channelpublication.channelTarget site or catalog scope
Localized name Fieldproduct.nameByLocaleLocalized target name
CVL valueproduct.standardizedAttributeTarget attribute code
Product-to-asset Linkproduct.mediaReferenceTarget media reference
Martini implementation pattern

A scheduled Martini workflow loads each Channel’s scope, retrieves data page by page, applies target-specific mappings for locales, vocabulary values, Links, and publication rules, and sends independent batches to each destination. Checkpoints and item-level results allow partial failures to be resumed without restarting the complete export.

Martini capabilities used
  • scheduler-triggered workflows
  • pagination orchestration
  • data mapping
  • transformation
  • business rules
  • monitoring

Applications commonly integrated with inriver

inriver commonly sits between product-information governance and commerce, ERP, customer-experience, and sales-channel applications. The following are realistic integration targets based on inriver’s PIM role; the exact direction, objects, fields, and ownership rules should be confirmed for each implementation.

Application Scenario Direction Martini Pattern
Shopify Publish enriched product descriptions, attributes, variants, identifiers, and selected media references to an online storefront. inriver → Martini → Shopify A scheduled or event-driven Martini workflow retrieves changed inriver Entities, resolves Fields and Links, applies channel and status rules, maps the result to Shopify’s product model, and performs idempotent create or update operations with retry handling.
Adobe Commerce Synchronize structured catalog data, categories, localized content, and product media references for commerce operations. inriver → Martini → Adobe Commerce Martini can paginate through inriver catalog data, translate controlled vocabulary values and locales, transform product relationships, and upsert the resulting catalog while recording checkpoints and partial failures.
Salesforce Commerce Cloud Distribute governed product information to digital commerce storefronts and regional sites. inriver → Martini → Salesforce Commerce Cloud A Martini workflow filters inriver data by Channel, maps localized Fields and product relationships into the target catalog structure, validates mandatory values, and retries transient downstream failures without duplicating updates.
SAP S/4HANA Combine ERP product identifiers and commercial master data with enriched product content managed in inriver. SAP S/4HANA → Martini → inriver Martini retrieves or receives SAP product data, maps stable identifiers and owned attributes to inriver Entities and Fields, translates values to inriver Controlled Vocabulary Lists, validates dependencies, and updates Links where required.
NetSuite Synchronize item master data and identifiers with enriched product information used for commerce and sales channels. NetSuite → Martini → inriver A Martini workflow reads NetSuite item data, applies field-ownership and upsert rules, resolves inriver entity and vocabulary identifiers, and writes validated changes through the inriver REST API with structured error reporting.
Sitecore Deliver product descriptions, attributes, and related product content to digital experience and web properties. inriver → Martini → Sitecore Martini can receive selected inriver notifications or run scheduled extraction, normalize localized and rich product data, map relationships to Sitecore content structures, and isolate failed items for replay.
Akeneo Exchange or consolidate product information during a PIM coexistence, migration, or domain-specific publishing architecture. inriver → Martini → Akeneo Martini can orchestrate a tenant-specific migration or coexistence workflow, map entity types, fields, links, locales, and vocabulary values between models, and use stable identifiers plus reconciliation reporting to prevent duplicates.
Salesforce Synchronize product names, descriptions, identifiers, and other governed product information used by sales and service processes. inriver → Martini → Salesforce A Martini workflow extracts approved inriver product data, applies publication and field-ownership rules, transforms it into the target product model, and sends validated updates with retry and duplicate protection.

How to build a inriver integration in Martini

Objective

Establish an environment-specific connection to inriver without embedding credentials in integration logic.

Instructions in Martini

  • Obtain the tenant-specific API base URL and API-key header requirements from inriver documentation or administrators.
  • Store the API key in Martini secrets management.
  • Use separate credentials and configuration for development, testing, and production where supported.
  • Define permission boundaries and key-rotation ownership.

Objective

Select the trigger that matches the synchronization requirement and the confirmed inriver capabilities.

Instructions in Martini

  • Use a Martini scheduler for catalog exports, reconciliation, and recovery runs.
  • Expose a controlled REST endpoint for selected inriver webhook-style notifications.
  • Use an inbound API or scheduled retrieval when event coverage is insufficient.
  • Document the selected entity, field, channel, and event scope.

Objective

Read the authoritative inriver state and its dependencies before transformation.

Instructions in Martini

  • Call the inriver REST API for Entities, Fields, Links, Channels, and CVL values in scope.
  • Implement the applicable pagination and incremental extraction model.
  • Retrieve current resource state after webhook notifications rather than trusting partial payloads.
  • Persist checkpoints or source identifiers for resumable processing.

Objective

Coordinate source calls, dependency resolution, target writes, and operational outcomes in a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, validation, transformation, and target delivery stages.
  • Resolve linked entities and vocabulary values before writing dependent objects.
  • Use conditional routing for channel, locale, lifecycle, and publication rules.
  • Keep reusable mapping and validation logic separate from tenant-specific configuration.

Objective

Convert the configurable inriver model into a stable canonical model and target-specific payloads.

Instructions in Martini

  • Map tenant-specific Entity types and Field names to canonical product attributes.
  • Handle localized values, structured fields, rich text, null-versus-empty values, and external identifiers explicitly.
  • Translate CVL values using stable identifiers where available.
  • Transform Links and Channel scope into each target application’s relationship and catalog model.

Objective

Prevent incomplete, unauthorized, or incorrectly scoped product data from reaching downstream systems or inriver.

Instructions in Martini

  • Validate mandatory identifiers, fields, relationships, and publication conditions.
  • Apply field ownership rules between ERP, inriver, and downstream applications.
  • Reject or quarantine values that do not match permitted controlled vocabularies.
  • Use idempotency keys or stable identifiers for all create-or-update operations.

Common inriver data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
EntitiesStore products and related product-master objects in the PIM.Shopify, Adobe Commerce, Salesforce Commerce Cloud, SAP S/4HANA, NetSuite, SitecoreMartini retrieves, creates, and updates Entities through REST workflows using tenant-specific identifiers, entity types, pagination, validation, and idempotent upsert logic.
FieldsRepresent product names, descriptions, identifiers, dimensions, localized content, and other attributes.Commerce platforms, ERP systems, Salesforce, digital experience platformsMartini maps Fields to canonical models, handles locales and structured values, distinguishes null from empty values, and applies field-ownership rules.
LinksRepresent relationships such as product-to-category, product-to-asset, and product-to-product associations.Commerce catalogs, CMS platforms, marketplaces, ERP and PIM coexistence solutionsMartini resolves dependent identifiers, creates or updates relationships in the correct order, and reports dependency failures separately from field errors.
ChannelsOrganize and distribute product information for market-facing or publishing contexts.Shopify, Adobe Commerce, Salesforce Commerce Cloud, Sitecore, marketplace platformsMartini filters and transforms data by Channel, applies channel-specific publication rules, and sends each target only the content in scope.
Controlled Vocabulary Lists (CVLs)Standardize values for fields such as categories, brands, statuses, or attributes.ERP systems, commerce platforms, data warehouses, other PIMsMartini retrieves and caches applicable values where appropriate, maps stable identifiers rather than display text alone, and validates values before writes.
Enrichment ProjectsCoordinate and manage product-information enrichment work.Workflow applications, reporting platforms, commerce and content systemsMartini can synchronize relevant project status or enrichment-related data when exposed by the tenant API, applying explicit scope and permission rules.

Authentication and security considerations

API-key authentication

API-key authentication is the primary confirmed authentication pattern for the inriver REST API. The exact header name, API base URL, and permission model should be verified for the target tenant.

  • Store API keys in Martini secrets management rather than workflow definitions.
  • Use separate credentials for development, testing, and production where supported.
  • Restrict key permissions to the operations required by the integration.
  • Rotate keys according to organizational policy and prevent credentials from appearing in logs or error payloads.

Webhook security

For selected inriver notifications, validate the incoming request and record event identifiers for replay protection. Retrieve authoritative resource state through the REST API before distributing changes.

Operational considerations for inriver integrations

Tenant-specific schemas

Entity types, Field names, Link types, Channels, Controlled Vocabulary Lists, permissions, and API behavior can vary between inriver tenants. Externalize configuration and avoid hard-coding assumptions into reusable workflows.

Pagination and rate limits

Large catalogs should be processed page by page with checkpoints, controlled concurrency, throttling, and appropriate backoff for rate-limit or temporary server responses.

Idempotency and ordering

Use stable inriver identifiers or agreed external identifiers for upserts. Webhook notifications may be duplicated or arrive out of order, so retrieve current state and make processing replay-safe.

Data quality and dependencies

Validate localized and structured Fields, Links, Channels, and CVL values before writes. Distinguish null from empty values and resolve dependencies in a defined order.

Testing and observability

Test representative entity types, locales, relationships, permissions, and failure responses in a non-production environment. Monitor request outcomes, checkpoints, retry counts, source identifiers, and downstream responses without logging credentials.

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

Orchestration beyond point-to-point scripts

Martini provides a maintainable workflow layer for coordinating inriver API calls, webhook intake, validation, transformation, target delivery, and operational handling. This avoids duplicating synchronization logic across individual scripts and applications.

Reusable integration assets

Teams can separate tenant configuration, mappings, validation, and business rules from workflow orchestration. Martini can also expose controlled REST APIs that provide an application-specific façade over inriver.

Operational control

  • Use schedules, event-driven workflows, pagination, checkpoints, and controlled retries.
  • Apply consistent mapping, localization, vocabulary, channel, and ownership rules.
  • Centralize secrets and distinguish retryable failures from data-quality or authorization errors.
  • Monitor workflow outcomes and support replay without creating duplicate target updates.

Frequently asked questions

How can inriver be integrated with enterprise systems?

inriver can be integrated primarily through its REST APIs, which expose product-related Entities, Fields, Links, Controlled Vocabulary Lists, and other tenant-configured PIM data. Selected webhook-style notifications can support event-driven processing, while scheduled workflows are suitable for catalog extraction, reconciliation, and multi-channel publishing.

Can Martini integrate with inriver?

Yes. Martini can consume the inriver REST API, receive selected inriver webhook-style notifications, orchestrate scheduled synchronization, map tenant-specific product data, and expose REST endpoints for controlled access to inriver information. A native Martini inriver connector is not documented in the supplied sources.

Do I need a connector to integrate inriver with Martini?

No. A dedicated inriver connector is not required. Martini can integrate using inriver’s confirmed REST API and API-key authentication, with selected webhook-style notifications where the target tenant supports the required events.

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

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

Which inriver integration methods should a new implementation use?

The inriver REST API is the recommended and primary confirmed mechanism. Use API-key authentication stored in Martini secrets, scheduled workflows for controlled catalog synchronization, and webhook-style notifications only for event types confirmed in the target tenant. GraphQL and SOAP APIs were not confirmed.

Are inriver events or webhooks available?

inriver supports webhook-style notifications for selected changes and events, but coverage should not be assumed for every Entity, Field, workflow, or publishing event. Martini can receive a notification, validate and deduplicate it, retrieve current state through REST, and continue the downstream workflow.

How does Martini synchronize large inriver catalogs?

Martini can use paginated REST requests, incremental filters or checkpoints where supported, controlled request rates, idempotent upserts, and retry handling. The workflow should avoid loading the full catalog into memory and should record progress so failed runs can resume.

How are inriver data mapping and failures handled?

Martini can map tenant-specific Entities, Fields, Links, Channels, locales, and Controlled Vocabulary values into canonical and target-specific models. Workflows can validate dependencies, distinguish authentication, validation, rate-limit, and transport failures, retry transient errors, and record item-level results without exposing API keys.

Related Martini documentation

APIs

Events

Workflows

Security

Operations

Integrate inriver with Martini

Use Martini to connect inriver product information with commerce, ERP, content, and sales applications through governed APIs, workflows, mappings, and event-driven synchronization.

EXPLORE MARTINI
BOOK A DEMO