Ellipse Gradient for Header

Spryker Integration Guide

Integrate Spryker commerce data with enterprise systems through REST APIs, selected webhook events, data imports, and secure OAuth-based access.

Spryker integration options at a glance

Spryker integrations primarily use the REST-based Glue API and other documented REST resources for products, categories, customers, carts, orders, marketplace data, and related commerce capabilities. Selected modules and project configurations can provide webhook-style notifications for event-driven processing. Spryker also supports data-import and batch-oriented processes, while asset and file handling depends on the enabled implementation. Protected APIs commonly use OAuth 2.0 bearer tokens, client credentials, scopes, and HTTPS. Martini can consume these APIs, receive configured webhook requests, schedule paginated synchronizations, process files, transform JSON payloads, apply business rules, and expose normalized APIs for downstream systems.

Integration pointSupported by Spryker?Common use casesHow Martini supports it
REST APIsYesSpryker Glue API and other REST resources support products, categories, customers, carts, orders, marketplace resources, and related commerce operations. Available resources depend on installed modules and project configuration.Martini can consume Spryker REST endpoints, authenticate requests, map JSON responses, apply business rules, and expose normalized APIs or workflows to downstream systems.
Webhooks and outbound callbacksLimitedSelected Spryker modules and projects can emit webhook-style notifications for configured business events. Coverage is not universal across all objects or events.Martini can expose an API endpoint to receive notifications, validate and deduplicate them, retrieve the current Spryker resource, and route normalized events.
Bulk, asynchronous, and batch processingLimitedSpryker supports data-import and batch-oriented processing, but general-purpose bulk behavior varies by resource, module, and implementation.Martini can schedule imports, page through REST resources, split large datasets, process files, store checkpoints, and retry individual batches.
File and asset handlingLimitedSpryker supports commerce-related assets and file-oriented import or export processes, but a universal arbitrary attachment API was not confirmed.Martini can process supported files and asset references, transform metadata, and invoke the specific Spryker asset, import, export, or storage capability enabled in the environment.
AuthenticationYesProtected Spryker APIs commonly use OAuth 2.0, client credentials or other client-based flows, bearer tokens, scopes, permissions, and HTTPS.Martini can manage environment-specific authentication configuration and secrets, obtain or use bearer tokens, and send authorized API requests over TLS.
Database accessLimitedSpryker uses databases internally, but direct database access is implementation-specific and is not the preferred business integration boundary.Martini can connect to permitted databases where required for specialized extraction or reporting, but API and supported import mechanisms should normally be used for business writes.
GraphQL APIsNot confirmedA generally available, primary Spryker GraphQL integration surface was not confirmed. GraphQL may exist in particular modules or projects and must be verified per environment.Martini can consume GraphQL when a target Spryker implementation explicitly exposes and documents it, but it should not be assumed for a standard integration.
SOAP APIsNot confirmedNo current general-purpose Spryker SOAP API was confirmed; custom or legacy project services would require separate verification.Martini can consume SOAP services when a specific Spryker implementation exposes them, but REST APIs remain the documented starting point.

How Spryker exposes data and business events

Spryker REST APIs

Spryker’s Glue API and other documented REST APIs are the primary integration surface for commerce resources. They can support retrieval and updates for Products, Categories, Customers, Carts, Orders, marketplace resources, and other modules enabled in the target project.

Martini implementation pattern

Martini implementation pattern: Martini authenticates with the Spryker environment, calls the required REST resources, handles pagination and response validation, maps JSON into a canonical model, applies business rules, and writes to downstream applications or exposes a normalized API.

Implementation sequence

Configure the Spryker base URL, OAuth client, scopes, and environment secrets
Authenticate and obtain an authorized bearer token
Call the required Spryker REST resource
Process pagination and preserve the synchronization checkpoint
Map Spryker JSON into the canonical data model
Apply validation, routing, and business rules‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌

Spryker Webhooks and Callbacks

Spryker supports webhook-style notifications for selected events when the relevant modules and project configuration expose them. Notifications may contain a complete resource or only an identifier, and coverage is selective rather than universal.

Martini implementation pattern

Martini implementation pattern: Martini exposes an authenticated endpoint, validates the incoming request, acknowledges quickly, deduplicates the notification, retrieves the current Spryker resource when needed, and routes the normalized event to downstream workflows. A scheduled reconciliation process can cover missed or delayed notifications.

Implementation sequence

Expose a Martini API endpoint for the configured Spryker notification
Validate the sender, credentials, event type, and request structure
Persist an event or resource key for duplicate detection
Acknowledge the notification and start asynchronous processing
Retrieve the current Spryker resource when the payload is incomplete
Map and route the event to downstream applications‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍

Spryker Data Imports and Batch Processing

Spryker provides data-import and batch-oriented capabilities for commerce data, although the exact process varies by resource and installed module. Large product, price, inventory, or category loads should not assume unrestricted bulk writes through every REST endpoint.

Martini implementation pattern

Martini implementation pattern: Martini schedules or receives an import, reads Spryker pages or supported files, partitions the workload, transforms each batch, applies throttling and idempotent upserts, and records checkpoints so processing can resume after a failure.

Implementation sequence

Define the import scope, source, schedule, and checkpoint strategy
Retrieve Spryker pages, exports, or supported import files
Split the dataset into bounded processing batches
Transform records and preserve store, locale, and currency context
Write each batch using controlled concurrency and idempotent keys
Store progress and route failed batches for retry or reconciliation

Common Spryker integration patterns

Pattern 1: Synchronize Spryker products to search

When to use this pattern

Use this pattern when Spryker is the commerce catalog source and a search platform needs current product, category, offer, price, or availability data. The flow should preserve the distinction between Products and Product Offers and support full rebuilds as well as incremental updates where the project provides them.

Integration direction
Spryker
Martini
Algolia
Example Mapping
Spryker FieldCanonical FieldTarget Field
idproductIdobjectID
nameproductNamename
abstractSkuproductSkusku
pricesellingPriceprice
Martini implementation pattern

A scheduled Martini workflow retrieves paginated Spryker Products, Product Offers, Categories, and relevant pricing or availability data. It transforms localized and store-specific fields into search documents, filters incomplete items, upserts stable identifiers, throttles requests, and retries failed indexing operations without duplicating documents.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination and checkpointing
  • data mapping
  • business rules
  • error handling

Pattern 2: Orchestrate Spryker orders with an ERP

When to use this pattern

Use this pattern when submitted Spryker Orders must be transferred to SAP S/4HANA or NetSuite for fulfillment, invoicing, inventory, or financial processing. It is also appropriate when ERP status must be returned to Spryker through supported order or shipment resources.

Integration direction
Spryker
Martini
SAP S/4HANA
Example Mapping
Spryker FieldCanonical FieldTarget Field
orderReferenceorderNumberSalesOrder
customerReferencecustomerIdBusinessPartner
orderItems[].skulineItemSkuProduct
totals.grandTotalorderTotalNetValue
Martini implementation pattern

Martini retrieves new or changed Orders, validates required customer, item, payment, and shipment data, maps the order to the ERP model, and stores the Spryker-to-ERP correlation. It checks permitted order-state transitions, retries transient failures, and prevents duplicate order creation through lookup or an integration ledger.

Martini capabilities used
  • REST API orchestration
  • data mapping
  • validation
  • business rules
  • correlation tracking
  • retry and duplicate handling

Pattern 3: Synchronize Spryker customers with CRM

When to use this pattern

Use this pattern when Spryker Customers, addresses, or B2B Companies need to be shared with Salesforce or another customer-facing application. The design should define ownership for personal data, conflict resolution, consent, and anonymization before enabling bidirectional updates.

Integration direction
Spryker
Martini
Salesforce
Example Mapping
Spryker FieldCanonical FieldTarget Field
idcustomerIdExternalCustomerId
emailemailAddressEmail
firstNamegivenNameFirstName
addresses[].address1streetAddressMailingStreet
Martini implementation pattern

Martini consumes Spryker customer data on a schedule or from selected notifications, normalizes addresses and identifiers, applies privacy and ownership rules, and upserts Salesforce records. Reverse updates are filtered to approved fields, with conflict detection, retry handling, and reconciliation for missed events.

Martini capabilities used
  • scheduled and event-driven workflows
  • API consumption
  • field mapping
  • privacy rules
  • idempotent upserts
  • reconciliation

Pattern 4: Process selected Spryker commerce events

When to use this pattern

Use this pattern when the Spryker project exposes webhook-style notifications for selected product, inventory, order, or marketplace events. Because event coverage is module-dependent, retain scheduled reconciliation for resources that do not provide reliable notifications.

Integration direction
Spryker
Martini
Salesforce
Example Mapping
Spryker FieldCanonical FieldTarget Field
eventTypecommerceEventTypeeventName
resourceIdresourceReferenceExternalId
occurredAteventTimestampActivityDate
Martini implementation pattern

Martini receives the notification through an exposed API, authenticates and validates it, records a deduplication key, and acknowledges promptly. A workflow then retrieves the current Spryker object, enriches it with the required context, routes it to Salesforce or another target, and sends exhausted failures to a retry or reconciliation path.

Martini capabilities used
  • API exposure
  • webhook consumption
  • event validation
  • deduplication
  • workflow orchestration
  • error handling

Applications commonly integrated with Spryker

Spryker commonly participates in composable commerce architectures alongside product, customer, ERP, tax, search, content, and fulfillment applications. The exact integration boundary depends on the installed Spryker modules, project configuration, and system-of-record decisions.

Application Scenario Direction Martini Pattern
Salesforce Synchronize Spryker customers, accounts, orders, and commerce activity with CRM and service processes. Spryker → Martini → Salesforce Martini can retrieve or receive selected Spryker commerce changes, map customer and order data to Salesforce models, apply ownership and privacy rules, and retry or reconcile failed updates.
SAP S/4HANA Exchange products, pricing, inventory, customers, orders, invoices, and fulfillment information between commerce and enterprise resource planning processes. Spryker → Martini → SAP S/4HANA Martini can orchestrate REST calls and scheduled workflows in both directions, normalize identifiers and units, apply order-state rules, and maintain correlation between Spryker and SAP documents.
Akeneo Publish product information, attributes, and category data from a product information management system into the Spryker catalog. Akeneo → Martini → Spryker Martini can consume Akeneo exports or APIs, transform product and category structures into Spryker resource representations, split large loads, and record checkpoints for replay.
NetSuite Coordinate orders, customers, inventory, fulfillment, and financial information between Spryker and an ERP platform. Spryker → Martini → NetSuite Martini can retrieve Spryker Orders and Customers, map them to NetSuite records, correlate external identifiers, and send status or inventory updates back through the applicable APIs.
Contentful Supply editorial, landing-page, and merchandising content to commerce experiences or the storefront layer. Contentful → Martini → Spryker Martini can retrieve published Contentful content, transform localized and market-specific fields, apply publication rules, and deliver the resulting content references to the relevant Spryker or storefront API.
Algolia Index Spryker products, categories, prices, and availability for search and discovery experiences. Spryker → Martini → Algolia Martini can schedule or trigger product-index updates, flatten Spryker Products and Product Offers into search documents, filter incomplete data, and retry failed indexing requests.
Avalara Calculate or validate sales tax during cart and checkout processes where the project uses Avalara for tax determination. Spryker → Martini → Avalara Martini can map cart, customer, address, and line-item data to Avalara requests, return tax results to the appropriate Spryker process, and apply validation and transient-error handling.
DHL Exchange shipment information, shipping options, labels, and tracking updates with fulfillment processes. Spryker → Martini → DHL Martini can route Spryker order and shipment data to DHL-related APIs, normalize tracking references, update Spryker where supported, and reconcile delayed or failed carrier responses.

How to build a Spryker integration in Martini

Objective

Establish an environment-specific connection to Spryker using the API base URL, OAuth client configuration, scopes, and HTTPS.

Instructions in Martini

  • Store OAuth client secrets and API URLs as environment-specific Martini secrets.
  • Confirm the target Glue API or other Spryker REST surface and permitted resources.
  • Use bearer tokens and scopes appropriate to the workflow rather than broad permissions.

Objective

Select a scheduled, API-led, or event-driven trigger based on Spryker event coverage and synchronization requirements.

Instructions in Martini

  • Use a Spryker webhook or callback where the required event is explicitly enabled.
  • Use a scheduler for reconciliation, incremental synchronization, and large data imports.
  • Expose a Martini API when Spryker or another application needs to invoke the integration.

Objective

Retrieve the current Spryker resource or accept the incoming event payload while accounting for pagination, incomplete notifications, and module-specific schemas.

Instructions in Martini

  • Call the required REST resource and process all pages or batches.
  • Treat webhook payloads as potentially incomplete and retrieve the current object by identifier when necessary.
  • Preserve store, locale, currency, seller, and marketplace context.

Objective

Coordinate validation, enrichment, routing, downstream API calls, and checkpoint management in a maintainable Martini workflow.

Instructions in Martini

  • Separate event acknowledgement from longer downstream processing where appropriate.
  • Use correlation identifiers for Spryker Orders, Customers, Products, Product Offers, and external documents.
  • Route resource-specific logic through reusable workflow components or services where useful.

Objective

Convert Spryker JSON and supported import data into canonical models and target-specific payloads.

Instructions in Martini

  • Keep Products and Product Offers distinct in marketplace flows.
  • Normalize identifiers, addresses, prices, currencies, locales, and date formats.
  • Handle optional fields and project-specific extensions without assuming every Spryker module is installed.

Objective

Enforce data quality, order-state, privacy, ownership, and routing rules before writing to target systems.

Instructions in Martini

  • Validate required fields and permitted Spryker order-state transitions.
  • Apply consent, retention, anonymization, and conflict-resolution policies for Customers and Companies.
  • Use stable keys and lookup-before-create or upsert logic for non-idempotent targets.

Common Spryker data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ProductsSynchronize product abstracts, concrete products, attributes, prices, and metadata across catalog and commerce processes.Akeneo, Algolia, SAP S/4HANA, data warehousesMartini retrieves paginated resources, preserves product identifiers and store context, separates metadata from price or availability updates, and performs idempotent upserts.
Product OffersRepresent seller-specific or merchant-specific offers associated with products in marketplace implementations.Algolia, SAP S/4HANA, marketplaces, analytics platformsMartini keeps Product Offers distinct from Products, maps seller and offer identifiers, applies availability and pricing rules, and handles module-specific fields as optional.
CategoriesRepresent product classification and category-tree structures used by catalogs and discovery experiences.Akeneo, Algolia, storefronts, data warehousesMartini transforms category hierarchies, preserves parent-child relationships and store or locale context, and processes changes through scheduled or incremental workflows.
CartsCoordinate shopping-cart items, prices, promotions, customer context, and checkout state.Avalara, payment platforms, fulfillment systems, analytics platformsMartini maps cart and line-item data, validates totals and addresses, applies tax or checkout rules, and avoids replaying non-idempotent operations.
OrdersExchange submitted purchases, order items, totals, payments, shipments, and order state with enterprise systems.SAP S/4HANA, NetSuite, fulfillment platforms, SalesforceMartini correlates Spryker order references with external identifiers, validates permitted state transitions, routes fulfillment updates, and records retry state.
CustomersSynchronize customer accounts, addresses, authentication details, and customer-specific commerce data.Salesforce, NetSuite, identity platforms, customer-service applicationsMartini applies field-level mappings, consent and privacy rules, conflict resolution, deduplication, and deletion or anonymization policies.

Authentication and security considerations

OAuth and bearer tokens

Protected Spryker APIs commonly use OAuth 2.0 client-based flows and bearer access tokens. The client, token endpoint, scopes, and permitted resources vary between Glue API, Back Office API, installed modules, and environments.

Environment-specific secrets

Store OAuth credentials, access tokens, API URLs, and webhook credentials in Martini environment configuration or secrets rather than workflow mappings or source-controlled files.

Transport and authorization

  • Use HTTPS for Spryker API and webhook communication.
  • Request only the scopes and permissions required by each workflow.
  • Validate inbound webhook credentials and event structure before processing.
  • Separate development, staging, and production credentials.

Operational considerations for Spryker integrations

Pagination and throughput

Spryker collections may be paginated, and rate limits or infrastructure capacity vary by environment. Use checkpoints, controlled concurrency, throttling, and exponential backoff for large synchronizations.

Idempotency and reconciliation

Webhook deliveries, retries, and restarts can produce duplicates. Use stable Product, Product Offer, Customer, Cart, Order, event, or external references and retain an integration ledger when necessary. Maintain scheduled reconciliation for selective or unreliable event coverage.

Schema and module variation

Resources, fields, relationships, permissions, store context, and order-state transitions depend on Spryker version, installed modules, marketplace configuration, and project extensions. Validate mappings against the target environment and treat optional fields conservatively.

Testing and monitoring

Test representative Products, Product Offers, Customers, Carts, Orders, stores, currencies, locales, and failure conditions. Monitor workflow logs, token failures, pagination progress, downstream responses, retries, and dead-letter or reconciliation paths.

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

Centralized orchestration

Martini provides a maintainable workflow layer between Spryker and ERP, CRM, search, tax, content, fulfillment, and other enterprise systems instead of embedding separate scripts in each point-to-point connection.

Reusable integration logic

Teams can reuse authentication configuration, mappings, validation, business rules, retry handling, correlation, and reconciliation patterns across Spryker resources and target applications.

Flexible API-led integration

Martini can consume Spryker REST APIs, receive selected webhook events, process supported files or imports, and expose normalized APIs without requiring a dedicated vendor connector.

Operational control

Workflows make pagination, checkpoints, idempotency, error routing, monitoring, and environment-specific deployment concerns explicit and easier to operate than unmanaged scripts.

Frequently asked questions

How can Spryker be integrated with enterprise systems?

Spryker is primarily integrated through its REST-based Glue API and other documented REST resources. Selected modules and project configurations can provide webhook-style notifications, while data-import and batch processes support larger catalog or commerce loads. OAuth-based bearer authentication and HTTPS protect API access.

Can Martini integrate with Spryker?

Yes. Martini can consume Spryker REST APIs, receive configured webhook or callback events, process supported imports and files, transform Spryker JSON, orchestrate downstream applications, and expose APIs for Spryker or related systems.

Do I need a connector to integrate Spryker with Martini?

No. A dedicated Spryker connector is not required. Martini can integrate using Spryker’s confirmed native mechanisms, including REST APIs, selected webhook or callback events, supported import processes, files, and OAuth-based authentication.

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

Lonti does not charge an additional per-connector or per-vendor fee to integrate Spryker. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Spryker, cloud infrastructure, logistics providers, tax services, or other third-party systems.

Which Spryker APIs or integration methods should be used?

The Spryker Glue API and other documented REST APIs are the primary starting point for commerce integrations. The appropriate resources depend on whether the use case involves Products, Customers, Carts, Orders, marketplace data, back-office functions, or project-specific modules. Webhooks and batch imports should be evaluated for event-driven or high-volume requirements.

Can Martini receive Spryker events or webhooks?

Martini can receive HTTP webhook requests through an exposed API. Spryker webhook coverage is selective and depends on the installed modules and project configuration, so the target environment must confirm which events are exposed, how they are authenticated, and whether the payload contains a complete resource.

How are Spryker data synchronization and transformations handled?

Martini can run scheduled or event-driven workflows that retrieve paginated Spryker resources, transform JSON into canonical models, preserve store and locale context, and write to target applications. Checkpoints, stable identifiers, idempotent upserts, and reconciliation workflows support reliable synchronization.

How does Martini handle Spryker errors, retries, and duplicate events?

Martini workflows can validate payloads, apply controlled retries and backoff for transient failures, record correlation and checkpoint data, and route exhausted failures for investigation. Webhook and order flows should use stable Spryker or external identifiers, deduplication, and lookup-before-create or upsert logic to prevent duplicates.

Related Martini documentation

API Integration

Workflows

Security

Operations

Connect Spryker with your enterprise systems

Use Martini to build secure, observable Spryker integrations across commerce APIs, selected events, batch processes, and downstream business applications.

EXPLORE MARTINI
BOOK A DEMO