.png)
Transporeon Integration Guide
Connect Transporeon transportation and logistics processes with enterprise systems through REST APIs, selected event notifications, scheduled workflows, and approved file exchanges.
Transporeon integration options at a glance
Transporeon’s primary integration mechanism for new development is its developer-facing REST API, with resources and write operations determined by the subscribed product and tenant. These APIs can support freight orders, tenders, shipments, carriers, locations, and visibility data. Selected transportation or visibility scenarios may provide webhook-style notifications or callbacks, while bulk and asynchronous processing may be available for specific APIs. Some products or customer deployments may also support structured file exchange. Authentication is application- and tenant-specific, commonly involving OAuth 2.0 and bearer tokens, although exact requirements must be confirmed. Martini can orchestrate authenticated calls, scheduled synchronization, event handling, mapping, validation, retries, and downstream updates.
| Integration point | Supported by Transporeon? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Primary mechanism for creating or updating freight orders, managing tenders, retrieving shipments and carriers, reading shipment events, and synchronizing locations or visibility data. Coverage depends on the subscribed product and tenant. | Martini can consume Transporeon REST APIs from workflows, apply authentication and pagination, transform payloads, enforce business rules, and expose controlled APIs for downstream consumers. |
| Webhooks and outbound callbacks | Limited | Selected transportation or visibility scenarios may provide event notifications for shipment milestones, delays, or other operational changes. Coverage, subscription configuration, and delivery semantics are product-specific. | Martini can expose an authenticated API endpoint, validate and deduplicate incoming notifications, retrieve the current resource when necessary, and invoke downstream workflows. |
| Bulk, asynchronous, or batch APIs | Limited | Selected APIs may support initial loads, high-volume freight-order synchronization, historical visibility extraction, or batch updates. Availability must be confirmed per endpoint. | Martini can orchestrate asynchronous jobs or implement scheduled pagination, checkpointing, throttling, and incremental filters when a bulk endpoint is unavailable. |
| File exchange | Limited | Structured logistics file exchange may be available in selected Transporeon products or customer deployments, particularly for legacy transportation processes. Formats and transfer mechanisms require confirmation. | Martini can process supported flat files and coordinate file-based workflows, while favoring documented REST APIs for new integrations where available. |
| Authentication | Limited | Transporeon integrations require application- and tenant-specific credentials. OAuth 2.0, client credentials, bearer tokens, scopes, API keys, certificates, or mutual TLS may apply depending on the API. | Martini can keep credentials in secure configuration, obtain and refresh tokens where configured, and separate development, test, and production authentication settings. |
| SOAP APIs | Not confirmed | A current, generally applicable SOAP interface was not confirmed. Any product-specific or legacy SOAP capability must be verified with Transporeon. | Martini can consume SOAP services when a supported Transporeon product explicitly provides one, but SOAP should not be assumed for a new integration. |
| Database or analytics access | Not confirmed | Direct access to Transporeon-managed production databases is not expected to be an appropriate integration mechanism. | Martini should use documented APIs, callbacks, or approved exports rather than relying on direct vendor database access. |
How Transporeon exposes data and business events
Transporeon REST APIs
Transporeon’s developer-facing REST APIs are the primary mechanism for current integrations. Resource coverage and write operations depend on the subscribed product, tenant, participant role, and enabled entitlements. Typical resources include freight orders, tenders, shipments, carriers, locations, and visibility data.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the applicable Transporeon API, retrieves or submits resources, handles pagination and response errors, maps the vendor model to a canonical model, and writes the result to enterprise systems.
Implementation sequence
Transporeon webhooks and callbacks
Transporeon supports event-driven capabilities for selected transportation and visibility scenarios, but coverage is not universal. Confirm event types, subscription scope, callback format, authentication, retries, ordering, and replay behavior for the selected product.
Martini implementation pattern
Martini implementation pattern: Martini exposes an authenticated API endpoint for supported notifications, validates the request, deduplicates the event, retrieves the current object when the notification is partial, and invokes a workflow for downstream synchronization.
Implementation sequence
Transporeon bulk and asynchronous processing
Bulk or asynchronous capabilities may be available for selected Transporeon resources or product APIs. These capabilities should be confirmed for each endpoint rather than assumed across the platform.
Martini implementation pattern
Martini implementation pattern: a workflow starts or polls an approved asynchronous operation, records job state and checkpoints, processes result pages or files, and routes failed items for replay without restarting the entire load.
Implementation sequence
Transporeon file exchange
Structured file exchange may be available in selected products or customer deployments, especially for legacy transportation processes. File formats, transport methods, schedules, and supported objects must be confirmed during implementation.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves an approved file, validates its format and control totals, transforms rows into the canonical model, invokes the relevant Transporeon or enterprise workflow, and archives processing results.
Implementation sequence
Common Transporeon integration patterns
Pattern 1: Synchronize freight orders from an ERP or TMS
When to use this pattern
Use this pattern when SAP S/4HANA, SAP Transportation Management, Oracle Transportation Management, or another upstream system creates transportation demand that must be submitted to Transporeon. It is suitable for scheduled or API-led processing with clear source references.
Integration direction
Example Mapping
| Transporeon Field | Canonical Field | Target Field |
|---|---|---|
| sourceOrderReference | freightOrder.reference | Transporeon freight-order reference |
| pickupLocation | stops[0].location | Transporeon pickup location |
| requestedDeliveryDate | stops[1].plannedDateTime | Transporeon delivery appointment |
| carrierCode | carrier.reference | Transporeon carrier identifier |
Martini implementation pattern
A Martini workflow retrieves new or changed source orders, validates mandatory fields, maps them to the applicable Transporeon freight-order model, and stores the returned Transporeon identifier. Stable source references and idempotency checks prevent duplicate creates; transient failures are retried while validation and business-state errors are routed to reconciliation.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- secure configuration
- error handling
Pattern 2: Orchestrate tenders and carrier responses
When to use this pattern
Use this pattern when Transporeon tender decisions must update an internal transportation system. It translates vendor-specific acceptance, rejection, expiration, carrier, and rate states into the organization’s canonical transportation model.
Integration direction
Example Mapping
| Transporeon Field | Canonical Field | Target Field |
|---|---|---|
| tenderStatus | tender.decision | SAP TM tender response |
| carrierId | assignedCarrier.reference | SAP TM carrier |
| agreedRate | freight.rate.amount | SAP TM agreed charge |
| expirationTime | tender.expiryDateTime | SAP TM response deadline |
Martini implementation pattern
Martini receives supported tender events or polls tender resources, correlates each tender with the internal freight order, translates statuses, and updates the target system. Conflicting responses, missing carrier mappings, or expired tenders are sent to an exception path rather than silently overwritten.
Martini capabilities used
- event-driven workflows
- API consumption
- data mapping
- conditional routing
- validation
- error handling
Pattern 3: Synchronize shipment visibility and milestones
When to use this pattern
Use this pattern when customer, service, or operational systems need Transporeon shipment status, estimated arrival changes, delays, delivery milestones, or proof-of-delivery information.
Integration direction
Example Mapping
| Transporeon Field | Canonical Field | Target Field |
|---|---|---|
| shipmentId | shipment.externalId | Salesforce shipment reference |
| eventType | milestone.type | Salesforce delivery milestone |
| estimatedArrival | milestone.estimatedDateTime | Salesforce estimated delivery |
| delayReason | exception.reason | Salesforce delivery exception |
Martini implementation pattern
Where callbacks are available, Martini exposes an authenticated endpoint and processes notifications through a workflow. Otherwise, a scheduler polls by change marker or timestamp. The workflow normalizes time zones and statuses, deduplicates events, applies delay rules, and updates Salesforce or other downstream consumers with retry and replay support.
Martini capabilities used
- API exposure
- webhook consumption
- scheduler triggers
- data mapping
- business rules
- idempotency
Pattern 4: Reconcile freight charges and invoices
When to use this pattern
Use this pattern when the subscribed Transporeon product exposes freight audit, settlement, charge, or invoice data that must be compared with ERP purchasing or payment information.
Integration direction
Example Mapping
| Transporeon Field | Canonical Field | Target Field |
|---|---|---|
| shipmentReference | transportationTransaction.shipmentId | SAP freight document reference |
| carrierReference | supplier.reference | SAP supplier |
| freightAmount | charge.amount | SAP freight charge |
| auditResult | reconciliation.status | SAP approval status |
Martini implementation pattern
Martini retrieves approved charge or invoice data, correlates it with shipment and carrier identifiers, normalizes currency and tax information, and applies tolerance rules. Approved results are posted to SAP, while discrepancies and missing references are routed to review with an auditable reconciliation record.
Martini capabilities used
- scheduled workflows
- API consumption
- data transformation
- business rules
- validation
- error handling
Applications commonly integrated with Transporeon
Transporeon can be integrated with transportation, enterprise resource planning, customer-service, workflow, and reporting applications. The exact direction and object coverage depend on the Transporeon product, tenant configuration, and capabilities enabled during onboarding.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Synchronize delivery, purchasing, freight-order, carrier, shipment-status, and transportation-cost data. | SAP S/4HANA → Martini → Transporeon | A Martini workflow retrieves approved transportation demand from SAP S/4HANA, validates locations and dates, maps the payload to the applicable Transporeon freight-order API, stores returned identifiers, and retries transient failures without duplicating orders. |
| SAP Transportation Management | Coordinate freight planning, tendering, carrier assignment, execution, and transportation status across systems. | SAP Transportation Management → Martini → Transporeon | Martini orchestrates bidirectional workflows that submit transportation requests, receive tender or shipment updates, normalize statuses, and return carrier and execution results to SAP Transportation Management. |
| Oracle Transportation Management | Exchange shipments, tenders, carrier responses, rates, and execution milestones. | Oracle Transportation Management → Martini → Transporeon | Scheduled or event-driven workflows correlate Oracle transportation identifiers with Transporeon objects, transform tender and milestone states, and route validation or business-state conflicts for reconciliation. |
| Blue Yonder Transportation Management | Synchronize transportation orders, carrier assignments, tender decisions, and delivery events. | Blue Yonder Transportation Management → Martini → Transporeon | Martini consumes or exposes the relevant APIs, applies explicit carrier and status mappings, and distributes accepted, rejected, delayed, or delivered states to Blue Yonder with idempotent updates. |
| Manhattan Active Transportation Management | Connect transportation planning and execution data with external carrier and logistics networks. | Manhattan Active Transportation Management → Martini → Transporeon | A Martini workflow validates shipment and location data, submits or updates Transporeon freight orders, and synchronizes resulting shipment events back to Manhattan using persistent checkpoints. |
| Salesforce | Provide customer-facing shipment milestones, delivery exceptions, and logistics status to account and service teams. | Transporeon → Martini → Salesforce | Martini receives supported Transporeon events or polls shipment status, converts logistics milestones into Salesforce updates, suppresses duplicates, and sends unresolved delivery exceptions to an operational workflow. |
| ServiceNow | Create incidents or tasks for transportation delays, failed deliveries, authentication failures, and integration exceptions. | Transporeon → Martini → ServiceNow | Martini classifies Transporeon events and workflow failures, enriches them with shipment and carrier context, and creates or updates ServiceNow records while preventing duplicate incidents. |
| Power BI | Consolidate shipment, carrier, tender, delivery, and transportation-performance metrics for reporting. | Transporeon → Martini → Power BI | Martini extracts paginated or event-derived data, normalizes identifiers and timestamps, writes it to an approved reporting store or ingestion endpoint, and records checkpoints for incremental refreshes. |
How to build a Transporeon integration in Martini
Objective
Establish the Transporeon application and tenant context before building business flows.
Instructions in Martini
- Confirm the Transporeon product, tenant, participant role, resources, and operations
- Obtain the required application credentials and confirm OAuth 2.0, API key, certificate, or mutual-TLS requirements
- Store secrets and environment-specific values in Martini secure configuration
- Configure separate development, test, and production credentials where available
Objective
Select an event-driven, scheduled, API-led, or approved file-based initiation method for each process.
Instructions in Martini
- Use a supported Transporeon callback or webhook-style event when coverage is confirmed
- Use a scheduler for incremental polling, reconciliation, or bulk extraction
- Use an exposed Martini API when an enterprise system needs to submit work
- Use approved file exchange only when the selected product and deployment support it
Objective
Read or receive Transporeon objects reliably, including pagination and partial event payloads.
Instructions in Martini
- Call the applicable REST resource or receive the supported notification
- Handle page or cursor navigation and persist a checkpoint
- Retrieve the full shipment, tender, or freight-order resource when an event contains only an identifier
- Use overlap windows and stable identifiers for late updates and replay
Objective
Coordinate vendor calls, validation, transformation, target writes, and exception paths in a maintainable Martini workflow.
Instructions in Martini
- Separate transport, mapping, business-rule, and target-system steps
- Use conditional routing for product-specific statuses and participant roles
- Persist correlation identifiers between Transporeon and enterprise systems
- Route permanent failures to reconciliation instead of repeatedly retrying them
Objective
Convert Transporeon logistics data into a canonical or target-specific model without losing operational meaning.
Instructions in Martini
- Map shipment, freight-order, tender, carrier, location, and event fields explicitly
- Normalize time zones, units, currencies, addresses, and status values
- Validate required references, dates, quantities, and tenant-specific identifiers
- Version mapping rules with the workflow and preserve relevant unknown fields where appropriate
Objective
Protect transportation processes from duplicates, conflicting states, and unauthorized updates.
Instructions in Martini
- Use source references and returned Transporeon identifiers to prevent duplicate creates
- Apply tolerance rules for rates, invoices, and freight charges
- Reject or quarantine updates for closed shipments or conflicting tender decisions
- Treat webhook-style delivery as at-least-once unless stronger guarantees are documented
Common Transporeon data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Shipments | Represent transportation movements for planning, execution, tracking, and status updates. | SAP Transportation Management, Oracle Transportation Management, Salesforce, Power BI | Martini retrieves or receives shipment changes, normalizes milestones and timestamps, correlates stable identifiers, and synchronizes downstream systems. |
| Freight orders | Represent orders or transport requests submitted for execution. | SAP S/4HANA, SAP Transportation Management, Oracle Transportation Management | Martini validates mandatory locations, dates, quantities, and references before creating or updating the applicable Transporeon resource with duplicate protection. |
| Tenders | Represent transportation offers sent to carriers or other transport providers. | SAP Transportation Management, Oracle Transportation Management, Blue Yonder Transportation Management | Martini maps tender states, carrier responses, rates, and expiration conditions, then applies business rules before updating the originating system. |
| Carriers | Represent transport providers participating in freight execution or tendering. | SAP S/4HANA, transportation management systems, reporting platforms | Martini synchronizes approved carrier identifiers and attributes, applies tenant-specific mappings, and preserves cross-system references. |
| Locations | Represent pickup, delivery, depot, warehouse, and other logistics locations. | SAP S/4HANA, transportation management systems, data platforms | Martini validates addresses, codes, time zones, and location identifiers before mapping them into freight orders and shipment flows. |
| Shipment events | Represent milestones such as accepted, dispatched, arrived, loaded, delivered, or delayed. | Salesforce, ServiceNow, SAP Transportation Management, Power BI | Martini processes callbacks or polling results, handles at-least-once delivery assumptions, orders or deduplicates events, and publishes normalized milestones. |
Authentication and security considerations
Tenant- and application-specific access
Transporeon credentials and permissions depend on the selected product, tenant, participant role, and API application. Confirm whether the API uses OAuth 2.0, client credentials, bearer tokens, API keys, certificates, mutual TLS, or another mechanism.
Secure credential handling
- Store client secrets, tokens, certificates, and tenant values in Martini secrets or secure environment configuration.
- Use least-privilege scopes and separate development, test, and production applications.
- Handle token expiration, rotation, and 401 or 403 responses explicitly.
- Limit logs to the information required for diagnosis and avoid exposing tokens or sensitive shipment data.
Operational considerations for Transporeon integrations
Reliability and synchronization
- Implement endpoint-specific pagination, checkpoints, overlap windows, and replay for incremental synchronization.
- Confirm Transporeon rate limits and apply throttling, exponential backoff, and controlled concurrency.
- Use stable identifiers and idempotency controls for freight orders, tenders, and event processing.
- Treat selected callback or webhook-style notifications as at-least-once until delivery guarantees are confirmed.
Data and lifecycle controls
- Normalize time zones, units, addresses, carrier identifiers, currencies, and transportation statuses.
- Separate authentication, validation, duplicate, rate-limit, transient, and business-state failures.
- Test representative shipment, tender, carrier, location, and event payloads before production rollout.
- Monitor API lifecycle notices and avoid dependence on undocumented fields or assumed product-wide object models.
Why use Martini instead of scripts or point-to-point integrations?
Reusable integration workflows
Martini provides a maintainable place to orchestrate Transporeon API calls, callbacks, scheduled polling, transformations, business rules, and downstream writes. The same workflow patterns can be reused across transportation systems and products without embedding integration logic in isolated scripts.
Operational control
Instead of point-to-point code, Martini centralizes secure configuration, validation, pagination, checkpoints, retries, idempotency, exception routing, and monitoring. Developers retain flexibility for custom logic while keeping mappings and process behavior visible and deployable as integration assets.
Frequently asked questions
Transporeon can be integrated primarily through its developer-facing REST APIs for freight orders, tenders, shipments, carriers, locations, and visibility data. Selected products or scenarios may also provide webhook-style callbacks, bulk or asynchronous processing, or approved file exchange. Authentication, object coverage, and write operations depend on the subscribed product and tenant.
Yes. Martini can consume the applicable Transporeon REST APIs, run scheduled synchronization workflows, expose an API endpoint for supported callbacks, and process approved file exchanges where available. Martini can handle authentication, pagination, mapping, validation, retries, idempotency, and downstream updates.
No. A dedicated Transporeon connector is not required. Martini can integrate using Transporeon’s confirmed native mechanisms, principally REST APIs and selected callback or webhook-style events, with file-based or other product-specific interfaces used only when documented and enabled.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Transporeon. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Transporeon, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are the primary mechanism to investigate for new integrations. Choose the API associated with the subscribed Transporeon product and process, such as freight orders, tendering, visibility, or freight audit. Confirm tenant entitlements, authentication, resource coverage, pagination, and write operations during onboarding.
Transporeon supports event-driven capabilities for selected transportation and visibility scenarios, but coverage is not universal. Confirm event types, subscription scope, callback format, authentication, retry and replay behavior, ordering, and whether the payload is complete. Martini can process supported callbacks or poll when event coverage is insufficient.
Martini can use scheduled or event-driven workflows, pagination, change timestamps or markers, overlap windows, and persistent checkpoints. Stable source references, returned Transporeon identifiers, mapping tables, and idempotency keys where supported help prevent duplicate freight orders, tenders, or shipment updates.
Yes. Martini can expose a controlled REST API that accepts enterprise requests, validates and transforms them, and invokes the applicable Transporeon workflow. This can isolate Transporeon-specific authentication and object mappings from consuming applications while centralizing authorization, error handling, and monitoring.
Related Martini documentation
Data Processing
Operations
Connect Transporeon with Martini
Use Martini to build reliable Transporeon integrations across transportation management, tendering, shipment visibility, carrier collaboration, and freight reconciliation workflows.