Documentation

Everything you need to design carrier packets, embed them on your site, and pull signed records into your TMS.

New to CarrierPacket.Link? Start with the 5-minute Quickstart — create an account, build a packet, share the link, and watch a signup land in your dashboard. After that, dive into the area that matters for your integration.

The product in one paragraph

Brokers build digital carrier packets in our designer. Each packet has a unique link they share or embed. Carriers click in, autofill from FMCSA, upload documents, and sign — the whole thing under five minutes. The signed packet shows up in the broker's dashboard with the full audit trail (signature, IP, timestamp, uploaded docs). From there it can flow out via webhooks, get pulled by your TMS via the REST API, or just sit in the Carriers list for human review.

The flow in three steps

Every part of the product fits into one of these three buckets. The docs are organized the same way.

StepWhat happensWhere to read
1. Design You build a carrier packet in the visual Designer. Pick branding, which fields and documents the carrier provides, and your broker–carrier agreement text. Embed & share
2. Connect You decide what happens after a carrier signs — email/SMS notifications, webhooks to your server, or pulled on demand via REST. Webhooks · REST API
3. Receive Signed packets land in your Carriers tab with the full audit trail and the verified-signature seal. Click through to view, mark verified, or archive. Quickstart → Receive

Key concepts

If a term in here is fuzzy, the Concepts page has the full data model. The four you'll see most often:

  • Packet — a template you design once. Has its own URL, branding, and document requirements. A broker can have multiple (e.g. one for power-only carriers, one for reefer).
  • Submission — one carrier completing one packet. This is the row that lands in your Carriers list.
  • Embed token — the unguessable string in /c/<token>. Every packet has one; regenerate it from the Packets page if a link gets shared somewhere it shouldn't be.
  • Verified vs. signed — "signed" means the carrier completed the form. "Verified" means they also clicked the link in the verification email we sent. Both events fire as separate webhooks.

Common integration paths

You don't need to build anything. Sign up, build a packet in the Designer, copy the public link from the Share modal, and email it to your carriers. Signed packets land in Carriers. Done.

→ Read: Quickstart

"I want the form on my own website"

Use the iframe snippet from the same Share modal. Pastes into any CMS — WordPress, Squarespace, Wix, plain HTML. No code required on your end.

→ Read: Embed & share

"I want signed packets pushed into my TMS automatically"

Set up a webhook that fires on carrier.signed (and optionally carrier.verified). Your endpoint receives the full submission as JSON, signed with HMAC-SHA256. Copy-paste receivers in PHP, Node.js, and Python.

→ Read: Webhooks

"I want to pull data on demand"

Generate an API key on Embedded, send Authorization: Bearer cpl_… headers, hit GET /v1/submissions for the list. Bonus: GET /v1/documents?expiring_within=30 gives you an "insurance about to expire" report with one call.

→ Read: REST API

Conventions used in these docs

  • HTTP method+path chips look like GET /v1/submissions.
  • Code samples are dark-themed and copy-pasteable. Inline code looks like this.
  • Replace cpl_xxx_yyy-style placeholders with your actual key/token.
  • Callouts:
    Useful context or pointers to related docs.
    Something that will bite you if you ignore it.
    Optional improvement / "you can also…" idea.
    Documented but not yet shipped. Plan around the shape; it's coming.

Need help?

Email support@carrierpacket.link if anything in here is wrong, missing, or confusing. We'd rather hear about it than have you guess.