Ellipse Gradient for Header

Blue Yonder Integration Guide

Integrate Blue Yonder product APIs with enterprise applications through OAuth-secured REST workflows, synchronization, mappings, and product-specific event handling.

Blue Yonder integration options at a glance

Blue Yonder’s modern integration approach is centered on product-specific REST APIs exposed through its developer platform. Martini can authenticate with OAuth 2.0, consume Orders, Shipments, Inventory, Products or Items, Locations, and transportation resources, then map and orchestrate the results across enterprise systems. Selected Blue Yonder products may provide event notifications or outbound callbacks, while asynchronous, batch, import, export, or file capabilities must be confirmed for the relevant product and tenant. When events are unavailable, scheduled Martini workflows can poll APIs using incremental filters, pagination, checkpoints, and idempotent processing.

Integration pointSupported by Blue Yonder?Common use casesHow Martini supports it
REST APIsYesBlue Yonder provides product-specific REST APIs for orders, shipments, inventory, products or items, locations, and transportation resources. Exact resources, operations, and API versions vary by product and tenant.Martini can consume REST APIs from workflows, map request and response payloads, orchestrate calls, and expose normalized REST APIs to downstream applications.
AuthenticationYesThe modern Blue Yonder API platform generally uses OAuth 2.0 bearer tokens with client credentials, tenant-specific endpoints, and product- or API-specific scopes.Martini can store client credentials in secure environment configuration, obtain and reuse access tokens, and apply authenticated API requests.
Webhooks / outbound callbacksLimitedSelected Blue Yonder products and processes may provide event, notification, or callback capabilities. Coverage is not universal across Blue Yonder objects.Martini can expose a REST endpoint or run a webhook-consuming workflow where the relevant Blue Yonder product documents notifications or callbacks.
Bulk / asynchronous / batch APIsLimitedHigh-volume, asynchronous, or job-based operations may be available for particular products, including job submission and status polling.Martini can submit jobs, persist job identifiers, poll status endpoints, retrieve results, and apply timeout and retry rules when supported by the product API.
File / attachment APIsLimitedIndividual Blue Yonder products may expose import, export, or document-related resources, but no portfolio-wide file or attachment API was confirmed.Martini can process supported file exchanges or product-specific resources when documented, with validation, transformation, and controlled delivery.
Scheduled synchronizationYesScheduled polling is appropriate when event notifications are unavailable or incomplete, particularly for incremental Orders, Inventory, Shipments, Products, and Locations synchronization.Martini can trigger workflows on a schedule, maintain checkpoints or overlap windows, paginate through results, and perform idempotent writes.
Database / analytics accessNot confirmedDirect access to an underlying Blue Yonder database is not a general public integration method. Supported APIs or approved export and analytics interfaces should be used instead.Martini should use documented APIs or approved interfaces rather than assuming direct database connectivity to Blue Yonder.
GraphQL APIsNot confirmedNo broadly applicable official Blue Yonder GraphQL API was confirmed for this research.Martini can consume GraphQL generally, but Blue Yonder GraphQL availability must be verified for the specific product before use.

How Blue Yonder exposes data and business events

Blue Yonder REST APIs

REST is Blue Yonder’s primary modern integration approach, but resources and authorization are organized by product or solution rather than one universal API. The relevant tenant documentation determines available objects, operations, versions, and filters.

Martini implementation pattern

Martini implementation pattern: configure OAuth 2.0 credentials and the tenant-specific base URL, call the selected Blue Yonder API from a workflow, paginate and transform responses, apply business rules, and write results to target systems or expose a normalized Martini API.

Implementation sequence

Confirm the Blue Yonder product, tenant, API version, and scopes
Obtain and securely reuse an OAuth 2.0 access token
Call the relevant Blue Yonder REST resource
Follow pagination or continuation information
Map the response to the canonical and target schemas
Apply validation, business rules, and idempotency checks','Write the result and persist a?

Common Blue Yonder integration patterns

Pattern 1: Synchronize Blue Yonder orders and fulfillment

When to use this pattern

Use this pattern when ERP, commerce, or customer-service applications need current Blue Yonder order and fulfillment information. A scheduled workflow or a supported product-specific notification can initiate processing.

Integration direction
Blue Yonder
Martini
SAP S/4HANA
Example Mapping
Blue Yonder FieldCanonical FieldTarget Field
Order IDorderIdSales Order Number
Order StatusorderStatusDocument Status
Shipment IDshipmentIdFulfillment Reference
Location IDfulfillmentLocationIdPlant
Martini implementation pattern

Martini retrieves changed or pending Orders, optionally retrieves related Shipments, Inventory, and Locations, maps product-specific statuses into the target model, and writes idempotently using the Blue Yonder order identifier and source status version. Transient failures are retried and validation failures are routed to reconciliation.

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

Pattern 2: Publish inventory availability

When to use this pattern

Use this pattern when commerce, sales, or fulfillment applications need Blue Yonder availability by item and location. Event support may be used where documented; otherwise scheduled incremental polling provides the trigger.

Integration direction
Blue Yonder
Martini
Shopify
Example Mapping
Blue Yonder FieldCanonical FieldTarget Field
Item IDitemIdSKU
Location IDlocationIdLocation Code
On-hand QuantityonHandQuantityInventory Level
Available-to-promise QuantityavailableQuantityAvailable Inventory
Martini implementation pattern

Martini retrieves inventory quantities, excludes inactive locations, subtracts configured safety stock where required, converts units of measure, and publishes only valid changes. Checkpoints, overlap windows, throttling, and idempotent inventory writes reduce missed or duplicated updates.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • retry handling

Pattern 3: Process shipment and transportation status

When to use this pattern

Use this pattern when customer-facing or ERP applications need normalized shipment, load, carrier, route, or delivery updates from Blue Yonder transportation or fulfillment products.

Integration direction
Blue Yonder
Martini
Salesforce
Example Mapping
Blue Yonder FieldCanonical FieldTarget Field
Shipment IDshipmentIdShipment Reference
CarriercarrierCodeCarrier
Delivery StatusdeliveryStatusStatus
Load IDloadIdTransportation Reference
Martini implementation pattern

Martini retrieves Shipments or Loads, translates product-specific transportation statuses, and sends updates to the target system. It stores the last processed status or timestamp, tolerates late-arriving updates according to business rules, and prevents duplicate customer-facing messages.

Martini capabilities used
  • workflows
  • API consumption
  • data transformation
  • conditional routing
  • error handling

Pattern 4: Synchronize products and locations

When to use this pattern

Use this pattern for master-data alignment between Blue Yonder and an ERP, warehouse, commerce, or planning application. It is appropriate when the selected Blue Yonder APIs provide incremental retrieval or reliable modified-time filters.

Integration direction
Blue Yonder
Martini
NetSuite
Example Mapping
Blue Yonder FieldCanonical FieldTarget Field
Product / Item IDitemIdItem ID
Product DescriptiondescriptionDisplay Name
Location IDlocationIdLocation ID
Location TypelocationTypeLocation Category
Martini implementation pattern

Martini retrieves changed Products / Items and Locations, validates required identifiers, maps units and classifications, and compares source and target keys before writing. Unknown values and rejected records are retained in an exception path for correction and replay.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • validation
  • reconciliation

Applications commonly integrated with Blue Yonder

Blue Yonder is commonly positioned alongside ERP, commerce, customer-service, and supply-chain applications. These integrations depend on the specific Blue Yonder products, APIs, tenants, and interfaces deployed; Martini can coordinate the confirmed endpoints without requiring a dedicated Blue Yonder connector.

Application Scenario Direction Martini Pattern
SAP S/4HANA Synchronize orders, products, inventory, locations, shipments, and fulfillment data between Blue Yonder operations and the ERP. SAP S/4HANA → Martini → Blue Yonder Use OAuth-authenticated REST workflows to exchange master data and orders, apply product- and tenant-specific mappings, and return fulfillment or inventory results with idempotency and retry handling.
Salesforce Provide sales and customer-service users with order, shipment, availability, and fulfillment status. Blue Yonder → Martini → Salesforce Poll or receive supported Blue Yonder notifications, normalize order and shipment data, and expose or consume APIs to update Salesforce while routing rejected updates for review.
Microsoft Dynamics 365 Coordinate ERP, commerce, warehouse, inventory, and order data with Blue Yonder planning or execution applications. Microsoft Dynamics 365 → Martini → Blue Yonder Orchestrate bidirectional REST calls, maintain cross-system identifiers, transform statuses and units of measure, and use scheduled reconciliation for missed or late changes.
NetSuite Synchronize orders, inventory, item data, fulfillment, and shipment information for organizations using NetSuite as an ERP. NetSuite → Martini → Blue Yonder Use separate API workflows for master data and transactions, map Blue Yonder Products, Locations, Orders, and Shipments to NetSuite objects, and persist processing state for safe retries.
Shopify Publish inventory availability and fulfillment status to commerce operations while sending orders toward downstream fulfillment processes. Shopify → Martini → Blue Yonder Receive or retrieve commerce orders, call the applicable Blue Yonder order and inventory APIs, apply availability and safety-stock rules, and publish shipment updates back to Shopify.
ServiceNow Create incidents or operational tasks when supply-chain, API, or synchronization exceptions require service management. Blue Yonder → Martini → ServiceNow Classify workflow failures and business-rule rejections, create ServiceNow incidents with correlation identifiers, and optionally return resolution status to an operational workflow.
Oracle Fusion Cloud Applications Synchronize procurement, order, inventory, fulfillment, and financial data with Blue Yonder supply-chain applications. Oracle Fusion Cloud Applications → Martini → Blue Yonder Coordinate product-specific API calls, transform Oracle and Blue Yonder schemas, enforce business rules, and use checkpoints and reconciliation for bidirectional flows.
SPS Commerce Exchange purchase orders, advance ship notices, invoices, and shipment documents with trading partners while Blue Yonder remains an operational source. Blue Yonder → Martini → SPS Commerce Use the selected gateway’s supported interface alongside Blue Yonder APIs, transform document data, validate required fields, and place failed exchanges into an exception process.

How to build a Blue Yonder integration in Martini

Objective

Establish a product- and tenant-specific Blue Yonder connection using OAuth 2.0 and environment-specific configuration.

Instructions in Martini

  • Confirm the Blue Yonder product, tenant, API base URL, token endpoint, scopes, and roles.
  • Store the client ID and client secret in Martini secrets or secure environment configuration.
  • Configure token acquisition, reuse, expiration handling, and separate development, test, and production settings.

Objective

Select event-driven processing when the relevant Blue Yonder product documents callbacks; otherwise use scheduled polling.

Instructions in Martini

  • Confirm whether the required resource supports notifications or outbound callbacks.
  • Expose a Martini API endpoint or webhook-consuming workflow for supported notifications.
  • Configure a scheduler and incremental retrieval strategy when events are unavailable.

Objective

Retrieve the required Blue Yonder resource and related objects while respecting pagination, filters, and asynchronous processing behavior.

Instructions in Martini

  • Call the relevant REST resource with the required bearer token and product-specific parameters.
  • Follow page, cursor, continuation, or job-status mechanisms documented for the endpoint.
  • Persist checkpoints, overlap windows, or asynchronous job identifiers between executions.

Objective

Coordinate related Blue Yonder calls and downstream operations in a maintainable Martini workflow.

Instructions in Martini

  • Retrieve related Orders, Shipments, Inventory, Products / Items, Locations, or Loads only when required.
  • Branch authentication, validation, throttling, and business failures separately.
  • Use reusable workflow logic for common token, pagination, correlation, and retry behavior.

Objective

Convert product-specific Blue Yonder payloads into a canonical model and the target application schema.

Instructions in Martini

  • Map identifiers, statuses, quantities, units of measure, timestamps, and location values explicitly.
  • Preserve source identifiers and correlation values for reconciliation.
  • Handle unknown or newly introduced enumeration values according to defined business rules.

Objective

Validate records and apply enterprise rules before writing to a target system.

Instructions in Martini

  • Apply safety-stock, inactive-location, fulfillment, and eligibility rules where relevant.
  • Use stable business keys and source versions to make downstream operations idempotent.
  • Route invalid or rejected records to an exception or reconciliation process.

Common Blue Yonder data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrdersCustomer, fulfillment, replenishment, or transportation-related order exchange and status synchronization.SAP S/4HANA, NetSuite, Microsoft Dynamics 365, Shopify, SalesforceMartini retrieves or receives supported order changes, enriches them with inventory, shipment, or location data, maps identifiers and statuses, and applies idempotent writes.
ShipmentsShipment execution, carrier, route, delivery, and fulfillment-status synchronization.Salesforce, NetSuite, SAP S/4HANA, Shopify, SPS CommerceMartini normalizes shipment and delivery statuses, tracks source timestamps or versions, prevents duplicate updates, and routes rejected records for review.
InventoryAvailable, allocated, reserved, on-hand, or available-to-promise quantity distribution.Shopify, SAP S/4HANA, NetSuite, Microsoft Dynamics 365Martini polls or consumes supported updates, applies safety-stock and location rules, converts units where required, and publishes normalized availability.
Products / ItemsItem master, SKU, product, packaging, or merchandising information synchronization.SAP S/4HANA, NetSuite, Microsoft Dynamics 365, ShopifyMartini maps product identifiers, descriptions, units, and lifecycle values, then sends new or changed objects when incremental retrieval is available.
LocationsStores, warehouses, distribution centers, suppliers, and other network-location synchronization.SAP S/4HANA, Oracle Fusion Cloud Applications, NetSuite, Microsoft Dynamics 365Martini maps location identifiers, types, addresses, and operational status while maintaining cross-system keys and handling unknown enumerations.
Loads / Transportation plansTransportation planning and execution structures for applicable Blue Yonder transportation products.SAP S/4HANA, Salesforce, ServiceNow, SPS CommerceMartini consumes product-specific transportation resources, maps carrier and route information, tracks asynchronous jobs where applicable, and manages late or out-of-order updates.

Authentication and security considerations

OAuth 2.0 and tenant-specific access

Blue Yonder’s modern API platform generally uses OAuth 2.0 client credentials, bearer access tokens, tenant- or environment-specific base URLs, and product-specific scopes or permissions. The exact token endpoint and grant configuration must be confirmed for each product and tenant.

Credential protection

  • Store client IDs, client secrets, token configuration, and endpoint settings in Martini secrets or secure environment configuration.
  • Use separate credentials and endpoints for development, test, and production.
  • Cache tokens for their valid lifetime and rotate credentials according to enterprise policy.
  • Use least-privilege scopes and avoid logging tokens or sensitive order and customer data.

Operational considerations for Blue Yonder integrations

Product and tenant variation

Blue Yonder is a portfolio of applications rather than one uniform API surface. Confirm the deployed product, API version, tenant, regional deployment, available resources, scopes, and synchronous or asynchronous behavior before implementation.

Reliability controls

  • Implement pagination using the endpoint’s documented page, cursor, or continuation model.
  • Use modified-time filters, change tokens, event notifications, or bounded overlap windows for incremental synchronization.
  • Apply controlled concurrency, Retry-After handling, exponential backoff, and separate treatment for 429 and 5xx responses.
  • Use stable business keys and source versions to prevent duplicate writes and handle replay safely.
  • Validate schemas and status mappings, monitor version changes, and avoid relying on undocumented fields.
  • For asynchronous operations, persist the job identifier, poll status, retrieve results, and apply timeout handling.

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

More than point-to-point scripts

Martini provides a maintainable workflow layer between Blue Yonder and enterprise applications. Instead of embedding authentication, pagination, mappings, retries, and business rules in separate scripts, teams can centralize those concerns in reusable workflows and APIs.

Operational and architectural value

  • Consume Blue Yonder REST APIs and expose stable normalized APIs to downstream consumers.
  • Combine scheduled, event-driven, and API-led processing when Blue Yonder capabilities vary by product.
  • Map product-specific payloads into canonical and target schemas with explicit validation and business rules.
  • Apply consistent error handling, correlation, retry, logging, and reconciliation patterns.
  • Keep credentials and environment differences outside workflow logic through secure configuration.

Frequently asked questions

How can Blue Yonder be integrated with enterprise systems?

Blue Yonder can be integrated primarily through its product-specific REST APIs using OAuth 2.0 bearer-token authentication. Selected products may provide event notifications or callbacks, while scheduled API polling can support synchronization when event coverage is unavailable. Bulk, asynchronous, file, and import or export capabilities must be confirmed for the relevant product and tenant.

Can Martini integrate with Blue Yonder?

Yes. Martini can consume the applicable Blue Yonder REST APIs, authenticate with OAuth 2.0, orchestrate workflows, transform Blue Yonder payloads, and expose normalized APIs. Where documented for a particular product, Martini can also receive event notifications or callbacks.

Do I need a connector to integrate Blue Yonder with Martini?

No. A dedicated Blue Yonder connector is not required. Martini can integrate using Blue Yonder’s confirmed native mechanisms, primarily product-specific REST APIs and OAuth 2.0, plus documented callbacks, asynchronous operations, or file interfaces where available.

Is there any extra Lonti cost to integrate Blue Yonder with Martini?

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

Which Blue Yonder integration methods should an architect use?

REST APIs are the primary recommended method for modern Blue Yonder integrations. OAuth 2.0 should be configured for the specific product and tenant. Webhooks or callbacks, asynchronous jobs, bulk operations, and file interfaces should be used only when the applicable product documentation confirms them. A universal Blue Yonder GraphQL or current vendor-wide SOAP API was not confirmed.

Are Blue Yonder events or webhooks available?

Selected Blue Yonder products and processes may support event notifications or outbound callbacks, but coverage is not universal across objects or applications. Martini can receive supported notifications through an API endpoint or webhook-consuming workflow. If notifications are unavailable, scheduled polling with incremental filters is an alternative.

How does Martini synchronize Blue Yonder data?

Martini can use supported change filters, modified timestamps, status filters, event notifications, or scheduled polling to retrieve changes. Workflows paginate through results, map objects such as Orders, Inventory, Shipments, Products, and Locations, maintain checkpoints or overlap windows, and use stable identifiers to prevent duplicate downstream writes.

How does Martini handle Blue Yonder errors, retries, and duplicates?

Martini can classify authentication, authorization, validation, throttling, transient, and business-rule failures; retry transient 429 and 5xx responses with controlled backoff; and route rejected records for reconciliation. Stable identifiers such as Order ID, Shipment ID, Load ID, Item ID, Location ID, or an event ID can support idempotent processing.