FORMATS
EDI and booking standards
Foryn publishes a native canonical API plus two narrowly supported trading-partner EDI profiles.
Supported message profiles
| Format | Version/profile | Current support |
|---|---|---|
| X12 301 | MSC / X12 release 005030 | Narrow carrier-confirmation and documented update/cancellation codes |
| UN/EDIFACT IFTMBC | MSC / D.99B | Narrow AP-accepted confirmation and supported cancellation function |
| DCSA Booking | 2.0.0 | UNSUPPORTED for direct wire ingestion; authoritative schema mapping incomplete |
| JSON partial extract | FORYN_EXTRACT_EVENTS_V1 | 1–50 canonical booking events, per-record result |
Important integration rules
- Both EDI parsers require an application/json wrapper containing the raw EDI payload and explicit sourceRevision.
- X12 301 can contain pending, decline, split or other responses. The transaction name alone does not mean accepted.
- IFTMBC can contain AP accepted, conditional, rejected and pending responses. Only the documented accepted profile is qualified.
- The supported equipment mapping is narrow: 22G1 → 20GP, 42G1 → 40GP, 45G1 → 40HC. Other codes remain unresolved.
- The forwarder must supply separately attested canonical facts when the source wire message cannot support them.
Version and conformance limits
Do not treat these adapters as universal parsers. Trading partners must verify specific implementation guides, release versions and positive and negative samples.
DCSA's December 2024 documentation refers to Information Model 2024.Q4 while a legacy Booking 2.0.0 introduction names 2024.Q3. Foryn does not claim Booking 2.0.0 OpenAPI conformance.
The EDI message endpoint is an adapter convenience, not a mandate. IT teams can normalize their TMS or EDI feed directly into the canonical JSON booking API.
API v1 · Fictional examples · Production access requires coordinated onboarding · OpenAPI contract ↗