.png)
FourKites Integration Guide
Connect FourKites transportation visibility data with enterprise systems through customer-specific APIs, event notifications, EDI, files, and partner interfaces.
FourKites integration options at a glance
FourKites integrations exchange transportation visibility data through customer- and partner-specific REST APIs, selected webhook-style callbacks, EDI, carrier or telematics feeds, and file-based interfaces. REST APIs are the primary mechanism for creating or updating shipments and loads, retrieving tracking events and estimated arrivals, and synchronizing stops, appointments, and carriers. Callback availability, batch operations, document exchange, authentication, pagination, and rate limits must be confirmed for the tenant and enabled products. Martini can securely consume the applicable FourKites endpoints, receive callbacks through exposed APIs, orchestrate EDI or file exchanges, normalize logistics data, and deliver it to downstream systems.
| Integration point | Supported by FourKites? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Create or update shipments and loads, submit stops and appointments, retrieve tracking events and ETAs, and synchronize carriers or facilities. Endpoint coverage depends on the tenant and enabled FourKites products. | Martini can consume the applicable FourKites REST endpoints, transform payloads, apply validation and business rules, and route responses to downstream workflows. |
| Webhooks / outbound callbacks | Limited | Selected customer or partner implementations may provide event-oriented notifications for shipment, tracking, delay, or delivery changes. Supported events and delivery guarantees must be confirmed. | Martini can expose a secured API endpoint, validate and persist callback payloads, trigger workflows, and apply deduplication and reconciliation logic. |
| EDI and logistics feeds | Limited | Enterprise implementations may exchange shipment and status transactions through EDI, carrier feeds, telematics, or transportation-system interfaces. | Martini can orchestrate supported partner interfaces and transform EDI or feed data when the required protocol and transaction contract are available. |
| File and attachment exchange | Limited | Proof-of-delivery documents, bills of lading, appointment documents, and other logistics files may be exchanged through an implementation-specific API, file transfer, EDI, or document system. | Martini can process approved file exchanges and map document metadata or logistics data into downstream workflows; a universal FourKites attachment API should not be assumed. |
| Bulk / asynchronous processing | Not confirmed | Batch shipment updates, bulk event retrieval, asynchronous exports, or job-status endpoints may be included in a customer-specific contract. | Martini can orchestrate batch workflows when FourKites provides the relevant contract, including checkpointing, partial-failure handling, and bounded retries. |
| Authentication | Limited | FourKites integrations require customer-authorized credentials, but public material does not fully specify credential formats, headers, scopes, token lifecycle, or callback authentication. | Martini stores credentials in environment-specific secrets and uses them from workflows; the FourKites security contract must define the exact authentication implementation. |
| Database / analytics access | Not confirmed | Direct access to FourKites-managed production databases was not identified. Data should be exchanged through APIs, exports, reports, or approved partner interfaces. | Martini can write retrieved FourKites data to supported databases or warehouses, but it should not assume direct FourKites JDBC or SQL access. |
How FourKites exposes data and business events
FourKites REST APIs
FourKites supports customer and partner API integrations for transportation visibility data. REST availability, endpoint coverage, request models, authentication, pagination, and rate limits depend on the tenant, products, and implementation contract.
Martini implementation pattern
Martini implementation pattern: Martini workflows call the applicable FourKites endpoints using environment-specific secrets, validate responses, map shipment and tracking data to canonical models, and write results to target systems or persistence stores.
Implementation sequence
FourKites outbound callbacks
Selected FourKites customer or partner implementations may provide webhook-style notifications for selected shipment or tracking events. Event coverage, authentication, retries, ordering, and duplicate behavior must be confirmed.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured API endpoint, validates and quickly persists each callback, then invokes asynchronous workflow processing for normalization, enrichment, routing, and reconciliation.
Implementation sequence
FourKites EDI and logistics feeds
FourKites participates in enterprise logistics integrations that may use EDI, carrier feeds, telematics, flat files, or transportation-system interfaces. Transaction sets, transport protocols, and connection ownership are implementation-specific.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves the approved feed, parses the agreed format, maps logistics data to canonical shipment and event models, applies validation, and sends acknowledgements or downstream updates where required.
Implementation sequence
FourKites scheduled reconciliation
Scheduled retrieval is useful when callback coverage is incomplete or when the integration must detect missed events. FourKites pagination, filtering, modification timestamps, and event identifiers must be confirmed.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow retrieves overlapping time windows or pages of FourKites data, maintains a persisted watermark, deduplicates results, and compares source state with downstream state.
Implementation sequence
Common FourKites integration patterns
Pattern 1: Submit transportation loads to FourKites
When to use this pattern
Use this pattern when a transportation management or ERP system creates or changes loads that must become visible in FourKites. It validates required carrier, pickup, delivery, and appointment information before submission and preserves the returned FourKites identifier for future updates.
Integration direction
Example Mapping
| FourKites Field | Canonical Field | Target Field |
|---|---|---|
| source load identifier | load.externalId | FourKites load identifier reference |
| carrier code | carrier.code | FourKites carrier identifier |
| pickup and delivery stops | stops[] | FourKites stops |
| appointment time | appointments[].scheduledAt | FourKites appointment time |
Martini implementation pattern
A Martini workflow receives a source event or scheduled extract, maps the transportation model, validates required references, calls the customer-specific FourKites API, and persists the response cross-reference. Transient failures are retried with bounded backoff, while validation failures are isolated for correction.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- secrets management
- error handling
Pattern 2: Distribute FourKites tracking events
When to use this pattern
Use this pattern when customer-service, operations, or case-management systems need shipment status, ETA changes, delay notifications, arrival, departure, or delivery milestones. Callback availability is implementation-specific, so polling reconciliation can complement event processing.
Integration direction
Example Mapping
| FourKites Field | Canonical Field | Target Field |
|---|---|---|
| shipment or load identifier | shipment.reference | Salesforce shipment reference |
| tracking event type | event.type | Salesforce milestone or case status |
| estimated arrival | eta | Salesforce estimated delivery |
| delay information | exception.details | Salesforce case description |
Martini implementation pattern
Martini receives selected callbacks or polls FourKites, validates and persists the event, then normalizes status and time values before enriching and updating Salesforce. Event identifiers and deterministic keys prevent duplicate cases, while scheduled reconciliation identifies gaps.
Martini capabilities used
- API exposure
- workflows
- data mapping
- business rules
- deduplication
- scheduled synchronization
Pattern 3: Load FourKites visibility data into Snowflake
When to use this pattern
Use this pattern for historical logistics reporting, carrier performance analysis, ETA analysis, and operational dashboards. It is appropriate when the customer needs a durable analytical copy rather than direct database access to FourKites.
Integration direction
Example Mapping
| FourKites Field | Canonical Field | Target Field |
|---|---|---|
| shipment identifier | shipment.id | SHIPMENT_ID |
| load status | load.status | LOAD_STATUS |
| tracking event timestamp | event.occurredAtUtc | EVENT_OCCURRED_AT_UTC |
| carrier identifier | carrier.code | CARRIER_CODE |
Martini implementation pattern
A scheduled Martini workflow retrieves changed shipments, loads, stops, and tracking events using the confirmed pagination and filtering model. It applies an overlap window, normalizes timestamps and status values, writes accepted rows to the warehouse interface, and advances the watermark only after successful processing.
Martini capabilities used
- scheduler triggers
- API consumption
- pagination orchestration
- data transformation
- database or warehouse integration
- error handling
Pattern 4: Route delivery exceptions to ServiceNow
When to use this pattern
Use this pattern when delayed deliveries, missed appointments, or other FourKites exceptions require operational ownership and case tracking. The workflow enriches the logistics event with business context and avoids opening multiple cases for the same exception.
Integration direction
Example Mapping
| FourKites Field | Canonical Field | Target Field |
|---|---|---|
| tracking event identifier | exception.eventId | ServiceNow correlation ID |
| shipment or load identifier | shipment.reference | ServiceNow configuration item or case reference |
| delay status | exception.type | ServiceNow incident category |
| facility and appointment details | stop.context | ServiceNow incident description |
Martini implementation pattern
Martini validates a FourKites callback or reconciliation result, applies severity and duplicate rules, enriches the event with order or account data where available, and calls ServiceNow. Authentication failures, validation errors, and transient service errors follow separate exception paths.
Martini capabilities used
- API exposure
- API consumption
- workflow orchestration
- data enrichment
- business rules
- retry and error handling
Applications commonly integrated with FourKites
FourKites can be integrated with transportation, enterprise, customer-service, and analytics applications when those systems need shipment execution, tracking, ETA, or exception data. The exact interface should be confirmed for each tenant and product configuration.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Exchange orders, deliveries, shipment references, and logistics execution data with FourKites visibility records. | SAP S/4HANA → Martini → FourKites | Martini consumes or receives SAP logistics data, maps deliveries and shipment references to the FourKites contract, validates carrier and stop data, and records FourKites identifiers for subsequent updates. |
| Oracle Transportation Management | Synchronize loads, stops, carriers, appointments, tracking events, ETAs, and transportation exceptions. | Oracle Transportation Management → Martini → FourKites | A Martini workflow is triggered by transportation changes or a schedule, transforms the Oracle model into FourKites shipment or load payloads, and reconciles returned status and event data. |
| Manhattan Active Transportation Management | Synchronize transportation plans and execution events with FourKites visibility data. | Manhattan Active Transportation Management → Martini → FourKites | Martini orchestrates API or partner-interface calls, applies explicit mappings for stops and appointments, and routes FourKites event updates back to the transportation workflow. |
| Salesforce | Surface shipment status, ETA changes, delivery milestones, and exceptions in customer and case-management workflows. | FourKites → Martini → Salesforce | Martini receives selected FourKites callbacks or polls for changes, normalizes event types, enriches them with shipment or account data, and updates Salesforce using duplicate-safe business rules. |
| ServiceNow | Create or update operational incidents and exception cases for delays, missed appointments, and delivery issues. | FourKites → Martini → ServiceNow | A Martini workflow validates FourKites events, applies severity and deduplication rules, maps exceptions to ServiceNow records, and retries transient API failures. |
| NetSuite | Synchronize fulfillment, order, and shipment information with transportation visibility data. | NetSuite → Martini → FourKites | Martini retrieves relevant fulfillment data, maps source identifiers and appointment details to FourKites fields, persists cross-references, and processes acknowledgement or error responses. |
| Snowflake | Centralize historical shipments, tracking events, ETAs, and carrier-performance data for analytics. | FourKites → Martini → Snowflake | A scheduled Martini workflow retrieves incrementally changed FourKites objects, handles pagination and watermarks, normalizes timestamps and statuses, and writes curated datasets to Snowflake through an approved interface. |
| Power BI | Provide operational dashboards and performance reporting from curated logistics datasets. | FourKites → Martini → Power BI | Martini prepares normalized FourKites data for a warehouse or approved reporting interface, preserving event and source identifiers so Power BI can consume consistent shipment and carrier metrics. |
How to build a FourKites integration in Martini
Objective
Establish the FourKites tenant-specific integration contract and configure credentials without embedding secrets in workflow definitions.
Instructions in Martini
- Confirm the FourKites base URL, API version, enabled products, operations, and authentication requirements.
- Store environment-specific FourKites credentials in Martini secrets.
- Configure target-system credentials and any approved EDI, file, or partner transport.
Objective
Select an event-driven, callback, scheduled, or feed-based trigger that matches the confirmed FourKites interface.
Instructions in Martini
- Use a callback endpoint when the tenant exposes the required event types.
- Use a scheduler for polling, batch synchronization, reconciliation, or completeness checks.
- Use a feed or file trigger when the implementation contract requires EDI or flat files.
Objective
Obtain shipment, load, stop, appointment, carrier, or tracking-event data while respecting the tenant-specific API contract.
Instructions in Martini
- Call the confirmed FourKites endpoint or receive the approved callback payload.
- Handle the documented pagination, filtering, time-window, and identifier model.
- Persist the source payload or event reference needed for audit and replay.
Objective
Coordinate validation, enrichment, transformation, target updates, and checkpoint management in a maintainable Martini workflow.
Instructions in Martini
- Separate intake and acknowledgement from long-running downstream processing where callbacks are used.
- Route records by object type, status, business priority, or target system.
- Persist watermarks and source-to-FourKites cross-references.
Objective
Convert customer-specific FourKites fields into canonical and downstream models without losing source identifiers or audit context.
Instructions in Martini
- Map shipments, loads, stops, appointments, carriers, and tracking events explicitly.
- Normalize timestamps, time zones, status values, and identifiers.
- Retain original source values where reconciliation or auditability requires them.
Objective
Apply validation, idempotency, event-ordering, and exception rules before writing data to target systems.
Instructions in Martini
- Reject or isolate messages missing required shipment, load, carrier, or stop references.
- Use event identifiers or deterministic keys to prevent duplicate processing.
- Compare event timestamps and business status before overwriting current state.
Common FourKites data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Shipment | Represents a transportation movement being monitored and is used for status, ETA, milestone, and execution synchronization. | Transportation management, ERP, CRM, customer portals, data warehouses | Martini maps tenant-specific shipment fields, persists the FourKites identifier, normalizes statuses and timestamps, and applies idempotent update rules. |
| Load | Represents the transportation load associated with one or more shipment movements. | Transportation management, ERP, warehouse, analytics systems | Martini correlates source and FourKites load identifiers, validates carrier and stop references, and handles create, update, and reconciliation flows. |
| Stop | Represents a pickup, delivery, or intermediate location within a transportation movement. | Transportation management, warehouse, appointment, customer-service systems | Martini maps location, sequence, arrival, departure, and appointment details while preserving local and normalized time values. |
| Appointment | Represents a scheduled pickup or delivery appointment. | Transportation management, warehouse, ERP, exception-management systems | Martini validates appointment times and facility references, transforms time zones, and routes changes to target scheduling or exception workflows. |
| Carrier | Identifies the transportation provider responsible for executing a shipment or load. | Transportation management, ERP, procurement, analytics systems | Martini maintains cross-system carrier mappings, validates identifiers, and enriches shipment or load messages with approved carrier data. |
| Tracking Event | Captures location, milestone, status, delay, arrival, departure, or delivery information associated with a shipment or load. | CRM, ServiceNow, customer portals, data warehouses, notification systems | Martini consumes callbacks or polling results, deduplicates events, evaluates ordering and status rules, and distributes normalized events. |
Authentication and security considerations
Tenant-specific credentials
FourKites authentication details are not fully specified in public material. Confirm the credential format, headers, token lifecycle, scopes, tenant restrictions, and callback authentication with the FourKites implementation or API team.
Secret management
Store FourKites credentials in environment-specific Martini secrets rather than workflow definitions. Apply separate credentials and endpoint configuration for development, testing, and production.
Callback protection
When callbacks are enabled, confirm signature or credential validation, replay behavior, source restrictions, and delivery guarantees. Martini can expose secured APIs and validate requests before triggering processing workflows.
Operational considerations for FourKites integrations
Pagination and incremental retrieval
Confirm whether FourKites uses pages, offsets, cursors, time-window filters, modification timestamps, or event identifiers. Persist a watermark and use an overlap window where late-arriving updates are possible.
Retries and rate limits
Obtain FourKites rate and concurrency limits. Use bounded exponential backoff for transient failures, treat authentication and validation errors separately, and respect HTTP 429 responses if returned.
Idempotency and ordering
Tracking events may be duplicated or arrive out of order. Use FourKites identifiers or deterministic keys, compare event timestamps and business status, and persist cross-system shipment and load references.
Schema and time handling
Status values, event types, optional fields, and identifiers may vary by product or contract. Maintain explicit mapping tables and normalize timestamps while retaining source time-zone context where needed.
Testing and monitoring
Test partial failures, replayed callbacks, invalid references, missing events, and tenant-specific status values. Monitor workflow logs, rejected records, retry queues, and reconciliation results.
Why use Martini instead of scripts or point-to-point integrations?
Reusable orchestration
Martini separates FourKites intake, transformation, business rules, target updates, retries, and reconciliation into maintainable workflows rather than embedding logic in isolated scripts.
Contract flexibility
Because FourKites capabilities and data coverage can vary by tenant, Martini can consume the confirmed API or partner interface and adapt mappings without assuming a universal connector or public data model.
Reliable processing
Martini supports scheduled and event-driven workflows, checkpointing, validation, idempotency, error handling, and controlled retries for shipment and tracking synchronization.
Controlled APIs
Martini can expose secured APIs that normalize FourKites data for downstream applications, reducing point-to-point coupling while preserving customer-specific business rules.
Frequently asked questions
FourKites can be integrated through customer- and partner-specific REST APIs, selected webhook-style callbacks, EDI, carrier or telematics feeds, flat files, and other approved partner interfaces. REST APIs are the primary confirmed mechanism, while callback, document, batch, and authentication details depend on the tenant and enabled products.
Yes. Martini can integrate with FourKites by consuming the applicable FourKites REST APIs, receiving callback notifications where enabled, and orchestrating confirmed EDI, file, or partner interfaces. It can map shipments, loads, stops, appointments, carriers, and tracking events into downstream systems.
No. A dedicated FourKites connector is not required. Martini can use FourKites' confirmed native APIs, callbacks, files, EDI, authentication methods, and other approved endpoints, with the exact implementation based on the customer-specific FourKites contract.
Lonti does not charge an additional per-connector or per-vendor fee to integrate FourKites. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from FourKites, infrastructure providers, or other third-party systems depending on subscriptions, usage, and deployment model.
REST APIs should generally be evaluated first because FourKites supports customer and partner API integrations for transportation visibility data. Use callbacks when the tenant exposes the required event types, and use EDI, files, carrier feeds, or telematics interfaces when they are part of the approved implementation contract. GraphQL and SOAP are not confirmed.
Selected FourKites implementations may provide webhook-style or outbound event notifications, but public information does not establish that all shipment or tracking events are available as callbacks. Confirm event coverage, authentication, retry behavior, ordering, and duplicate delivery expectations, and use scheduled reconciliation where completeness is important.
Use a persisted watermark, modification timestamp, event identifier, or confirmed cursor model for incremental synchronization. Martini can map customer-specific FourKites fields into canonical models, normalize time zones and statuses, and use stable event identifiers or deterministic composite keys to prevent duplicate updates. Overlapping retrieval windows help detect late-arriving changes.
Yes. Martini can expose a secured REST API that presents normalized shipment, load, status, ETA, or tracking-event data to other applications. The façade can invoke FourKites workflows, apply authorization and business rules, hide tenant-specific contracts, and provide a consistent interface for downstream consumers.
Related Martini documentation
APIs
Workflows
Connect FourKites with your enterprise systems
Use Martini to implement maintainable FourKites workflows for transportation visibility, tracking events, synchronization, and operational automation.