Freight and trucking API development built so a shipment means the same thing in every system it touches.

Usually all three, and the question is which partner takes which route. A direct API where the relationship is big enough that the carrier warns you before it changes something. EDI where the partner requires it, which still means most large carriers and North American 3PLs. An aggregator when you need coverage faster than you could build it, renting the mapping. Cost across all three turns on having one internal shape for a shipment.

They will disagree, so the design decides which one wins. A GPS ping, a carrier webhook and an EDI 214 describe the same leg, arriving hours apart, out of order, sometimes twice. We write precedence rules per event type rather than per source, keep every raw event as it arrived, and derive status from that log instead of overwriting a field. Disagreements stay answerable afterwards, and a replay returns the same answer.

That is the normal case, so the build assumes it. Every carrier-specific quirk lives inside one translator per partner rather than spread through the application. Contract tests against recorded responses make a shape change fail on your build instead of in front of a customer, and each partner flow degrades on its own. The fix is a translator edit and a test update, not a release across the platform.

Three engagement models: time and materials billed hourly and quoted per project, fixed price quoted per project against an agreed outcome, and team extension billed monthly per team member. Which fits depends on how firm the partner list is, and we recommend one after scoping. We publish no project price band: the spread between one integration and a dozen is too wide for one number. Fixed-scope work carries a post-launch warranty agreed in the contract, and team extension carries no recruitment or placement fee.

Most engagements start within two to four weeks of signature. The first partner takes the longest: it is where the internal shipment model, the event log and the reconciliation path get built. Everything after it is a translator against a harness that already exists. One documented vendor API reaches a usable release far faster than a mixed EDI and portal stack. Scoping ends with a phased plan carrying the order and the cost.

Contracts and NDAs are signed before anyone starts. Credentials stay server-side, scoped and rotated, and never reach a browser. We work from least-privilege access agreed with your technical contact, never write access to production during discovery. unicrew holds ISO 27001:2022 and ISO 9001:2015, audited by Quay Audit UK, and delivery runs with ISTQB-certified QA engineers. We do not hold SOC 2. Driver and consignee data falls under GDPR, so retention and access are data-model decisions taken at scoping.