docs: clarify inland rail vs SSL ETA/ATA fields and pickup_lfd sources

[mintlify]

Summary

Clarify recurring field-definition questions about inland rail vs. shipping-line ETA/ATA and how pickup_lfd is sourced, so readers can answer them from the docs alone.

Changes

• Rail integration guide: add a "rail carrier vs. shipping line" comparison table for ind_eta_at/ind_ata_at (container, rail-sourced) vs. destination_eta_at/destination_ata_at (shipment, SSL-sourced), document the pickup_lfd coalescing order, and flag ind_facility_lfd_on as deprecated in favor of import_deadlines.pickup_lfd_rail.
• OpenAPI: add descriptions for shipment pol_etd_at, pol_atd_at, pod_eta_at, pod_original_eta_at, pod_ata_at, destination_eta_at, destination_ata_at, and container ind_eta_at, ind_ata_at, ind_rail_unloaded_at; clarify source/timezone on import_deadlines.pickup_lfd_rail and pickup_lfd_line.

Context

Recent docs-assistant traffic shows repeated questions about the difference between the shipment-level destination_* arrival fields and the container-level ind_* arrival fields, and about how pickup_lfd is derived from import_deadlines. The schema fields existed but lacked descriptions, and the rail guide didn't call out the data-source distinction.

Greptile Summary

This PR adds clarifying documentation to close a recurring gap in the rail integration guide and OpenAPI spec: the distinction between rail-carrier-sourced ind_* fields and SSL-sourced destination_* fields, and the coalescing order that drives the top-level pickup_lfd value. No code changes are included.

• Rail guide: adds a comparison table for ind_eta_at/ind_ata_at (container, rail carrier) vs. destination_eta_at/destination_ata_at (shipment, SSL), documents the three-level pickup_lfd coalescing order, and officially deprecates ind_facility_lfd_on in favor of import_deadlines.pickup_lfd_rail.
• OpenAPI: adds descriptions to 9 previously undescribed shipment and container datetime fields and improves the pickup_lfd_rail / pickup_lfd_line descriptions to include source, timezone, and webhook guidance.

Confidence Score: 4/5

Documentation-only change; safe to merge with one minor clarification worth addressing.

The guide adds timezone annotations for pickup_lfd_terminal (item 2) and pickup_lfd_rail (item 3) in the coalescing list but leaves item 1 — pickup_lfd_line, the most commonly used value — without one. This creates an incomplete picture for readers trying to correctly display timestamps, and the OpenAPI description for that field is itself ambiguous. All other additions are accurate and internally consistent.

The pickup_lfd_line entry in the coalescing list in docs/api-docs/in-depth-guides/rail-integration-guide.mdx needs a timezone annotation to match the pattern set by the other two entries.

Important Files Changed

Filename	Overview
docs/api-docs/in-depth-guides/rail-integration-guide.mdx	Adds a rail-carrier-vs-SSL ETA/ATA comparison table, a Rail LFD coalescing-order list, and deprecates ind_facility_lfd_on. Content is accurate; the coalescing list omits a timezone note for pickup_lfd_line that it provides for the other two sources.
docs/openapi.json	Adds descriptions to 9 previously undocumented shipment/container datetime fields and updates pickup_lfd_rail / pickup_lfd_line descriptions. Changes are purely additive and consistent with the guide additions.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Container pickup_lfd (coalesced)"] --> B{"pickup_lfd_line\n(shipping line)\nnon-null?"}
    B -- Yes --> C["Use pickup_lfd_line\ntimezone: final_destination_timezone\nor pod_timezone (carrier-dependent)"]
    B -- No --> D{"pickup_lfd_terminal\n(POD terminal)\nnon-null?"}
    D -- Yes --> E["Use pickup_lfd_terminal\ntimezone: pod_timezone"]
    D -- No --> F{"pickup_lfd_rail\n(rail carrier)\nnon-null?"}
    F -- Yes --> G["Use pickup_lfd_rail\ntimezone: final_destination_timezone"]
    F -- No --> H["pickup_lfd = null"]

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
docs/api-docs/in-depth-guides/rail-integration-guide.mdx:163-165
**Missing timezone for `pickup_lfd_line` in the coalescing list**

Items 2 and 3 in the ordered list include a `(timezone: …)` note, but item 1 — `pickup_lfd_line`, the most commonly used value — does not. The OpenAPI description for that field reads "Corresponding timezone is `final_destination_timezone` or `pod_timezone`", which is itself ambiguous. A reader using this coalescing list to know which timezone to use when displaying `pickup_lfd` will hit a dead end for the preferred source. Adding a concise note here (e.g., "timezone: varies by carrier — see `import_deadlines.pickup_lfd_line` for details") would complete the pattern started by items 2 and 3.

_{Reviews (1): Last reviewed commit: "docs: clarify inland rail vs SSL ETA/ATA..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
api	Ready	Preview, Comment	Jun 15, 2026 4:12pm

[greptile-apps]

Missing timezone for pickup_lfd_line in the coalescing list

Items 2 and 3 in the ordered list include a (timezone: …) note, but item 1 — pickup_lfd_line, the most commonly used value — does not. The OpenAPI description for that field reads "Corresponding timezone is final_destination_timezone or pod_timezone", which is itself ambiguous. A reader using this coalescing list to know which timezone to use when displaying pickup_lfd will hit a dead end for the preferred source. Adding a concise note here (e.g., "timezone: varies by carrier — see import_deadlines.pickup_lfd_line for details") would complete the pattern started by items 2 and 3.

Prompt To Fix With AI

This is a comment left during a code review.
Path: docs/api-docs/in-depth-guides/rail-integration-guide.mdx
Line: 163-165

Comment:
**Missing timezone for `pickup_lfd_line` in the coalescing list**

Items 2 and 3 in the ordered list include a `(timezone: …)` note, but item 1 — `pickup_lfd_line`, the most commonly used value — does not. The OpenAPI description for that field reads "Corresponding timezone is `final_destination_timezone` or `pod_timezone`", which is itself ambiguous. A reader using this coalescing list to know which timezone to use when displaying `pickup_lfd` will hit a dead end for the preferred source. Adding a concise note here (e.g., "timezone: varies by carrier — see `import_deadlines.pickup_lfd_line` for details") would complete the pattern started by items 2 and 3.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
terminal49	🟢 Ready	View Preview	Jun 15, 2026, 4:29 PM