> ## Documentation Index
> Fetch the complete documentation index at: https://terminal49.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Migrating from Project44
> Map project44 ocean tracking fields, webhooks, and errors to Terminal49 equivalents. Covers container holds, per diem fees, and checklist.
If you are using Project44 for ocean visibility, this guide maps the ocean portion of Project44 onto Terminal49 field by field, so you can replace the ocean leg without reverse-engineering our schema.
Terminal49 is ocean and terminal focused. We do not cover road, rail, LTL, or air. If your Project44 integration spans modes, this migration handles only the ocean shipments.
There is no compatibility shim. You will change your authentication, request shape, and response parsing. For most integrations that is an afternoon.
Terminal49 self-serves. Create an account, generate a free API key, and start tracking up to 10 active containers at no cost. Terminal data: holds, fees, and last free day are included on the container object out of the box.
## Start in sixty seconds
Signing up and getting a key is self-serve.
Go to [app.terminal49.com](https://app.terminal49.com). The free plan tracks up to 10 active containers.
Visit [app.terminal49.com/developers/api-keys](https://app.terminal49.com/developers/api-keys). Copy the key immediately. It is shown once and then masked forever.
```bash theme={null}
curl -X POST https://api.terminal49.com/v2/tracking_requests \
-H "Content-Type: application/vnd.api+json" \
-H "Authorization: Token YOUR_API_KEY" \
-d '{
"data": {
"type": "tracking_request",
"attributes": {
"request_number": "YOUR_BOL_NUMBER",
"request_type": "bill_of_lading",
"scac": "MAEU"
}
}
}'
```
The full API key is shown once, right after you create it. Copy it before you navigate away — after that it is masked and cannot be revealed. If you miss it, create a new key and delete the old one.
The free plan tracks up to 10 active containers. Creating tracking requests through the API works right away; reading tracking data back through the API requires a free 7-day API trial (same 10-container limit) — contact us via in-app chat or [support@terminal49.com](mailto:support@terminal49.com) and we enable it.
If you want to test without a live shipment, use the [test tracking numbers](/docs/api-docs/useful-info/test-numbers), which simulate success and failure outcomes.
**Migration offer:** sign up now and the [Vessels API](/docs/api-docs/api-reference/vessels/get-a-vessel-using-the-id) — vessel schedules, AIS positions, and projected routes — is free for your first month.
## The architectural shift
Project44 tracks multi-modal shipments with legs. Terminal49 tracks ocean shipments and containers directly. You register a tracking request once, and we keep it updated and push changes to your webhook.
OAuth client credentials to get a bearer token, then call `GET` or polling endpoints for shipment status. Multi-modal legs are bundled in one shipment resource. You own the cache, the schedule, and the deduplication across road, rail, and ocean.
`POST /tracking_requests` once → Terminal49 polls carriers, terminals, and rail → we POST to your endpoint as things change → write to your database. No cache layer, no dedupe logic.
You can keep polling if you prefer — point your existing scheduler at `GET /v2/shipments` or `GET /v2/containers`. But webhooks are the reason the API is shaped this way, and terminal data (holds, fees, last free day) changes on a cadence that polling tends to miss.
## Quick comparison
| | Project44 | Terminal49 |
| ----------------------- | -------------------------------------- | ------------------------------------- |
| Tracking model | Poll on demand, multi-modal legs | Register once, then push or poll |
| Authentication | OAuth2 client credentials bearer token | `Authorization: Token` header |
| Base URL | `api.project44.com` | `https://api.terminal49.com/v2` |
| Content type | `application/json` | `application/vnd.api+json` |
| Response format | Custom JSON | JSON:API |
| Webhooks | Webhook subscriptions available | 30+ events, HMAC-signed |
| Carrier identification | SCAC or carrier code | `scac`, or `auto_detect_vocc_scac` |
| Terminal holds and fees | No direct equivalent | Included on the container object |
| Last free day | No direct equivalent | Included, with per-source breakdown |
| Rail milestones | Limited | North American Class I and short-line |
| Multi-modal | Ocean, road, rail, air, LTL | Ocean and terminal only |
| Getting an API key | Account setup with Project44 | Self-serve |
## Authentication
Project44 uses OAuth2 client credentials. You request a bearer token from their token endpoint and include it in every call as `Authorization: Bearer`. Terminal49 uses a static API key as `Authorization: Token`.
```bash Project44 theme={null}
# 1. Request bearer token
curl -X POST https:// \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-d "client_id=YOUR_CLIENT_ID" \
-d "client_secret=YOUR_CLIENT_SECRET"
# 2. Use bearer token on every call
curl https://api.project44.com/ \
-H "Authorization: Bearer YOUR_BEARER_TOKEN"
```
```bash Terminal49 theme={null}
curl -X POST https://api.terminal49.com/v2/tracking_requests \
-H "Content-Type: application/vnd.api+json" \
-H "Authorization: Token YOUR_T49_KEY" \
-d '{"data":{"type":"tracking_request","attributes":{
"request_number":"MRKU9465770",
"request_type":"container",
"scac":"MAEU"}}}'
```
Note the `Token` prefix. It is not `Bearer`.
## Request parameter mapping
| Project44 parameter | Terminal49 equivalent | Notes |
| ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Your Project44 shipment identifier | `request_number` | Use BOL, booking, or container number |
| Container number tracking | `request_type: "container"` | |
| Bill of lading tracking | `request_type: "bill_of_lading"` | Master or house BOL |
| Booking number tracking | `request_type: "booking_number"` | |
| SCAC / carrier code | `scac` | Same SCAC values for most carriers |
| Omit carrier / auto-detect | Set `auto_detect_vocc_scac: true`, or call [Infer Tracking Number](/docs/api-docs/in-depth-guides/auto-detect-carrier) first | Auto-detection runs asynchronously; a failed inference fails the tracking request with `scac_auto_detect_failed` |
| Force refresh / requery | `PATCH /v2/containers/{id}/refresh` | Forces an immediate pull from all sources. Paid feature — requires account enablement, limited to 10 requests per minute |
| Shipment legs / routes | `GET /v2/containers/{id}/map_geojson` — requires the Routing Data entitlement | See [Routing](/docs/api-docs/in-depth-guides/routing) |
| OAuth `client_id` / `client_secret` | `Authorization: Token` header | Single static key, no token rotation |
Project44 bundles multi-modal legs in one shipment. Terminal49 expects one identifier per tracking request. Track by BOL and we return every container on that bill of lading as related container resources. Container-number tracking requests are currently in beta. If you were tracking a single leg in Project44, send the corresponding container or BOL number to Terminal49.
## Response field mapping
Terminal49 is JSON:API compliant, so relationships between shipments, containers, ports, and terminals are explicit rather than something you reassemble from ID references.
Use the [`include` parameter](/docs/api-docs/in-depth-guides/including-resources) to sideload related resources in one call instead of chasing IDs.
### Shipment level
| Project44 | Terminal49 |
| --------------------------- | -------------------------------------------- |
| Your Project44 shipment ID | `shipment.id` (UUID) |
| Bill of lading number | `shipment.attributes.bill_of_lading_number` |
| Carrier / SCAC code | `shipment.attributes.shipping_line_scac` |
| Carrier name | `shipment.attributes.shipping_line_name` |
| Shipment status | Derived from container status and milestones |
| Place of receipt | `shipment.attributes.port_of_lading_*` |
| Port of loading | `shipment.relationships.port_of_lading` |
| Port of discharge | `shipment.relationships.port_of_discharge` |
| Final destination (inland) | `shipment.relationships.destination` |
| Predictive ETA | `shipment.attributes.pod_eta_at` |
| Your Project44 cached state | No equivalent — refresh is managed for you |
### Container level
| Project44 | Terminal49 |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Container number | `container.attributes.number` |
| ISO code | `container.attributes.equipment_type` + `equipment_length` + `equipment_height` |
| Container size / type | Same three fields above |
| Container status | `container.attributes.current_status` |
| Transport events / legs | Container timestamps, [transport events](/docs/api-docs/api-reference/containers/get-a-containers-transport-events), and webhook events |
Project44 returns a single ISO code string like `45G1`. Terminal49 splits this into three normalized fields: type (dry, reefer, open top, flat rack, bulk, tank), length (10, 20, 40, 45), and height (standard, high cube). If you were parsing ISO codes yourself, you can delete that code.
### Locations, facilities, and vessels
| Project44 | Terminal49 |
| ------------------------- | ------------------------------------------------------------------------------------------- |
| Location / port name | `port.attributes.name` |
| Location code / UN/LOCODE | `port.attributes.code` |
| Latitude / longitude | `port.attributes.latitude` / `.longitude` |
| Timezone | `port.attributes.time_zone` |
| Country code | `port.attributes.country_code` |
| Terminal / facility name | `terminal.attributes.name` |
| Terminal SMDG code | `terminal.attributes.smdg_code` |
| Terminal BIC code | `terminal.attributes.bic_facility_code` |
| Vessel name | `shipment.attributes.pod_vessel_name` |
| Vessel IMO | `shipment.attributes.pod_vessel_imo` |
| Vessel MMSI | Available via the [Vessels API](/docs/api-docs/api-reference/vessels/get-a-vessel-using-the-imo) |
| Vessel call sign, flag | Not returned |
## Milestone and event mapping
Project44 uses event codes or status fields on shipment legs. Terminal49 exposes the same milestones as normalized transport events and pushes each one to your webhook.
| Project44 ocean event | Milestone | Terminal49 event |
| ------------------------- | ----------------------------- | --------------------------------------- |
| Vessel loaded event | Loaded on vessel at origin | `container.transport.vessel_loaded` |
| Vessel departed event | Vessel departed origin | `container.transport.vessel_departed` |
| Vessel arrived event | Vessel arrived at destination | `container.transport.vessel_arrived` |
| Vessel discharged event | Discharged from vessel | `container.transport.vessel_discharged` |
| Container gated out event | Gated out at destination | `container.transport.full_out` |
| Container gated in event | Gated in at origin | `container.transport.full_in` |
| — | Empty picked up at origin | `container.transport.empty_out` |
| — | Empty returned at destination | `container.transport.empty_in` |
Terminal49 also emits milestones Project44 has no equivalent for:
* **Vessel berthed** — `container.transport.vessel_berthed`
* **Available for pickup** — `container.transport.available` and `.not_available`
* **Transshipment** — arrived, discharged, loaded, departed
* **Feeder vessel and barge** — arrived, discharged, loaded, departed
* **Rail** — loaded, departed, arrived, unloaded, plus `arrived_at_inland_destination`
See the full [event catalog](/docs/api-docs/webhooks/event-catalog).
### Registering a webhook
```bash theme={null}
curl -X POST https://api.terminal49.com/v2/webhooks \
-H "Content-Type: application/vnd.api+json" \
-H "Authorization: Token YOUR_API_KEY" \
-d '{
"data": {
"type": "webhook",
"attributes": {
"url": "https://your-endpoint.example.com/t49",
"active": true,
"events": [
"container.transport.vessel_discharged",
"container.transport.available",
"container.pickup_lfd.changed"
]
}
}
}'
```
Payloads are HMAC-signed. See [webhook setup](/docs/api-docs/in-depth-guides/webhooks) for signature verification, and [List webhook IPs](/docs/api-docs/api-reference/webhooks/list-webhook-ips) if your firewall restricts inbound traffic.
## What you gain
This is the part worth reading even if the rest is mechanical. Terminal49 integrates with terminals directly, not only carriers, so the container object carries operational data that has no Project44 equivalent.
### Holds
`holds_at_pod_terminal` is an array of active holds blocking pickup:
```json theme={null}
{
"holds_at_pod_terminal": [
{ "name": "customs", "status": "hold", "description": "CBP HOLD" },
{ "name": "freight", "status": "hold", "description": null }
]
}
```
Hold names are `freight`, `customs`, `USDA`, `VACIS`, `TMF`, and `other`. Status is `hold` or `pending`. When a hold clears, the object is removed from the array — there is no released state.
Hold names are case-sensitive. `USDA`, `VACIS`, and `TMF` are uppercase; `freight`, `customs`, and `other` are lowercase. Match exactly.
### Fees
`fees_at_pod_terminal` carries type, amount, and currency:
```json theme={null}
{
"fees_at_pod_terminal": [
{ "type": "demurrage", "amount": 850.00, "currency_code": "USD" },
{ "type": "exam", "amount": 450.00, "currency_code": "USD" }
]
}
```
Fee types are `demurrage`, `extended_dwell_time`, `exam`, `total`, and `other`.
Some terminals report a `total` line item alongside individual fees. Filter it out before summing or you will double-count.
### Last free day
`pickup_lfd` is a coalesced value that follows a fixed source priority: shipping line, then terminal, then rail. It does not pick the earliest date. The individual sources are available separately on `import_deadlines`:
* `pickup_lfd_line` — the shipping line's LFD (per diem deadline)
* `pickup_lfd_terminal` — the terminal's LFD (demurrage deadline)
* `pickup_lfd_rail` — the rail carrier's LFD at the inland destination
Each has its own webhook event, so you can alert on whichever source your operation cares about.
### Release readiness
Two fields answer "can I pick this up?" — `available_for_pickup` and the holds array:
```javascript theme={null}
function isReadyForPickup(container) {
const { available_for_pickup, holds_at_pod_terminal } = container.attributes;
const hasActiveHolds = holds_at_pod_terminal.some(h => h.status === 'hold');
return available_for_pickup === true && !hasActiveHolds;
}
```
Full detail in [Holds, Fees, and Release Readiness](/docs/api-docs/in-depth-guides/holds-and-fees).
Holds, fees, LFD, and availability come back on the container object wherever the terminal is a supported source. They are not a paid add-on and they do not require a sales conversation. See [Entitlements](/docs/api-docs/useful-info/entitlements) for the features that do require account enablement.
## Gotchas that will bite you
Project44 bearer tokens expire and must be refreshed. Terminal49 keys do not expire and do not rotate. Delete your token refresh logic. If you rotate for security, create a new key in the dashboard and replace the old one.
Project44 bundles ocean, road, rail, and air legs in one shipment resource. Terminal49 is ocean only. You must extract the ocean leg and send the BOL or container number to Terminal49. Mode-crossing logic you built in Project44 will not carry over.
Project44 returns flat JSON objects. Terminal49 returns JSON:API with `data`, `relationships`, and `included`. Use a JSON:API client library, or use `include` to sideload exactly what you need. Parsing raw JSON works but you will write more code than you expect.
`POST /tracking_requests` returns immediately with a pending status. The shipment appears once the carrier responds. Subscribe to `tracking_request.succeeded` and `tracking_request.failed` rather than expecting shipment data in the creation response. A request may also land in `awaiting_manifest` if the carrier has not manifested the shipment yet — we retry automatically. See [Tracking Request Lifecycle](/docs/api-docs/in-depth-guides/tracking-request-lifecycle).
Project44 timestamp handling varies by API version and resource. Terminal49 stores event timestamps in UTC and returns the matching IANA timezone alongside. Convert for display rather than assuming local time. See [Event Timestamps](/docs/api-docs/in-depth-guides/event-timestamps).
`holds_at_pod_terminal: []` and `fees_at_pod_terminal: []` mean no active holds or fees. This is the common case. Do not treat it as missing data.
It means the terminal reported the fee type but has not posted an amount yet. Common for demurrage in the first day or two after discharge.
Terminal changes (fees, holds, LFD, appointment, availability) arrive on `container.updated` with a `changeset` showing old value first, new value second. Use it instead of diffing state yourself.
## Error handling
Project44 returns errors within the response body, sometimes alongside partial data, sometimes with an error envelope. Terminal49 uses standard HTTP status codes. Replace envelope checks with status-code checks.
| Status | Meaning |
| ------ | -------------------------------------------------------------------------- |
| 400 | Malformed request or failed validation |
| 401 | Missing or invalid API key |
| 403 | Key lacks permission, or the feature is not enabled on your plan |
| 404 | Resource does not exist |
| 422 | Valid syntax, rejected content — for example a malformed container number |
| 429 | Rate limited. See [Rate Limiting](/docs/api-docs/in-depth-guides/rate-limiting) |
| 5xx | Terminal49 or an upstream carrier or terminal is unavailable |
Rough equivalence for the Project44 errors you are handling today:
| Project44 error pattern | Terminal49 |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| Invalid or expired bearer token | HTTP 401 |
| Insufficient scope / unauthorized client | HTTP 403 |
| Rate limit exceeded | HTTP 429 |
| Invalid request parameters, malformed identifier | HTTP 400 or 422 |
| Shipment not found, unsupported SCAC | HTTP 422 |
| Carrier temporary unavailability, no response | `tracking_request.failed`, or `tracking_request.awaiting_manifest` if not yet manifested. Not surfaced directly — we retry internally. |
The [TypeScript SDK](/docs/sdk/introduction) maps these to typed errors (`AuthenticationError`, `ValidationError`, `RateLimitError`, `UpstreamError`, `FeatureNotEnabledError`, `AuthorizationError`, `NotFoundError`) and retries rate-limit and server errors automatically with exponential backoff.
## Where we are narrower than Project44
Worth knowing before you commit.
**Carrier count.** Terminal49 integrates directly with 36 ocean carriers, plus 2 more enabled on request — as of 14 August 2026. Project44 lists more. Ours are direct integrations covering the lines that move volume into North America, and each is normalized into one schema. Check your carrier mix against the [ocean carrier list](/docs/coverage/ocean-carriers) before cutover, and read the known issues section there — we publish the per-carrier field gaps.
**Terminal data is North America.** Holds, fees, LFD, and availability come from direct terminal integrations concentrated in the US and Canada, with European ports expanding. Ocean milestones work globally; terminal-level operational data does not yet.
**No road, rail, air, or LTL tracking.** If your Project44 integration covers those modes, this migration handles only the ocean portion. You will need to keep Project44 or another provider for the non-ocean legs.
**No freight rates or sailing schedules.** We do not offer a rate calculator, rate index, or schedule search.
**Some fields are source-dependent.** Seal number, container weight, and departure or arrival events vary by carrier. The [field availability reference](/docs/coverage/fields) says which fields are always present and which depend on the carrier, terminal, or journey.
## Migration checklist
Everyone does the base path. Then pick a branch.
### Base path
Self-serve at [app.terminal49.com/developers/api-keys](https://app.terminal49.com/developers/api-keys). Copy it immediately — it is shown once.
Project44 bearer tokens expire. Terminal49 keys do not. Replace your token acquisition and refresh logic with a static `Authorization: Token` header.
Compare your Project44 carrier codes against the [carrier list](/docs/coverage/ocean-carriers). Flag anything missing before you cut over.
Extract ocean legs from your Project44 shipments. Send the corresponding BOL, booking, or container number to Terminal49.
One `POST /tracking_requests` per BOL, booking, or container, replacing the per-request lookup.
Tracking requests start pending. Handle `succeeded`, `failed`, and `awaiting_manifest` rather than expecting data on creation.
JSON:API structure, split equipment fields, UTC timestamps with a separate timezone.
Replace envelope checks with HTTP status codes.
Submit tracking requests for everything currently in transit. Send us the list if it is large and we will load it.
Holds, fees, and LFD are the reason to do this properly rather than porting like for like.
### Then pick one
1. Expose an HTTPS endpoint that accepts our POST payloads.
2. Register a webhook and subscribe only to events you act on.
3. Verify HMAC signatures.
4. Whitelist our IPs if your firewall restricts inbound traffic.
5. Trigger a test delivery before going live.
6. Retire your polling job and your dedupe layer.
See [webhook best practices](/docs/api-docs/webhooks/best-practices) for retries and idempotency.
1. Store the tracking request ID from the creation response. The shipment ID arrives later — the creation response is pending with no shipment attached; fetch the tracking request again (or handle `tracking_request.succeeded`) to get it once the carrier responds.
2. Repoint your existing scheduler at `GET /v2/shipments` or `GET /v2/containers`.
3. Keep your existing cadence.
Skipped: endpoint setup, signature verification, IP whitelisting, delivery testing.
Terminal data changes on a cadence polling tends to miss. If you only adopt webhooks for one thing, make it `container.updated` and `container.pickup_lfd.changed`.
## Migrate with an AI coding agent
If you use Claude Code, Cursor, Codex, Windsurf, Copilot, or another AI coding assistant, hand it the prompt below. It is written to run a **side-by-side migration**: the agent stands up a Terminal49 client next to your existing project44 code, shadows every project44 call with a Terminal49 call, diffs the responses, and only cuts over once parity is proven.
Point your agent at this page as context (paste the URL or add it as a doc source). The prompt references the mappings above, so the more of this page the agent can see, the better it does.
1. Open your repo in your AI coding tool.
2. Add this page as a documentation source, or paste its URL into the chat.
3. Copy the prompt below into a new chat and send it.
4. Answer the agent's discovery questions (project44 client location, env var names, carrier mix).
5. Review each PR the agent opens. It should ship in small, reviewable steps: client, shadow, parity harness, cutover, cleanup.
* A `Terminal49Client` alongside your existing project44 client, sharing the same interface where possible.
* A shadow-mode wrapper that calls both providers and logs response diffs without changing behavior.
* A parity report per shipment: matched fields, diverged fields, and Terminal49-only fields (holds, fees, LFD).
* A feature-flagged cutover: route reads to Terminal49, keep project44 as fallback until you flip the flag off.
* A webhook receiver with HMAC verification, or a polling scheduler, depending on which path you pick.
* A cleanup PR that removes project44 code, env vars, dependencies, and dedupe logic.
### The prompt
Copy this into your agent. Replace the bracketed placeholders in the **Repo context** block before sending.
```markdown Terminal49 migration agent prompt expandable icon=robot wrap theme={null}
You are migrating this codebase from the project44 API to the Terminal49 API,
side by side. Terminal49's authoritative migration guide is at
https://terminal49.com/docs/migrate/project44. Use it as
the source of truth for field mappings, event names, error codes, and behavior differences.
# Repo context (fill this in before running)
- project44 client lives at: [path/to/client]
- project44 is called from: [list the call sites or "find them"]
- Language and framework: [e.g. TypeScript + Node, Python + FastAPI, Ruby on Rails]
- Storage for tracking state: [e.g. Postgres table `shipments`]
- Current polling schedule: [e.g. cron every 2h]
- Carrier mix (SCACs we track most): [e.g. MAEU, MSCU, CMDU, HLCU, ONEY]
- Deployment target: [e.g. AWS ECS, Vercel, Fly.io]
- Secret store: [e.g. AWS Secrets Manager, `.env`, Doppler]
# Rules
1. Do not delete project44 code until the cleanup step. Migration is side by side.
2. Ship in small PRs. Each PR must build, pass tests, and be independently revertable.
3. Never invent Terminal49 fields, endpoints, or event names. If the guide does not
confirm a mapping, ask me. Do not guess.
4. Terminal49 uses `Authorization: Token ` (not `Bearer`) and content type
`application/vnd.api+json`. Get this right on the first request.
5. Terminal49 is asynchronous. `POST /tracking_requests` returns pending. Data arrives
via `tracking_request.succeeded`, `tracking_request.failed`, or
`tracking_request.awaiting_manifest` webhooks, or by polling `GET /v2/shipments`. Do not expect shipment data on creation.
6. Timestamps are UTC with a separate IANA `time_zone` field. Do not assume local time.
7. `holds_at_pod_terminal: []` and `fees_at_pod_terminal: []` are the normal state,
not missing data. A fee `amount` of 0 is valid.
8. On `container.updated`, prefer the `changeset` over diffing state yourself.
9. Terminal49 uses a static API key. Delete the OAuth2 client-credentials token flow,
token refresh logic, and any token-refresh cron jobs in the cleanup step — do not
port them.
10. Terminal49 covers the ocean leg only. Keep project44 air, road, rail, and LTL
tracking in place. Extract the ocean leg from each multi-modal shipment before
mapping it.
# Plan (execute in order, one PR per step)
## PR 1 — Discovery and interface
- Grep the repo for every project44 call site. List them in the PR description.
- Extract the project44 client's public surface into an interface
(`TrackingProvider` with methods like `track(number, type, carrier)`,
`getShipment(id)`, `refresh(id)`).
- Make the existing project44 client implement it. No behavior change.
## PR 2 — Terminal49 client
- Add a `Terminal49Client` implementing the same `TrackingProvider` interface.
- Auth via `T49_API_KEY` env var, header `Authorization: Token ${key}`.
- Base URL `https://api.terminal49.com/v2`, content type `application/vnd.api+json`.
- Implement:
- `createTrackingRequest({ request_number, request_type, scac })` returning the
tracking request ID.
- `getShipment(id, { include: 'containers,port_of_lading,port_of_discharge' })`.
- `getContainer(id)`.
- `refreshContainer(id)` mapping to `PATCH /v2/containers/{id}/refresh` (a paid
feature — skip it unless our account has it enabled).
- Normalize responses to the same shape project44 callers expect today, using the field
mapping from the guide. Split equipment codes into `equipment_type`, `equipment_length`,
`equipment_height`. Convert timestamps to UTC + `time_zone`.
- Map errors to typed classes: `AuthenticationError` (401), `AuthorizationError` (403),
`ValidationError` (400/422), `RateLimitError` (429), `UpstreamError` (5xx),
`FeatureNotEnabledError` (403 + feature flag response).
- Add unit tests using recorded fixtures. Do not hit the live API in tests.
## PR 3 — Shadow mode
- Add a `ShadowProvider` that wraps both clients. On every read:
- Call project44 as the primary. Return its response.
- Fire-and-forget a Terminal49 call for the same identifier.
- Log a structured diff: matched fields, diverged fields, T49-only fields.
- Gate with env var `TRACKING_SHADOW_MODE=true`. Off by default.
- Add a parity report script that aggregates shadow logs by SCAC and field.
- Do NOT change what callers see. This step is observation only.
## PR 4 — Backfill script
- Write a one-shot script that reads all active shipments from our database and calls
`POST /tracking_requests` for each (one per BOL, booking, or container).
- Store the returned `tracking_request.id` and eventual `shipment.id` on our records.
- Rate-limit to respect Terminal49's limits (handle 429 with exponential backoff).
- Idempotent: safe to re-run. Skip rows already backfilled.
## PR 5 — Webhook receiver (only if we picked the webhook path)
- Add `POST /webhooks/terminal49` endpoint.
- Verify HMAC signature using the shared secret from `T49_WEBHOOK_SECRET`. Reject on
mismatch with 401.
- Handle these events at minimum:
- `tracking_request.succeeded`, `tracking_request.failed`, `tracking_request.awaiting_manifest`
- `container.transport.vessel_discharged`, `container.transport.available`,
`container.transport.full_out`
- `container.updated` (use the `changeset`, do not diff)
- `container.pickup_lfd.changed`
- Persist events idempotently keyed by event ID.
- Register the webhook via `POST /v2/webhooks` from a bootstrap script, subscribing
only to events we handle.
- If our firewall restricts inbound traffic, whitelist Terminal49 IPs from
`GET /v2/webhooks/ips`.
## PR 6 — Cutover behind a flag
- Add feature flag `TRACKING_PROVIDER` with values `project44` (default) and `terminal49`.
- Route all reads through the flag. project44 stays available as a fallback for one
release cycle.
- Flip staging to `terminal49`, verify parity report is clean, then flip production.
## PR 7 — Cleanup
- Delete the project44 client, its tests, its env vars, its dedupe cache, and any
equipment-code parsing helpers Terminal49 makes redundant.
- Remove the shadow provider and the feature flag.
- Update README and any runbooks. Note the new webhook endpoint if applicable.
# Definition of done
- All project44 call sites now go through Terminal49.
- Webhook (or polling) is live in production.
- Parity report shows no unexplained divergences for our top 10 SCACs.
- Holds, fees, and LFD are exposed to whichever downstream system needs them
(dashboard, alerts, customer emails). Do not migrate without wiring these up. They
are the reason to do this properly.
- project44 dependency, env vars, and dead code are gone from the repo.
# Ask me before you
- Choose between the webhook path and the polling path. Default to webhooks unless our
infra makes an inbound HTTPS endpoint hard.
- Change the shape of any function project44 callers use today. Prefer a normalization
layer inside the Terminal49 client.
- Add a new dependency. Prefer stdlib and what is already in the repo.
- Touch anything outside the tracking integration.
```
## Getting help
Send us your list of active container and bill of lading numbers and we will load them rather than making you script the backfill.
If something in this mapping is wrong or incomplete, tell us. We would rather fix the page than have you work around it.
Every endpoint, with request and response schemas
Typed client with retries and pagination built in
Carriers, terminals, rail, and field availability
Simulate success and failure outcomes