.png)
Manhattan Active Integration Guide
Manhattan Active integrates with enterprise systems primarily through tenant-specific REST APIs, OAuth 2.0 authentication, and selected event or callback mechanisms.
Manhattan Active integration options at a glance
Manhattan Active integrations are primarily API-led, using application-specific REST APIs documented through the Manhattan Associates developer portal. Access commonly uses OAuth 2.0 bearer tokens with tenant-specific clients, scopes, and permissions. Some Manhattan Active applications may provide event notifications, outbound callbacks, batch operations, asynchronous jobs, or import processes, but coverage must be confirmed for the relevant product and tenant. File-based mechanisms may also be implementation-specific. Martini can consume the REST APIs, securely manage credentials, schedule incremental synchronization, receive selected HTTP notifications, transform JSON payloads, expose controlled APIs, and route failures for retry or reconciliation.
| Integration point | Supported by Manhattan Active? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Primary integration method for orders, shipments, inventory, items, facilities, purchase orders, and other application-specific resources. Available resources and operations vary by Manhattan Active product and tenant. | Martini can consume Manhattan Active REST APIs from workflows, map request and response payloads, apply validation and business rules, and expose its own REST APIs for downstream consumers. |
| Webhooks / outbound callbacks | Limited | Selected Manhattan Active product contexts may provide event notifications or HTTP callbacks for business changes such as orders, shipments, or inventory. Coverage, delivery behavior, and event authority must be verified. | Martini can expose an API or webhook-oriented workflow to receive confirmed notifications, authenticate requests, retrieve the current resource, and process duplicates or retries. |
| Bulk / async / batch APIs | Limited | Individual applications may provide batch operations, asynchronous jobs, import processes, or integration-specific endpoints. Platform-wide availability is not confirmed. | Martini can orchestrate job submission and polling when documented, schedule batch workflows, transform results, and persist checkpoints for restartable processing. |
| File / attachment APIs | Limited | File-based enterprise integration is common in Manhattan deployments, but Active-specific file, attachment, SFTP, CSV, or XML coverage is product- and implementation-specific. | Where an approved file endpoint is available, Martini can orchestrate file movement and processing, parse supported formats, map records, and route rejected files for review. |
| Authentication | Yes | Manhattan Active API access commonly uses OAuth 2.0 bearer tokens with client registration, secrets, tenant or environment settings, scopes, and permissions. | Martini can store client values and environment-specific endpoints as secrets or configuration and attach bearer tokens to API requests without hard-coding credentials. |
| GraphQL APIs | Not confirmed | No platform-wide Manhattan Active GraphQL capability was verified. A GraphQL endpoint should not be assumed for a product or tenant. | Martini can consume GraphQL generally, but a Manhattan Active GraphQL integration should only be designed if the applicable tenant documentation confirms an endpoint. |
| SOAP APIs | Not confirmed | SOAP may exist in legacy or adjacent Manhattan products, but it was not confirmed as a recommended Manhattan Active interface. | Martini can consume SOAP services generally, but Manhattan Active SOAP use requires explicit confirmation for the relevant product and deployment. |
| Database / analytics access | Not confirmed | Direct tenant database access was not confirmed. Integrations should use documented APIs or approved export and analytics mechanisms. | Martini can connect to approved downstream databases or reporting stores, but it should not bypass Manhattan Active APIs through assumed direct tenant database access. |
How Manhattan Active exposes data and business events
Manhattan Active REST APIs
REST APIs are the primary confirmed integration mechanism for Manhattan Active. The developer portal documents application-specific resources and operations, but the available catalog, API versions, permissions, and payloads depend on the licensed product and tenant.
Martini implementation pattern
Martini implementation pattern: a workflow obtains an OAuth 2.0 bearer token, calls the required Manhattan Active endpoint, validates the response, maps the application payload to a canonical or target model, and records correlation and synchronization state.
Implementation sequence
Manhattan Active event notifications
Some Manhattan Active product contexts support event-driven integration through notifications, callbacks, queues, or another event mechanism. Broad coverage for every object and lifecycle event was not confirmed.
Martini implementation pattern
Martini implementation pattern: expose a controlled REST endpoint or webhook-oriented workflow for confirmed HTTP notifications, authenticate the request, use the event as a trigger or hint, and retrieve the current Manhattan Active resource when the notification does not contain sufficient data.
Implementation sequence
Manhattan Active batch and asynchronous operations
Selected Manhattan Active applications may expose batch operations, asynchronous jobs, import processes, or integration-specific endpoints. These capabilities must be verified for the target application before implementation.
Martini implementation pattern
Martini implementation pattern: submit a documented job or batch request, store its identifier, poll or receive completion status, process the resulting data, and make the workflow restartable from a checkpoint.
Implementation sequence
Manhattan Active file-based integration
File-based enterprise integration is present in some Manhattan deployments, but Active-specific file, attachment, SFTP, CSV, or XML mechanisms are not uniform across the platform and require implementation confirmation.
Martini implementation pattern
Martini implementation pattern: use only an approved Manhattan Active file endpoint or transfer process, validate file structure and provenance, transform accepted contents, and isolate rejected files for reconciliation.
Implementation sequence
Common Manhattan Active integration patterns
Pattern 1: Orchestrate orders between Salesforce and Manhattan Active
When to use this pattern
Use this pattern when Salesforce owns customer-facing transactions while Manhattan Active manages order orchestration and fulfillment. The flow should support both initial submission and return of status, shipment, and cancellation information.
Integration direction
Example Mapping
| Manhattan Active Field | Canonical Field | Target Field |
|---|---|---|
| externalOrderNumber | order.reference | Order external reference |
| orderLines[].sku | order.lines[].itemId | Order line item |
| shippingAddress | fulfillment.destination | Order ship-to address |
| fulfillmentStatus | order.fulfillmentStatus | Salesforce fulfillment status |
Martini implementation pattern
Martini receives or retrieves Salesforce orders, validates required customer, address, item, and quantity data, and submits the mapped payload to Manhattan Active through REST APIs. A return workflow maps Manhattan Active status and shipment information back to Salesforce. Stable external references, reconciliation queries, and retry classification protect against duplicate creates and lost responses.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- scheduled synchronization
Pattern 2: Connect Shopify fulfillment and inventory with Manhattan Active
When to use this pattern
Use this pattern when Shopify remains the commerce storefront and Manhattan Active provides fulfillment and inventory orchestration. Bidirectional processing keeps storefront availability and customer order status aligned with operational execution.
Integration direction
Example Mapping
| Manhattan Active Field | Canonical Field | Target Field |
|---|---|---|
| id | order.reference | Manhattan Active order reference |
| line_items[].sku | order.lines[].itemId | Order line item |
| inventory.available | inventory.availableQuantity | Shopify inventory quantity |
| shipment.tracking_number | shipment.trackingReference | Shopify fulfillment tracking |
Martini implementation pattern
Martini transforms Shopify orders, addresses, delivery options, and lines into the Manhattan Active model, then publishes inventory and fulfillment changes back to Shopify. Workflows enforce item and facility validation, use source identifiers for idempotency, and schedule reconciliation when event or callback coverage is unavailable.
Martini capabilities used
- workflows
- REST API consumption
- data mapping
- transformation
- idempotency
- retry handling
Pattern 3: Synchronize inventory and purchase orders with SAP S/4HANA
When to use this pattern
Use this pattern when SAP S/4HANA manages procurement and enterprise product information while Manhattan Active manages warehouse and fulfillment execution. It is suited to scheduled or incremental synchronization of items, facilities, purchase orders, receipts, and inventory.
Integration direction
Example Mapping
| Manhattan Active Field | Canonical Field | Target Field |
|---|---|---|
| materialNumber | item.identifier | Manhattan Active item ID |
| plant | facility.identifier | Manhattan Active facility ID |
| purchaseOrderNumber | purchaseOrder.reference | Purchase order reference |
| availableQuantity | inventory.availableQuantity | SAP inventory quantity |
Martini implementation pattern
Scheduled Martini workflows retrieve changes from each side using confirmed filters or watermarks, transform units and facility identifiers, and apply business rules for permitted status transitions. The workflow persists checkpoints, bounds concurrency, retries transient failures, and routes authorization or validation failures for reconciliation.
Martini capabilities used
- scheduler triggers
- workflow orchestration
- data mapping
- business rules
- checkpoint management
- error handling
Pattern 4: Publish shipment visibility and exceptions
When to use this pattern
Use this pattern when shipment or load information from Manhattan Active must be shared with Salesforce, ServiceNow, a carrier platform, or a customer-facing service, while delivery exceptions need to be returned or escalated.
Integration direction
Example Mapping
| Manhattan Active Field | Canonical Field | Target Field |
|---|---|---|
| shipment.reference | shipment.identifier | ServiceNow correlation key |
| shipment.status | shipment.lifecycleStatus | ServiceNow incident context |
| deliveryException | shipment.exceptionReason | ServiceNow incident description |
| resolutionStatus | exception.resolutionStatus | Manhattan Active exception workflow |
Martini implementation pattern
Martini retrieves shipment changes through REST APIs or processes confirmed notifications, normalizes status and time-zone fields, and creates or updates downstream exception records. Correlation keys prevent duplicate incidents, while workflow branches distinguish temporary transport errors from business exceptions and support controlled status return.
Martini capabilities used
- event-driven workflows
- API consumption
- data normalization
- business rules
- correlation
- error handling
Applications commonly integrated with Manhattan Active
Manhattan Active commonly participates in enterprise order, fulfillment, warehouse, inventory, transportation, and supply chain architectures. The applications below represent practical integration scenarios rather than claims of native, out-of-the-box connectivity; exact objects, endpoints, and event coverage depend on the Manhattan Active application and tenant.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer-facing orders, fulfillment status, shipments, cancellations, and service context between Salesforce and Manhattan Active. | Salesforce → Martini → Manhattan Active | Martini receives or retrieves Salesforce data, validates and maps orders into Manhattan Active REST payloads, then returns normalized fulfillment and shipment updates to Salesforce through scheduled reconciliation or confirmed callbacks. |
| Shopify | Send commerce orders and product information to Manhattan Active while returning inventory, fulfillment, shipment, and cancellation updates to the storefront. | Shopify → Martini → Manhattan Active | A Martini workflow consumes Shopify data, maps addresses, delivery options, items, and quantities to Manhattan Active, and publishes normalized inventory and fulfillment responses back to Shopify with idempotency controls. |
| SAP S/4HANA | Coordinate products, suppliers, purchase orders, inventory, receipts, and operational status between enterprise resource planning and Manhattan Active execution processes. | SAP S/4HANA → Martini → Manhattan Active | Martini orchestrates bidirectional REST and approved enterprise interfaces, applies product- and facility-specific mappings, and separates retryable API failures from validation and authorization errors. |
| Oracle NetSuite | Synchronize items, orders, inventory, purchase orders, fulfillment information, and operational status between NetSuite and Manhattan Active. | Oracle NetSuite → Martini → Manhattan Active | Scheduled or event-assisted Martini workflows retrieve changes, transform financial and fulfillment models, write to the destination system, and persist watermarks and source identifiers for safe replay. |
| ServiceNow | Create incidents or requests from warehouse, fulfillment, shipment, and integration exceptions and return resolution status to operational teams. | Manhattan Active → Martini → ServiceNow | Martini classifies Manhattan Active errors or business exceptions, creates ServiceNow work items through its API, correlates them with source identifiers, and updates status when remediation is recorded. |
| Jira | Create engineering or operational work items from integration failures, warehouse exceptions, or change requests associated with Manhattan Active processes. | Manhattan Active → Martini → Jira | A Martini error-handling branch enriches selected failures with workflow and object identifiers, submits Jira issues, and prevents duplicate tickets through correlation keys. |
| Microsoft Power BI | Publish order, inventory, shipment, and fulfillment data for reporting and operational dashboards without relying on direct Manhattan Active database access. | Manhattan Active → Martini → Microsoft Power BI | Martini retrieves approved API data on a schedule, normalizes product-specific status and timestamp fields, and delivers curated datasets through an approved reporting interface or downstream data service. |
| MuleSoft | Route and govern data exchanged between Manhattan Active and broader enterprise application landscapes where MuleSoft is already part of the integration architecture. | Manhattan Active → Martini → MuleSoft | Martini can consume or expose controlled REST endpoints, apply canonical mappings and business rules, and exchange normalized payloads with MuleSoft while preserving correlation and retry state. |
How to build a Manhattan Active integration in Martini
Objective
Establish tenant-specific access to Manhattan Active and keep environment differences out of workflow logic.
Instructions in Martini
- Confirm the application, tenant, environment, API base URL, token endpoint, scopes, and permissions.
- Register or obtain the OAuth 2.0 client credentials required by the Manhattan Active environment.
- Store credentials, tokens, and environment values in Martini configuration or secrets rather than hard-coding them.
- Test access against the specific resources and operations required by the integration.
Objective
Select a trigger that matches the confirmed Manhattan Active capability and the required freshness of the data.
Instructions in Martini
- Use a scheduled workflow for inventory, orders, shipments, or reference data when incremental API retrieval is available.
- Use a Martini API or webhook-oriented workflow when the Manhattan Active application provides confirmed HTTP notifications.
- Use a documented batch or asynchronous process only after verifying its availability and completion behavior.
Objective
Acquire current Manhattan Active data reliably and preserve enough state to support incremental processing and replay.
Instructions in Martini
- Call the relevant REST resource with tenant-appropriate filters, pagination, and page sizes.
- Persist a watermark, cursor, continuation token, or other stable checkpoint when the API supports it.
- For notifications, retrieve the current resource when the event payload is incomplete or only acts as a change hint.
- Record source identifiers, event identifiers, and correlation values.
Objective
Coordinate API calls, enrichment, routing, and target writes as a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, transformation, business rules, and target delivery into clear workflow stages.
- Use reusable services or workflow components for common token handling, pagination, status normalization, and correlation logic.
- Apply bounded concurrency and ordering rules where inventory, order, or shipment dependencies require them.
Objective
Convert application-specific Manhattan Active payloads into canonical enterprise models and target schemas.
Instructions in Martini
- Map actual Manhattan Active objects such as Orders, Shipments, Inventory, Items, Facilities, and Purchase Orders.
- Normalize identifiers, quantities, status values, dates, and time-zone offsets explicitly.
- Validate required fields and isolate product-specific mappings so API version or application differences remain manageable.
Objective
Protect operational processes from invalid, duplicate, or out-of-sequence data.
Instructions in Martini
- Use stable Manhattan Active IDs, external references, transaction IDs, or event IDs for idempotency.
- Distinguish authentication, authorization, validation, conflict, throttling, timeout, and platform errors.
- Apply facility, item, order, shipment, and status transition rules before writing to downstream systems.
Common Manhattan Active data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Orders | Customer, sales, fulfillment, or distribution orders managed by Order Management and related applications. | Salesforce, Shopify, SAP S/4HANA, Oracle NetSuite | Martini retrieves or receives order data, validates identifiers and lines, maps addresses and fulfillment attributes, and uses stable references to prevent duplicate writes. |
| Shipments | Outbound or inbound transportation and fulfillment movements, including shipment status and tracking context where exposed by the application. | Salesforce, Shopify, carrier platforms, ServiceNow | Martini normalizes shipment milestones and status values, correlates them with orders or loads, and routes exceptions for retry, reconciliation, or operational review. |
| Inventory | Available, allocated, reserved, or on-hand stock associated with products and facilities. | Shopify, SAP S/4HANA, Oracle NetSuite, Microsoft Power BI | Scheduled workflows retrieve incremental inventory data when supported, apply facility and item mappings, persist watermarks, and publish normalized quantities to approved targets. |
| Items | Products or SKUs used across order, inventory, warehouse, and fulfillment processes. | SAP S/4HANA, Oracle NetSuite, Shopify | Martini maps item identifiers, descriptions, units, and status fields while isolating product-specific schema differences in reusable workflow logic. |
| Facilities | Warehouses, distribution centers, stores, and other operational locations used by fulfillment and inventory processes. | SAP S/4HANA, Oracle NetSuite, Microsoft Power BI | Martini synchronizes facility identifiers and organizational attributes, validates references before writes, and preserves tenant-specific mappings in environment configuration. |
| Purchase Orders | Inbound procurement documents and associated lines, receipts, or fulfillment activities. | SAP S/4HANA, Oracle NetSuite, inventory and reporting platforms | Martini transforms purchase order headers and lines, applies supplier and facility business rules, and handles partial receipts or validation failures through controlled reconciliation. |
Authentication and security considerations
OAuth 2.0 and tenant access
Manhattan Active API access commonly uses OAuth 2.0 bearer tokens with registered clients, associated secrets, tenant or environment settings, scopes, and permissions. Exact token endpoints, audiences, and permissions depend on the product and deployment.
Protect credentials and endpoints
- Store client credentials, token settings, base URLs, and tenant identifiers in Martini environment configuration or secrets.
- Use least-privilege permissions for orders, inventory, shipments, facilities, items, and purchase orders.
- Apply authentication and authorization to Martini APIs that receive callbacks or expose normalized Manhattan Active data.
- Verify callback signatures or equivalent sender authentication whenever the Manhattan Active implementation provides them.
Operational considerations for Manhattan Active integrations
Tenant-specific behavior
API resources, versions, permissions, status values, pagination, filters, and event coverage may vary by Manhattan Active application and tenant. Confirm these characteristics in the applicable API catalog before implementation.
Reliability and synchronization
- Use pagination, updated-since filters, stable watermarks, and bounded concurrency for large Orders, Inventory, and Shipments collections.
- Respect tenant-specific rate limits and Retry-After responses, and use exponential backoff for transient failures.
- Use Manhattan Active identifiers, external references, and event IDs to prevent duplicate writes and safely replay uncertain requests.
- Distinguish authentication, authorization, validation, conflict, throttling, timeout, and platform errors.
- Preserve time-zone offsets and map operational status fields explicitly rather than assuming one universal lifecycle.
- Test mappings against the target product and API version, and isolate product-specific schemas so changes can be managed without rewriting every workflow.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini provides a maintainable workflow layer between Manhattan Active and enterprise applications. It can coordinate retrieval, transformation, validation, business rules, target writes, callbacks, and reconciliation without embedding the entire integration in a single script or point-to-point connection.
Reusable integration assets
- Use reusable workflows and services for token handling, pagination, status normalization, idempotency, and common error paths.
- Expose controlled APIs for downstream systems instead of distributing direct Manhattan Active credentials and resource knowledge.
- Manage tenant-specific configuration and secrets separately from deployable integration logic.
- Apply consistent retry, logging, checkpoint, and monitoring patterns across orders, inventory, shipments, and reference data.
- Extend mappings and business rules with custom logic when product-specific payloads require more than declarative transformation.
Frequently asked questions
Manhattan Active is primarily integrated through application-specific REST APIs documented in the Manhattan Associates developer portal. Access commonly uses OAuth 2.0 bearer tokens. Selected applications may also provide event notifications, callbacks, batch operations, asynchronous jobs, or file-based mechanisms, but those capabilities must be confirmed for the relevant product and tenant.
Yes. Martini can consume Manhattan Active REST APIs, use OAuth 2.0 credentials stored as configuration or secrets, schedule synchronization workflows, receive confirmed HTTP notifications, transform JSON payloads, expose controlled REST APIs, and handle validation, retries, and reconciliation.
No. A dedicated Manhattan Active connector is not required. Martini can integrate using Manhattan Active’s documented REST APIs and any tenant-specific callbacks, event mechanisms, batch endpoints, files, or other supported interfaces that are explicitly enabled.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Manhattan Active. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Manhattan Associates, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
REST APIs are the primary confirmed method for new Manhattan Active integrations. OAuth 2.0 bearer-token authentication is commonly used. Event notifications, callbacks, batch or asynchronous APIs, and file processes should be selected only after confirming their availability and behavior for the specific Manhattan Active application and tenant.
They may be available for selected product contexts, but broad coverage across all objects and events was not confirmed. Architects should verify event types, delivery guarantees, authentication, signatures, retries, ordering, duplicate behavior, and replay support. Martini can expose an API or webhook-oriented workflow when HTTP notification delivery is confirmed.
Martini can run scheduled or event-assisted workflows, use API pagination and incremental filters where supported, and persist watermarks or checkpoints. Stable Manhattan Active identifiers, external references, source transaction IDs, and event IDs can support idempotency. The applicable API’s pagination, filtering, and retry behavior must be confirmed.
Yes. Martini can expose a controlled REST API, retrieve or transform Manhattan Active data in a workflow, and return a normalized response to calling applications. Martini can also apply authentication, authorization, validation, business rules, logging, and error handling around the façade.
Related Martini documentation
API access
Workflows
Data handling
Plan your Manhattan Active integration
Use Martini to connect Manhattan Active APIs and confirmed event mechanisms with enterprise applications through secure, observable, and maintainable workflows.