.png)
Stibo Systems Integration Guide
Integrate STEP product, master, classification, location, relationship, and digital asset data with enterprise applications through APIs, web services, events, files, and orchestrated workflows.
Stibo Systems integration options at a glance
Stibo Systems STEP integrations can use REST APIs for configured product, classification, asset, entity, location, and relationship operations. Existing implementations may also expose SOAP services, while configured event processes can support selected outbound notifications or HTTP callbacks. For high-volume exchange, STEP projects commonly use imports, exports, queues, staged processing, or batch jobs rather than assuming a generic bulk REST API. Asset integrations may exchange metadata, relationships, binaries, and renditions. Authentication varies by deployment and may include Basic, session, OAuth 2.0, token, or gateway-specific controls. Martini can consume these interfaces, transform data, expose controlled APIs, and orchestrate scheduled or event-driven synchronization.
| Integration point | Supported by Stibo Systems? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | STEP REST APIs can retrieve and update configured Products, Classifications, Assets, Entities, Locations, and relationships. Resources, methods, payloads, and paths depend on the STEP version and tenant model. | Martini can consume the STEP REST API from workflows, map responses, apply business rules, and expose a controlled Martini API for downstream consumers. |
| SOAP APIs | Limited | Existing STEP deployments may expose WSDL-based SOAP or web-service operations, particularly for legacy enterprise integrations. | Martini can consume SOAP services when the target environment exposes the required WSDL operations and authentication configuration. |
| Webhooks / outbound callbacks | Limited | Configured STEP event and outbound integration processes may issue selected notifications or HTTP callbacks, but universal webhook coverage for every object event is not confirmed. | Martini can expose a REST endpoint to receive confirmed callbacks, validate and deduplicate events, retrieve current STEP data, and route failures for retry. |
| Bulk / async / batch exchange | Limited | High-volume exchange may use STEP imports, exports, integration processes, event queues, staged processing, or batch jobs. A generic bulk REST API should be confirmed for the target environment. | Martini can orchestrate file, API, queue, or batch processing, transform records in stages, maintain checkpoints, and separate rejected records. |
| File / attachment APIs | Limited | STEP manages digital asset metadata, product-to-asset relationships, images, documents, videos, renditions, and potentially binary content. | Martini can retrieve permitted asset metadata and files, select renditions, transform metadata, and deliver staged or streamed content to target applications. |
| Authentication | Limited | Authentication varies by STEP deployment and exposed endpoint and may include Basic, session, OAuth 2.0, token, or gateway-specific methods. | Martini can store endpoint credentials and tokens in secure configuration and apply the authentication model required by the STEP administrator. |
| Database access | No | Direct access to the underlying STEP application database is not a confirmed public integration interface and is not recommended as a general integration method. | Martini should use supported STEP APIs, SOAP services, exports, integration processes, or separately provisioned reporting interfaces instead. |
How Stibo Systems exposes data and business events
Stibo Systems REST APIs
Configured STEP REST APIs provide the primary standards-based method for retrieving and updating supported Products, Classifications, Assets, Entities, Locations, and relationships. Available resources and operations vary by STEP version, tenant configuration, and data model.
Martini implementation pattern
Martini implementation pattern: a workflow calls the relevant STEP endpoint, handles pagination or continuation behavior, validates the response, maps the object into a canonical model, applies business rules, and writes to one or more target systems.
Implementation sequence
Stibo Systems SOAP services
STEP has established SOAP and web-service capabilities that may remain important for existing deployments or operations not available through the configured REST interface.
Martini implementation pattern
Martini implementation pattern: Martini consumes the exposed WSDL service, sends the required request, transforms the XML response, and applies the same validation, retry, and checkpoint controls used for REST-based synchronization.
Implementation sequence
STEP event and outbound integrations
STEP can support configured event-driven and outbound integration processes for selected object types and lifecycle events. This is not confirmed as a universal webhook for every change.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured REST API for confirmed HTTP callbacks, validates the event, checks idempotency, retrieves current STEP data where necessary, and acknowledges or routes the event based on processing outcome.
Implementation sequence
STEP imports, exports, and batch processes
STEP projects commonly use configured imports, exports, integration processes, queues, or staged jobs for high-volume product, classification, and master-data exchange. Exact formats and processing behavior are implementation-specific.
Martini implementation pattern
Martini implementation pattern: a scheduled or event-triggered workflow retrieves or receives the batch, parses XML, CSV, or another confirmed format, validates dependencies, processes records in controlled groups, and records successful and failed outcomes separately.
Implementation sequence
STEP asset exchange
STEP digital asset integrations may exchange asset metadata, product relationships, approval states, renditions, and permitted image or document binaries. Binary endpoints and limits depend on the deployment.
Martini implementation pattern
Martini implementation pattern: Martini retrieves approved asset metadata, selects the required rendition, handles large content through staged file processing where appropriate, and publishes the asset only after related product data is ready.
Implementation sequence
Common Stibo Systems integration patterns
Pattern 1: Synchronize products and classifications to commerce
When to use this pattern
Use this pattern when STEP is the source of enriched product information and taxonomy, while a commerce platform needs approved products, variants, categories, and localized attributes. It is suitable for scheduled incremental synchronization or an initial batch load.
Integration direction
Example Mapping
| Stibo Systems Field | Canonical Field | Target Field |
|---|---|---|
| STEP Product identifier | product.externalId | Shopify product handle or metafield |
| STEP product name | product.name | Shopify title |
| STEP classification assignment | product.category | Shopify product taxonomy |
| STEP variant SKU | variant.sku | Shopify variant SKU |
Martini implementation pattern
A scheduled Martini workflow retrieves changed or approved Products and Classifications through the available STEP API or export process, resolves dependencies, validates required attributes, and maps localized values and variants. It upserts Shopify objects using stable external keys, records checkpoints only after successful writes, and sends validation failures to an exception process.
Martini capabilities used
- scheduled workflows
- API consumption
- file and batch processing
- data mapping
- validation
- business rules
- error handling
Pattern 2: Distribute approved digital assets to content systems
When to use this pattern
Use this pattern when STEP manages product imagery and documents and downstream content or commerce platforms need approved renditions and relationships. Asset metadata and binary content should be treated as separate concerns when the implementation requires it.
Integration direction
Example Mapping
| Stibo Systems Field | Canonical Field | Target Field |
|---|---|---|
| STEP Asset identifier | asset.externalId | AEM asset ID or external reference |
| STEP asset rendition | asset.file | AEM binary content |
| STEP approval state | asset.publicationStatus | AEM activation status |
| STEP product-to-asset reference | asset.productReference | AEM product association |
Martini implementation pattern
Martini retrieves approved asset metadata and permitted content, selects a rendition according to target rules, and transfers large files through staged processing where appropriate. The workflow applies deterministic naming, prevents duplicate publication, updates relationships after product availability is confirmed, and retries transient transfer failures without duplicating assets.
Martini capabilities used
- workflows
- API consumption
- file handling
- data mapping
- business rules
- idempotency
- retry handling
Pattern 3: Synchronize entities and locations with ERP master data
When to use this pattern
Use this pattern when STEP governs suppliers, brands, organizations, or operational Locations and an ERP requires validated master data. The workflow can be bidirectional only where ownership and return updates are explicitly defined.
Integration direction
Example Mapping
| Stibo Systems Field | Canonical Field | Target Field |
|---|---|---|
| STEP Entity identifier | party.externalId | SAP business partner external ID |
| STEP Entity name | party.name | SAP business partner name |
| STEP Location code | location.code | SAP plant or location code |
| STEP approval state | masterData.status | SAP lifecycle or release status |
Martini implementation pattern
A Martini workflow selects approved or changed Entities and Locations, maps identifiers and operational attributes, validates mandatory ERP fields, and processes dependent objects in a controlled order. It performs idempotent writes, captures target identifiers, and distinguishes permanent validation failures from transient service errors.
Martini capabilities used
- incremental workflows
- API consumption
- data mapping
- validation
- business rules
- dependency management
- error handling
Pattern 4: Receive STEP change notifications and update downstream systems
When to use this pattern
Use this pattern when the specific STEP implementation can issue outbound HTTP callbacks or event notifications for the required object and lifecycle events. If callback coverage is incomplete, use scheduled incremental retrieval instead.
Integration direction
Example Mapping
| Stibo Systems Field | Canonical Field | Target Field |
|---|---|---|
| STEP event ID | event.id | Martini idempotency key |
| STEP object ID | sourceObject.id | Salesforce external ID |
| STEP object type | sourceObject.type | Salesforce routing rule |
| STEP changed attributes | sourceObject.changedFields | Salesforce update payload |
Martini implementation pattern
Martini exposes a secured REST API to receive the callback, validates the source and event identifier, and checks a persisted processing key before continuing. The workflow retrieves the current STEP object when necessary, maps it to Salesforce, acknowledges successful processing, and routes transient or permanent failures to retry and support queues.
Martini capabilities used
- REST API exposure
- webhook handling
- workflows
- API consumption
- data mapping
- idempotency
- error handling
Applications commonly integrated with Stibo Systems
STEP is commonly positioned as a product, master-data, and digital asset source for enterprise landscapes. The exact scope and direction depend on the customer’s data model, licensed modules, and system-of-record decisions.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Synchronize product, material, supplier, location, and commercial master data between STEP and SAP. | Stibo Systems → Martini → SAP S/4HANA | Martini can consume STEP REST APIs or exports, normalize identifiers and classifications, apply validation and ownership rules, and upsert SAP data. A workflow can record checkpoints and route rejected dependencies for correction. |
| Salesforce | Distribute selected product, account, brand, or related master data to support sales and service processes. | Stibo Systems → Martini → Salesforce | A Martini workflow retrieves approved and changed STEP objects, maps them to Salesforce payloads, applies field and ownership rules, and handles retries and rejected records separately. |
| NetSuite | Align product, item, vendor, and classification information between STEP and NetSuite ERP. | Stibo Systems → Martini → NetSuite | Martini can orchestrate incremental API or export-based synchronization, preserve STEP identifiers as external keys, transform classifications and units, and perform idempotent NetSuite upserts. |
| Shopify | Publish enriched products, variants, classifications, and approved digital assets to commerce stores. | Stibo Systems → Martini → Shopify | Martini retrieves approved STEP product and asset data, selects the required rendition, maps localized attributes and variants, and sends controlled updates to Shopify with exception handling. |
| Adobe Experience Manager | Distribute product information and approved digital assets to web and content experiences. | Stibo Systems → Martini → Adobe Experience Manager | A workflow can synchronize STEP metadata and asset relationships, stage larger files where appropriate, enforce approval-state rules, and publish only complete product-content packages. |
| Akeneo | Support product-information migration, comparison, or exchange in multi-PIM environments. | Stibo Systems → Martini → Akeneo | Martini can extract STEP products, classifications, and localized attributes, map them to Akeneo structures, validate required values, and produce an exception report for incompatible taxonomy or attributes. |
| ServiceNow | Synchronize selected products, assets, locations, or organizational data used in service and operational workflows. | Stibo Systems → Martini → ServiceNow | Martini can consume approved STEP objects, transform them into ServiceNow API payloads, apply target ownership and lifecycle rules, and expose a reusable workflow for incremental updates. |
| Jira | Create or update data-quality, enrichment, or product-governance work items from STEP validation and workflow exceptions. | Stibo Systems → Martini → Jira | A Martini workflow routes selected STEP validation failures or governance events to Jira, includes source identifiers and diagnostic details, and optionally processes status changes returned by Jira. |
How to build a Stibo Systems integration in Martini
Objective
Confirm the STEP deployment, exposed interface, network path, service account, and authentication method before implementing workflows.
Instructions in Martini
- Identify the STEP version, tenant configuration, data model, and required resources
- Confirm REST, SOAP, callback, export, or file endpoints with the Stibo Systems administrator
- Configure HTTPS, allowlisting or private connectivity requirements
- Store credentials, tokens, and endpoint configuration in Martini secrets or environment configuration
- Use a least-privilege STEP integration account
Objective
Select the trigger that matches the STEP integration mechanism and synchronization objective.
Instructions in Martini
- Use a scheduler for incremental polling or batch exchange
- Use a REST API endpoint when STEP can issue the required callback
- Use a start trigger for controlled API-led invocation
- Define the change marker, export job, event key, or checkpoint strategy
Objective
Obtain the current STEP objects and related data using the confirmed API, service, export, or asset process.
Instructions in Martini
- Retrieve Products, Classifications, Assets, Entities, Locations, or relationships as required
- Implement the STEP pagination or continuation model
- Separate asset metadata from binary content when necessary
- Resolve referenced objects and preserve source identifiers
- Avoid direct database access unless a separately approved reporting interface exists
Objective
Build the end-to-end Martini workflow that coordinates source retrieval, transformation, target writes, checkpoints, and exception routing.
Instructions in Martini
- Use workflow branches for object types, dependencies, or target systems
- Bound concurrency and batch sizes for the STEP environment
- Persist checkpoints only after target processing succeeds
- Use reusable services or APIs for shared retrieval and validation logic
- Separate initial loads from incremental synchronization
Objective
Convert configurable STEP data into stable canonical and target models while protecting data quality.
Instructions in Martini
- Map technical identifiers, attributes, classifications, localized values, and relationships
- Validate mandatory target fields and permitted enumerations
- Apply units, localization, lifecycle, and approval-state rules
- Use stable technical identifiers instead of display labels where available
- Route invalid records with source object IDs and diagnostic details
Objective
Update downstream applications, files, or APIs with idempotent operations and clear ownership rules.
Instructions in Martini
- Use upserts and deterministic external keys where supported
- Process referenced objects before dependent relationships
- Publish assets only after approval and product prerequisites are satisfied
- Capture target identifiers and response correlation details
- Avoid duplicate writes when a callback or request is replayed
Common Stibo Systems data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Products | Synchronize product records, SKUs, variants, attributes, localized values, and lifecycle status. | SAP S/4HANA, NetSuite, Shopify, Salesforce, Adobe Experience Manager, Akeneo | Martini retrieves changed or approved Products, resolves classifications and references, validates required attributes, and performs idempotent target upserts. |
| Classifications | Transfer product hierarchies, category structures, taxonomy nodes, and classification assignments. | Shopify, SAP S/4HANA, Akeneo, Adobe Experience Manager | Martini maps STEP taxonomy identifiers and hierarchy relationships to target categories, preserving technical identifiers and handling dependency order. |
| Assets | Exchange images, documents, videos, metadata, product relationships, approval states, and renditions. | Adobe Experience Manager, Shopify, Salesforce, content delivery platforms | Martini separates metadata from binary handling where required, selects approved renditions, stages large files, and prevents premature publication. |
| Entities | Synchronize suppliers, customers, organizations, brands, and other master-data objects. | SAP S/4HANA, NetSuite, Salesforce, ServiceNow | Martini filters by status or change marker, maps entity attributes and identifiers, applies ownership rules, and upserts the target object. |
| Locations | Exchange stores, facilities, markets, warehouses, and other geographic or operational locations. | SAP S/4HANA, NetSuite, ServiceNow, Salesforce | Martini validates location codes and relationships, transforms address and operational fields, and processes dependencies before downstream writes. |
| References and relationships | Represent links between Products, Assets, Classifications, suppliers, brands, and other STEP objects. | SAP S/4HANA, Shopify, Adobe Experience Manager, Akeneo | Martini resolves embedded, linked, or separately retrieved relationship data and applies ordered synchronization so referenced objects exist first. |
Authentication and security considerations
Deployment-specific authentication
STEP authentication depends on the exposed API or integration endpoint. Confirm whether the environment uses Basic Authentication, session credentials, OAuth 2.0, tokens, or an API gateway-specific method.
Least-privilege access
Use a dedicated integration account with only the permissions required for the Products, Classifications, Assets, Entities, Locations, workflows, and operations used by Martini.
Secure transport and secrets
- Use HTTPS/TLS for API and file-transfer traffic.
- Store credentials and tokens in Martini secrets or environment configuration.
- Do not log credentials, tokens, full sensitive payloads, or asset content.
- Confirm network allowlisting, VPN, or private connectivity requirements.
Operational considerations for Stibo Systems integrations
Throughput and pagination
Confirm STEP request limits, concurrency, collection pagination, and change-detection behavior. Use bounded batches, exports, queues, or staged processing for large product and asset volumes.
Idempotency and dependencies
Use stable STEP identifiers, revisions, event IDs, and deterministic target keys. Load Classifications, Entities, Locations, and Assets in an order that supports Product and relationship dependencies.
Assets and schemas
Do not assume asset metadata and binary content use the same endpoint. Treat configurable attributes, classifications, enumerations, workflow states, and relationships as versioned integration contracts.
Retries and testing
Retry transient failures with bounded backoff, but do not automatically retry permanent validation or authorization failures. Test initial loads, incremental changes, callback replay, approval-state changes, missing references, large files, and schema changes before production deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than API calls
Martini coordinates STEP API calls, SOAP services, callbacks, files, batch processes, target writes, checkpoints, and exception paths in maintainable workflows.
Separate mapping from business rules
Mappings, validation, lifecycle rules, dependency handling, and transformations can be managed as explicit integration logic rather than being scattered across scripts or point-to-point interfaces.
Support multiple operating modes
The same integration approach can support scheduled polling, event-driven callbacks, API-led access, initial migration, and high-volume staged processing when the STEP implementation requires different mechanisms.
Improve operational control
Martini provides reusable workflows, secure configuration, controlled API exposure, retry handling, checkpointing, and centralized troubleshooting patterns for enterprise synchronization.
Frequently asked questions
STEP can integrate through configured REST APIs, legacy or required SOAP services, outbound event and callback processes, imports and exports, batch jobs, queues, and asset exchange mechanisms. The exact resources, formats, events, and authentication controls depend on the STEP version, tenant configuration, and data model.
Yes. Martini can consume Stibo Systems STEP REST APIs, consume SOAP services where required, receive confirmed HTTP callbacks, process supported exports and files, and orchestrate scheduled synchronization workflows. Martini maps STEP objects into downstream application models and applies validation, business rules, and error handling.
No. A dedicated Stibo Systems connector is not required. Martini can integrate using STEP’s confirmed native REST APIs, SOAP services, configured callbacks, exports, files, batch processes, and deployment-specific authentication methods.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Stibo Systems. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Stibo Systems, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs should generally be assessed first for new integrations where the target STEP deployment provides the required resources. SOAP may be appropriate for existing services or operations without a REST equivalent. For high-volume exchange, confirm whether imports, exports, queues, staged processing, or batch jobs are the supported mechanism.
STEP supports configured event-driven and outbound integration patterns, but universal webhook coverage for every object change is not confirmed. Confirm the required object types and lifecycle events with the STEP administrator. Martini can receive confirmed callbacks, or use scheduled incremental synchronization when callbacks are unavailable.
Martini can retrieve changed or approved STEP objects using the deployment’s supported change mechanism, map them to canonical and target schemas, resolve classifications and relationships, validate required fields, and perform idempotent writes. Checkpoints should be committed only after downstream processing succeeds.
Martini can distinguish transient network, rate-limit, and server failures from permanent validation or authorization errors. Workflows can retry transient failures with bounded backoff, use stable STEP identifiers or event IDs for idempotency, and route rejected records to an exception or dead-letter process. Martini can also expose an API façade for downstream applications that need a controlled interface to STEP data.
Related Martini documentation
Connect Stibo Systems with Martini
Use Martini to build maintainable STEP integrations across APIs, web services, callbacks, files, batch processes, and enterprise applications.