.png)
Kinaxis Integration Guide
Kinaxis RapidResponse and Maestro integrate with enterprise systems through tenant-specific APIs, batch exchanges, files, and selected outbound event interfaces.
Kinaxis integration options at a glance
Kinaxis RapidResponse and Maestro can exchange supply-chain planning data through tenant-specific REST APIs, approved batch or asynchronous interfaces, and configured file imports or exports. Some deployments may also expose SOAP or XML services and selected outbound callbacks, although these capabilities must be confirmed for the product, release, and tenant. Authentication can involve enterprise SSO, service accounts, OAuth or token-based methods, depending on the environment. Martini can consume the confirmed Kinaxis interfaces, schedule incremental or batch workflows, transform Items, Locations, Orders, Demand, and Supply data, expose APIs for upstream systems, and manage validation, retries, checkpoints, and exception handling.
| Integration point | Supported by Kinaxis? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Limited | Tenant-specific APIs may be used to retrieve or submit Items, Locations, Orders, Demand, Supply, and other configured planning objects. Exact resources, schemas, permissions, and authentication must be confirmed for RapidResponse or Maestro. | Martini can consume Kinaxis REST endpoints from workflows, map request and response payloads, expose a Martini API for upstream callers, and apply validation, retries, and error handling. |
| SOAP APIs | Limited | Some deployments or legacy interfaces may provide XML-based web services for enterprise integration. A current universal SOAP surface should not be assumed. | If a Kinaxis SOAP service is provided, Martini can consume it, construct XML requests, parse responses, and transform the result into downstream models. |
| Webhooks / outbound callbacks | Limited | Selected deployments may provide outbound callbacks or event-style notifications, but coverage, payloads, delivery guarantees, and subscription configuration vary by tenant. | Martini can expose a REST API or webhook workflow to receive notifications, retrieve authoritative Kinaxis data, and apply deduplication and reconciliation logic. |
| Bulk / async / batch APIs | Limited | High-volume planning data may be exchanged through batch interfaces, asynchronous jobs, scheduled processes, or tenant-specific integration services. Job limits and partial-failure behavior require confirmation. | Martini can schedule batch workflows, paginate reads, split large payloads, track job status, persist checkpoints, and route failed batches for replay. |
| File imports and exports | Limited | Kinaxis implementations may use CSV, XML, JSON, or other agreed files for planning and master-data loads and extracts, transferred through SFTP, FTP, object storage, or managed file transfer. | Martini can orchestrate file-based workflows, parse and transform supported formats, validate rows, submit or retrieve files through the approved endpoint, and maintain processing status. |
| File and attachment APIs | Not confirmed | Planning-data file exchange may be available, but a general-purpose Kinaxis attachment or document API was not confirmed. | Martini can process files when the Kinaxis deployment exposes an approved transfer or import/export mechanism, while treating business-document attachments as a separate capability. |
| Database / analytics access | Not confirmed | Direct SQL access to Kinaxis-managed application storage should not be assumed. Approved exports, APIs, integration services, or customer-controlled replicas are the safer integration boundary. | Martini can connect to a customer-controlled database or warehouse when Kinaxis data has been replicated there, but does not infer direct access to Kinaxis internal storage. |
| Authentication | Limited | Authentication may use enterprise SSO, tenant-specific users, service accounts, OAuth or token-based methods, depending on the product and deployment. Basic Authentication and API keys should not be assumed. | Martini can store environment-specific credentials and tokens as secrets, apply the confirmed authentication configuration, and separate authorization failures from other workflow errors. |
How Kinaxis exposes data and business events
Kinaxis REST APIs
Kinaxis supports enterprise application integration through APIs, but the exact REST resources and payloads depend on the RapidResponse or Maestro product, release, tenant, and licensed configuration. Confirm the endpoint base URL, object permissions, schema, pagination, and authentication before implementation.
Martini implementation pattern
Martini implementation pattern: Martini consumes the confirmed Kinaxis REST API from a workflow or exposes a Martini REST API for upstream applications. The workflow retrieves or submits authoritative data, maps it to a canonical model, validates business keys and planning context, and writes the result to the target system with structured error handling.
Implementation sequence
Bulk, asynchronous, or batch integration
Kinaxis planning workloads can involve high-volume master data, transactions, and planning results. Deployments may use batch interfaces, asynchronous jobs, scheduled processes, or tenant-specific integration services, but the exact job model and limits require confirmation.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow submits or retrieves manageable batches, tracks job identifiers where available, polls status when required, splits large responses, and stores checkpoints. Partial failures are separated from successful records so a retry does not resubmit the entire batch.
Implementation sequence
Kinaxis file exchanges
Kinaxis deployments may use CSV, XML, JSON, or other agreed files for planning and master-data imports and exports. Transfer mechanisms can include SFTP, FTP, object storage, managed file transfer, or Kinaxis import/export jobs and must be confirmed for the environment.
Martini implementation pattern
Martini implementation pattern: Martini retrieves or receives the agreed file, validates its structure and business keys, transforms rows into the configured Kinaxis or downstream model, and records the source file and processing outcome. The workflow can route malformed files and rejected rows to an exception process.
Implementation sequence
Outbound callbacks and event notifications
Some Kinaxis environments may expose outbound callbacks or event-style integration for selected planning or execution events. A blanket webhook model for every Item, Order, Demand, Supply, or Location change was not confirmed.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured REST endpoint or webhook workflow to receive the notification, validates the source and correlation data, and retrieves the authoritative Kinaxis object when the event contains only an identifier. Scheduled reconciliation remains available for missed, duplicate, or unsupported events.
Implementation sequence
SOAP and XML services
Some Kinaxis deployments or legacy interfaces may expose SOAP or XML-based enterprise services. This mechanism is not universal and should be selected only when the customer's Kinaxis administrator confirms the service contract.
Martini implementation pattern
Martini implementation pattern: Martini consumes the confirmed SOAP service, constructs the XML request from mapped workflow data, parses the XML response, and routes SOAP faults or validation failures separately from transport failures.
Implementation sequence
Common Kinaxis integration patterns
Pattern 1: Send ERP master data and orders to Kinaxis
When to use this pattern
Use this pattern when Kinaxis requires regular Items, Locations, inventory, purchase orders, production orders, or customer orders from an execution system. Scheduled or batch processing is generally more predictable for large planning inputs than assuming real-time events.
Integration direction
Example Mapping
| Kinaxis Field | Canonical Field | Target Field |
|---|---|---|
| MaterialNumber | itemId | Items.itemIdentifier |
| Plant | locationId | Locations.locationIdentifier |
| RequestedDeliveryDate | requiredDate | Orders.requestedDate |
| OrderQuantity | quantity | Orders.quantity |
Martini implementation pattern
A scheduled Martini workflow retrieves changed ERP data, normalizes units, calendars, dates, and identifiers, validates referenced Items and Locations, and submits the configured Kinaxis API or batch payload. Stable order and line keys support idempotent updates; rejected rows and transport failures are persisted for targeted replay.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- data transformation
- validation
- business rules
- error handling
Pattern 2: Publish Kinaxis planning results to execution systems
When to use this pattern
Use this pattern when approved or published Supply, Demand, replenishment, shipment, or exception results must be distributed to ERP, warehouse, transportation, or analytics applications. The integration should preserve scenario, version, planning-cycle, and effective-date context.
Integration direction
Example Mapping
| Kinaxis Field | Canonical Field | Target Field |
|---|---|---|
| SupplyItem | itemId | Material |
| SupplyLocation | locationId | Plant |
| PlannedQuantity | plannedQuantity | PlannedOrder.Quantity |
| ScenarioVersion | planningContext | PlanningReference |
Martini implementation pattern
Martini retrieves Kinaxis results through an approved API, export job, or file, filters the required scenario or published version, transforms planning values to the execution system's units and dates, and writes idempotently. A watermark and reconciliation count prevent missed or duplicated outputs.
Martini capabilities used
- workflows
- API consumption
- file processing
- mapping and transformation
- business rules
- checkpoint management
- monitoring
Pattern 3: Normalize partner demand into Kinaxis
When to use this pattern
Use this pattern when customer, supplier, or partner systems provide demand, forecast, shipment, or inventory signals in different formats. Martini provides a controlled orchestration layer that can validate and normalize data before it enters Kinaxis planning.
Integration direction
Example Mapping
| Kinaxis Field | Canonical Field | Target Field |
|---|---|---|
| AccountExternalId | customerId | Demand.customerIdentifier |
| ProductCode | itemId | Demand.itemIdentifier |
| ForecastDate | demandDate | Demand.date |
| ForecastQuantity | quantity | Demand.quantity |
Martini implementation pattern
The workflow consumes partner APIs or files, maps source identifiers to canonical values, converts units and time zones, validates item and location references, and applies acceptance thresholds before submitting Demand or Orders to Kinaxis. Invalid records are routed to an exception process while accepted records receive correlation keys.
Martini capabilities used
- API consumption
- workflow orchestration
- file processing
- data mapping
- validation
- conditional routing
- exception handling
Pattern 4: Handle Kinaxis exceptions with hybrid events and reconciliation
When to use this pattern
Use this pattern when the Kinaxis tenant exposes selected outbound notifications but does not provide complete event coverage. Event notifications can accelerate urgent actions while scheduled incremental reads provide authoritative synchronization and recovery from missed events.
Integration direction
Example Mapping
| Kinaxis Field | Canonical Field | Target Field |
|---|---|---|
| ExceptionIdentifier | exceptionId | ServiceNow.correlationId |
| ExceptionSeverity | priority | Incident.priority |
| PlanningScenario | planningContext | Incident.description |
| AffectedLocation | locationId | Incident.configurationItem |
Martini implementation pattern
Martini receives the selected callback, validates and deduplicates it, retrieves current Kinaxis details when necessary, evaluates severity rules, and creates or updates a ServiceNow incident. A scheduled reconciliation workflow checks for missed or duplicate notifications and retries only transient failures.
Martini capabilities used
- API exposure
- webhook reception
- workflow orchestration
- data enrichment
- business rules
- idempotency
- retry handling
Applications commonly integrated with Kinaxis
Kinaxis is commonly positioned alongside ERP, customer, warehouse, procurement, analytics, and operational workflow products. The exact objects, direction, and interface depend on the licensed Kinaxis product and the surrounding application configuration.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Exchange materials, plants, inventory, purchase orders, production orders, and other execution data with Kinaxis planning processes. | SAP S/4HANA → Martini → Kinaxis | A scheduled Martini workflow retrieves changed SAP data, validates identifiers and quantities, maps it to the configured Kinaxis Items, Locations, Orders, or Supply model, and submits it through the approved Kinaxis API or batch interface. Rejections and transport failures are recorded separately for replay. |
| Oracle Fusion Cloud ERP | Synchronize items, suppliers, orders, inventory, and supply commitments with Kinaxis planning workflows. | Oracle Fusion Cloud ERP → Martini → Kinaxis | Martini consumes the Oracle API or approved export, normalizes dates, units, and identifiers, applies scenario and planning-context rules, and writes accepted data to Kinaxis. Checkpoints and stable business keys support incremental processing and idempotent retries. |
| Microsoft Dynamics 365 | Send sales, product, inventory, and supply data to Kinaxis and return approved planning or replenishment results to execution processes. | Microsoft Dynamics 365 → Martini → Kinaxis | A workflow reads changed Dynamics data, maps it to the tenant-specific Kinaxis schema, validates item and location references, and submits batches. A complementary workflow retrieves planning outputs and updates the relevant Dynamics resources with duplicate protection. |
| Salesforce | Provide customer demand, opportunity, or order signals to planning processes and make selected supply or availability information available to customer-facing workflows. | Salesforce → Martini → Kinaxis | Martini receives or retrieves Salesforce changes, converts CRM identifiers and dates into the configured Kinaxis Demand or Orders model, and routes invalid signals to an exception process. Approved Kinaxis outputs can be mapped back to Salesforce through a controlled API workflow. |
| ServiceNow | Create incidents or operational tasks for supply exceptions, failed integrations, or selected planning alerts. | Kinaxis → Martini → ServiceNow | Where Kinaxis provides an event or after a scheduled exception read, Martini evaluates severity and business rules, enriches the event with planning context, and creates or updates a ServiceNow incident. Correlation keys prevent duplicate incidents and failures enter a retry or exception workflow. |
| Snowflake | Consolidate Kinaxis planning, demand, supply, and exception data for analytics, reporting, and data science. | Kinaxis → Martini → Snowflake | Martini retrieves approved Kinaxis exports or API pages, adds scenario and extraction metadata, transforms the data into analytics-ready structures, and writes it to Snowflake. Watermarks and reconciliation counts help identify missed or duplicated planning results. |
| Manhattan Active | Coordinate supply, inventory, warehouse, and fulfillment data between Kinaxis planning and execution processes. | Manhattan Active → Martini → Kinaxis | Martini orchestrates API or file exchanges, normalizes item, location, quantity, and date conventions, and routes data according to planning scenario and fulfillment rules. Batch status, partial failures, and replay information are persisted for operational control. |
| Coupa | Exchange procurement, supplier, sourcing, and supply information with Kinaxis planning processes. | Coupa → Martini → Kinaxis | A Martini workflow consumes approved Coupa data, validates supplier and item references, maps procurement commitments into the configured Kinaxis Supply or Orders model, and records accepted and rejected rows. Kinaxis outputs can be routed back when the business process requires bidirectional synchronization. |
How to build a Kinaxis integration in Martini
Objective
Confirm whether the target is RapidResponse, Maestro, or another Kinaxis service, then obtain the tenant-specific endpoint, API definition, permissions, and authentication requirements.
Instructions in Martini
- Confirm the Kinaxis product, release, tenant, and licensed integration features
- Obtain the approved REST, SOAP, batch, file, or callback contract
- Store credentials, tokens, and endpoint configuration in Martini environment secrets
- Assign least-privilege access to required Items, Locations, Orders, Demand, Supply, or Resources
Objective
Select a trigger that matches the Kinaxis capability and consistency requirement rather than assuming that every object change can generate an event.
Instructions in Martini
- Use a scheduler for incremental or batch synchronization
- Use a Martini API or webhook workflow when Kinaxis provides an approved callback
- Use a file arrival or approved export process when file exchange is the configured boundary
- Define the watermark, scenario, version, or planning cycle for each run
Objective
Acquire the current Kinaxis data or notification and preserve enough context to resume processing after an interruption.
Instructions in Martini
- Retrieve API pages or approved export files
- Receive callback notifications through a secured Martini endpoint when enabled
- Track pagination, batch, job, file, and checkpoint information
- Retrieve authoritative Kinaxis data when an event contains only an identifier
Objective
Coordinate calls, transformations, validations, target writes, and exception paths as a maintainable Martini workflow.
Instructions in Martini
- Separate transport, authentication, validation, and business-rule failures
- Control concurrency and backoff according to tenant limits
- Split large payloads into manageable pages or batches
- Persist correlation identifiers and processing outcomes
Objective
Convert the Kinaxis planning model into a canonical or target-system model while preserving scenario and operational context.
Instructions in Martini
- Map actual Kinaxis objects such as Items, Locations, Orders, Demand, Supply, and Resources
- Normalize units, calendars, time zones, dates, and identifiers
- Preserve scenario, version, planning horizon, and effective-date values
- Validate required fields and reference relationships before submission
Objective
Use workflow conditions to decide whether data is accepted, routed, enriched, retried, or sent to an exception process.
Instructions in Martini
- Apply create, update, and idempotency rules using stable business keys
- Route invalid records and business-rule rejections separately from transient failures
- Check whether data belongs to the intended scenario or published planning cycle
- Prevent duplicate downstream incidents, orders, or planning submissions
Common Kinaxis data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Items | Products, materials, or planning items managed through the supply-chain model. | SAP S/4HANA, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Manhattan Active, Snowflake | Martini validates item identifiers, units, status, and effective dates, then maps Items through REST, batch, or approved file interfaces. |
| Locations | Plants, warehouses, suppliers, distribution centers, and other supply-chain nodes. | SAP S/4HANA, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Manhattan Active | Martini normalizes location codes, time zones, calendars, and relationships before submitting or distributing location data. |
| Orders | Customer, purchase, transfer, or other orders used in planning and execution. | SAP S/4HANA, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Coupa | Martini uses stable order and line identifiers, validates quantities and dates, applies create/update rules, and protects retries against duplicates. |
| Demand | Forecast, customer demand, independent demand, and other demand signals. | Salesforce, SAP S/4HANA, Oracle Fusion Cloud ERP, Snowflake | Martini converts units, dates, item codes, locations, and planning context, then routes valid demand to Kinaxis or downstream analytics. |
| Supply | Planned or actual production, purchase, transfer, or replenishment supply. | SAP S/4HANA, Oracle Fusion Cloud ERP, Manhattan Active, Snowflake | Martini retrieves or submits Supply data with scenario, version, quantity, and effective-date context and records partial failures separately. |
| Resources | Production capacity, labor, equipment, and other constrained planning resources. | SAP S/4HANA, manufacturing systems, Snowflake | Martini maps resource identifiers, capacity values, calendars, and planning horizons while preserving the source scenario or version context. |
Authentication and security considerations
Tenant-specific authentication
Kinaxis authentication and authorization depend on the product, release, tenant, and deployment. Confirm whether the environment uses enterprise SSO, a service account, OAuth or token-based authentication, or another documented method. Basic Authentication and API keys should not be assumed.
Least-privilege access
Limit integration identities to the Kinaxis workspaces, scenarios, objects, and operations required by the workflow. Review access to Items, Locations, Orders, Demand, Supply, Resources, and planning results separately where the tenant supports that distinction.
Secrets and sensitive data
- Store credentials, tokens, and endpoint settings in Martini environment secrets.
- Do not embed credentials in mappings or API definitions.
- Avoid logging full payloads that contain customer, supplier, pricing, or commercially sensitive planning information.
- Protect callback endpoints with the authentication and authorization controls confirmed for the Kinaxis deployment.
Operational considerations for Kinaxis integrations
Volume and rate control
Confirm pagination, maximum page size, request limits, concurrent job limits, batch limits, and maintenance windows. Use controlled concurrency, backoff, and checkpoints for large planning datasets.
Idempotency and reconciliation
Use stable business identifiers such as order and line numbers, item identifiers, location identifiers, or Kinaxis record keys. Persist watermarks, scenario and version context, accepted counts, rejected counts, and source references so interrupted runs can resume safely.
Planning context and data quality
Preserve scenario, planning cycle, version, horizon, and effective-date values. Normalize units, calendars, time zones, and week conventions before comparing or submitting data.
Testing and change management
Kinaxis schemas, workspaces, fields, and business rules can be deployment-specific. Test with representative payloads and verify schema changes, partial failures, asynchronous job behavior, and authorization before production rollout.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond point-to-point calls
Martini coordinates Kinaxis APIs, files, callbacks, databases, and downstream applications in workflows rather than embedding logic in isolated scripts or one-off mappings.
Reusable integration logic
Shared validation, transformation, authentication, error handling, and checkpoint patterns can be reused across ERP, CRM, warehouse, procurement, analytics, and operational workflows.
Reliable operations
- Apply controlled retries, idempotency, pagination, and partial-failure handling.
- Expose APIs for upstream systems while consuming Kinaxis interfaces from workflows.
- Separate transport failures from validation and business-rule exceptions.
- Monitor workflow outcomes and preserve enough context for reconciliation and replay.
Frequently asked questions
Kinaxis RapidResponse and Maestro can be integrated through the APIs, batch or asynchronous interfaces, file exchanges, and selected SOAP, XML, or outbound callback mechanisms enabled in the customer's product and tenant. The exact endpoint, object model, authentication, and event coverage must be confirmed with the Kinaxis administrator.
Yes. Martini can integrate with Kinaxis through the tenant's confirmed REST APIs, approved SOAP or XML services, batch interfaces, files, and selected outbound callbacks. Martini can orchestrate workflows, map Kinaxis planning objects, expose APIs, and handle validation, retries, checkpoints, and exceptions.
No. A dedicated Kinaxis connector is not required. Martini can use the native Kinaxis integration mechanisms enabled for the environment, such as REST APIs, approved SOAP or XML services, batch exchanges, files, or outbound callbacks.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Kinaxis. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Kinaxis, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
Use the current interface documented for the customer's RapidResponse or Maestro product and tenant. REST APIs are the primary candidate where enabled; batch, asynchronous, and file mechanisms may be better for large planning datasets. SOAP or XML should be used only when a current service contract is specifically provided.
Some Kinaxis deployments may expose outbound callbacks or event-style interfaces for selected events, but a universal webhook model for all object changes was not confirmed. Verify event types, payload completeness, delivery guarantees, retries, signing, and replay behavior; use scheduled incremental synchronization for unsupported events.
Martini can run scheduled, event-driven, API-led, or batch workflows that retrieve or receive Kinaxis data, map actual objects such as Items, Orders, Demand, and Supply to canonical or target models, normalize units and dates, and apply scenario and version rules. Watermarks, stable identifiers, and checkpoints support incremental and repeatable synchronization.
Martini can classify transport, authentication, validation, business-rule, conflict, timeout, and partial-batch failures. Transient failures can be retried with controlled backoff, while invalid records are routed to exceptions. Stable item, location, order, line, or vendor-provided identifiers support idempotent processing and duplicate prevention.
Related Martini documentation
APIs
Plan your Kinaxis integration
Use Martini to connect Kinaxis with enterprise applications through governed APIs, workflows, mappings, batch processes, files, and confirmed event interfaces.