For OTM data consumers
Open Trip Model integration
Not every partner is on the Open Trip Model. Some still send PDF and email. Chainfill delivers OTM-compliant data from any source.
- Incoming streams
- Source-agnostic
- PDF, email, or legacy EDI in
- Output
- OTM-compliant
- The schema your TMS expects
OTM is the modern standard, but the chain isn't on the same page
Open Trip Model is an open, JSON-based exchange model for logistics data. It is built for real-time collaboration over REST/JSON instead of batch EDI, and is positioned as the modern successor to classical EDI formats in the Dutch logistics sector.
In practice, part of the chain is on OTM and part is not. Smaller forwarders, foreign carriers, and one-person partners still send PDF, email, or legacy EDI. A team that consumes OTM often only sees half of the stream arrive in the right format.
The problem
Where OTM stalls in practice
- 01
Not every partner supports OTM. Smaller forwarders and foreign partners still send PDF and email.
- 02
TMS systems that can consume OTM receive non-OTM input and end up translating manually.
- 03
Hand-written mappings between legacy formats and OTM break with every schema change.
Bridging non-OTM sources into the OTM stream
Partners that still send PDF, email, or legacy EDI are extracted and mapped into OTM-compliant payloads. Your TMS sees one schema regardless of where the order entered the chain. The bridge to Open Trip Model is the same: one extraction layer turns mixed inbound streams into the OTM payloads downstream systems already understand.
- 01
PDF orders
Forwarders and one-person partners
- 02
Email + attachments
Shippers without API access
- 03
Legacy EDI
EDIFACT, X12
- 04
Existing OTM feed
Partners already on OTM
- 05
Chainfill OTM bridge
One OTM-compliant stream
How it works
From mixed input to one OTM stream
Capture every source
Non-OTM streams (PDF, email, EDIFACT, X12, CSV) land in the same inbox as your existing OTM feed.
Extract to structured fields
AI recognises field meaning regardless of layout, including the partner-specific terminology your TMS expects normalised.
Map to OTM
Validated fields are projected onto the OTM schema your TMS or integration layer consumes. Versioning is aligned per customer, so no team gets a forced OTM upgrade or schema mismatch.
Hand off to your TMS
Records land in OTM format alongside your existing OTM partners. Downstream consumers see one uniform stream.
Stories from our customers
Logistics companies already growing without extra people.
Customer story
- of orders automatic
- 90%
“Since going live in October, Hartog Transport now processes 90% of its order flow automatically with Chainfill. A process that previously required many manual steps has become a much more efficient and scalable way of working.”
The result
One schema, regardless of how partners deliver
What consuming OTM looks like once Chainfill takes over the source-side translation.
Without Chainfill
Mixed input
PDF, email, EDIFACT, CSV and OTM all mixed in. Your TMS or integration layer still translates per stream.
With the Chainfill OTM bridge
Uniform OTM
Non-OTM sources are extracted and passed through in OTM format. Your TMS sees one schema.
One uniform schema for everything downstream
Conceptual framing: OTM stays the schema your TMS consumes. Chainfill fills the gap for partners not on OTM yet.
Your TMS or integration layer sees a single uniform OTM stream, whether the partner is on the standard yet or still sends PDF attachments. The bridge moves with you as more of the chain migrates.
Conceptual, based on OTM positioning.
Frequently asked questions
Finn Loots
Founder
Is your question not listed?
Call or email us. You will hear back from someone who knows the product.
Ready to remove the manual work?
See where Chainfill can save time in your document, email, and system workflows.