Tracking & visibility

Look up logistics companies and equipment, and get alerts

Conterminal publishes open reference pages for drayage carriers, forwarders, terminals, steamship lines, and vessels. Reviewed company profiles include source-backed facts, direct official actions, and a public correction path. Entity alerts remain available for terminals, lines, vessels, and signed-in company records.

10 minute read · Updated September 6, 2026

The directories at /carriers, /forwarders, /terminals, /lines, and /vessels need no account and no sign-in. Only reviewed, explicitly published records appear. Alerts are separate: you give an email address, confirm it once, and manage subscriptions from links inside the emails.

Public pages vs the app

Most entities have two pages that look similar and answer different questions. The public page is reviewed reference data about the company, facility, line, or vessel. The signed-in page is reference data plus your containers.

Public — /terminals/<slug>: Gate hours, appointment link, contacts, cameras, vessel receiving schedule, and the empty-return acceptance grid, with a source link on every externally-sourced fact. Ends with an email-alert form and a “See your containers at this terminal” button that routes to the login page.
Public — /carriers/<slug> or /forwarders/<slug>: A reviewed drayage-carrier or freight-forwarder profile with identifiers, coverage, capabilities, official action links, source dates, and a correction link. The page never includes private shipment data or unreviewed research notes.
Public — /lines/<slug>: A published U.S. ocean-carrier reference profile. Depending on the record, it shows operational identity, tracking, published tariff defaults, official links, and source-attributed terminal empty-return acceptance. Fields stay absent when the current evidence does not support them.
Signed in — /protected/terminals/<slug>: The same profile with a working-set overlay of your own containers at that terminal, and internal per-cell remarks on the empty-return grid. Those internal remarks stay private. A public Maher lookup may separately include a bounded excerpt of the terminal's own equipment-specific instruction when it supports an exact result.

The signed-in equivalent of the whole directory is Entities. That page leads with counts — Active Delivery Orders, Companies You Work With, Terminals On File, Lines On File, Vessels Tracked — and then lists companies, terminals, lines, and vessels tied to your shipments. Use it when you want the entities you touch. Use the public directory when you want any facility in the catalog, published or not yet worked. Use the carrier and forwarder directories when you want a public, source-backed company reference rather than a relationship view.

In supported carrier, BCO, and freight-forwarder workspaces, active delivery-order counts use Conterminal's canonical physical tracking state. An eligible shipment remains active until Gate In. BCO and forwarder company cards count unique shared delivery orders. Carrier cards separate historical links from active shipments: historical links count company roles, so one delivery order can contribute more than one link. These activity views do not add warehouse support or independently managed tracking records.

If the activity read is incomplete or fails, the affected counts and sections show Unavailable or a temporary unavailability message, not zero. Public reference catalogs remain independent of your shipment activity. An unsupported workspace type is also different from an outage: it has no activity view. For company-profile previews and historical counts, see Company directories.

The /lines index is a national ocean-carrier reference surface. It combines published operational line profiles with source-backed directory profiles. Directory evidence shows its official source links and As of dates; operational profiles may also show published tariff defaults, tracking, and terminal empty-return acceptance when that source is available. Publication is staged, so the directory is not a complete list of every ocean carrier or U.S. port.

The two catalogs are not the same size and are not meant to be. Public entity pages exist only for entities that have been explicitly published with a confirmed official website; the signed-in console counts everything on file. A terminal you see inside the app can legitimately have no public page, in which case its name is plain text rather than a link.

Searching drayage carriers and forwarders

/carriers is a drayage directory, not a general motor-carrier registry. It covers only published carriers with affirmative evidence of port or rail-container drayage service. An FMCSA authority record or a self-reported intermodal flag alone does not qualify a profile. /forwarders covers published freight forwarders. Search matches company names, identifiers, services, cities, and states. You can also filter by coverage tier, provider class, state, and reviewed capability.

Rich profile: A fully reviewed launch profile with meaningful source-backed facts and official actions. The profile shows when its projection was last verified.
Reference record: A deliberately narrower public identity record with a confirmed official website. Other missing fields stay missing instead of being guessed or filled from an unreviewed source.

Official actions can include the company website, quote or booking tools, tracking, tariffs, claims, safety records, authority records, office locators, or support. Follow the action link for the current operating detail; Conterminal records the source and verification date so you can judge freshness.

Directory coverage is staged and reviewed in publication sets. A company can be active with a regulator and still be absent from the public directory until its identity, official website, sources, and profile have cleared review. A motor carrier also needs affirmative drayage-service evidence. Absence is not evidence that a company is inactive.

If a published profile is wrong or stale, choose Report outdated information. Include a public source URL when possible. Reports enter a staff review queue and never update or publish a profile automatically. Do not include credentials, shipment data, or other confidential information.

Searching and faceting terminals

/terminals is the only directory with search. The whole published list is delivered with the page, so filtering is instant and never hits the network — but it also means the search only knows about the fields that are on the cards.

Type into Search terminals. The field is labeled Search terminals with the placeholder Name, city, state, port, or operator. Matching is case-insensitive substring matching across exactly those five values. A UN/LOCODE, a FIRMS code, or a SCAC will not match.
Narrow with the facets. Three groups appear below the search box: State, Port / gateway, and Terminal type. Each button shows a count. Selecting one in each group narrows the list further; selecting the same button again clears it.
Read the count line. Above the results you get Showing 4 of 11 terminals or similar, plus a Clear filters link once anything is active. With nothing matching you get “No terminals match the current search and filters.”

Facet buttons and their counts are derived once from the full list and do not change as you type. A facet button can therefore show a count of 6 while the visible list shows 1, because the count describes the whole catalog and not the filtered view. It is not a bug, but it will mislead you if you read the counts as “remaining.”

A terminal only appears under Port / gateway or Terminal type when that classification is actually known for it. Conterminal leaves those blank rather than guessing, so a facility with an unconfirmed classification is reachable by search and by State, but is filtered out the moment you press a gateway or type button. If you cannot find a terminal you know exists, clear the facets and search by name.

/lines and /vessels have no search box and no facets — they are plain alphabetical card grids. Use your browser's find-in-page there.

Reading a terminal profile

Terminal pages come in two shapes behind the same URL, and knowing which one you are on saves you from hunting for a section that was never there.

Curated operational profile: The deeply-covered terminals. Structured gate hours, appointment status, phone and email contacts, terminal cameras, a vessel receiving schedule, a live empty-return acceptance grid, and an email-alert form.
Directory reference profile: The broader published national ocean-terminal and rail-ramp set. Coordinates and coordinate basis, facility codes (UN/LOCODE, FIRMS code, SPLC, serving railroads), official links, facility notes, and FAQ — no structured gate-hours table, and no email-alert form on the page.

Gate hours

On a curated profile, gate hours render as three rows — Mon–Fri, Sat, and Sun — and any day with no published value is simply omitted rather than shown as closed. Underneath sits Verify with the terminal: and a link to the operator's own site. Treat that link as the authority; the page is a convenience copy. A directory profile has no hours table at all; it offers a Gate hours link under Links & systems instead.

The Appointment block always renders, and reads either Appointment required or No appointment required, followed by a Make an appointment link when the operator publishes one.

Receiving schedule

The Receiving schedule table carries one row per vessel call with the columns Vessel / Voyage, ETA, Begin receiving, Cargo cutoff, Hazmat cutoff, and Reefer cutoff. Vessel names link through to the vessel page when that vessel is published. The whole section is hidden unless Conterminal can point at the terminal's own schedule page as the source, so its absence means “no attributable source” rather than “no vessels.”

Empty-return acceptance

The grid puts steamship lines down the left and equipment classes across the top, with one status badge per cell and an em dash where the terminal publishes nothing for that combination. Above it are the source link and an As of timestamp. The page states the operating rule plainly: empty-return acceptance “changes daily. Always confirm same-day before dispatching a driver.”

Accepted: The terminal is taking that line and equipment class.
Restricted: Taking it under a limitation the terminal has published.
Conditional: Taking it only if some condition is met.
Not Accepted: Not taking it.
Unknown: A value was published but does not map to a known status.

When the underlying refresh falls behind, the grid prints “This terminal’s refresh is overdue — treat the statuses below as unconfirmed and verify same-day before dispatching.” Overdue public status cells are replaced with Unknowninstead of carrying an old acceptance decision forward. Verify with the terminal before dispatching.

Where a terminal publishes no acceptance page of its own, the section stays but the grid does not, and the page says the terminal “does not currently publish an operator-owned public empty-return acceptance page. Confirm acceptance with the terminal or your steamship line directly.” The grid is refreshed by LongShorty, the worker that signs in to terminal systems on Conterminal's behalf; every status change it observes is also what feeds the alert emails below.

Integrations can read the same redacted, source-dated status from /api/public-terminals/<terminal-slug>/empty-returns. The Conterminal ChatGPT app uses the same published snapshot. Both surfaces omit internal remarks, credentials, raw provider data, and shipment records. For Maher, an exact line-and-equipment result may include a short excerpt of the operator's published instruction so the decision can be checked against the linked report. A broad line rule, missing match, invalid snapshot, or overdue snapshot never becomes an acceptance decision.

Subscribing an email to alerts

The subscribe form sits near the bottom of a published terminal, line, or vessel page, headed Get alerts for <entity name>. It describes itself accurately: “Free email alerts for empty-return acceptance changes and page updates. One confirmation email, then at most one digest a day.”

Enter an address in Email address and select Get email alerts. The button reads Sending... while it works.
The form is replaced by Check your email to confirm. and “We sent a confirmation link. Once verified, you’ll get a daily digest of changes for <entity name>.”
Open the email from Conterminal Alerts, subject Confirm your Conterminal email alerts, and select Confirm your email.

Every subscription is created with both alert kinds switched on, and there is no per-kind choice anywhere in the interface:

Empty-return changes: A status flip, a newly listed line/equipment pair, or a pair disappearing from a terminal's acceptance grid. Produced by diffing the grid before and after each LongShorty refresh cycle, so it fires on what a viewer would actually see change.
Page updates: A substantive republish of the entity's own profile facts. Content-addressed, so republishing byte-identical content produces no alert, while a genuine edit on the same day does.

An empty-return change produces alerts for both sides of the change — the terminal and the steamship line — so subscribing to a line and to a terminal it calls will show you the same change twice, once under each heading.

“Check your email to confirm.” means the request was accepted, not that an email was delivered. The verification send is deliberately fail-soft: if the mail provider rejects or defers it, subscribe still reports success and the failure is only visible in server logs. There is no delivery queue behind it — the retry is you submitting the form again, which mints a fresh link. If no email arrives within a few minutes, check spam, then resubmit once. Do not hammer it; you get five subscribe attempts per hour per address.

An address that is already confirmed gets no email when you subscribe it to another entity — there is nothing left to verify, so the new subscription is simply live. That is why the second and third entity you add feel silent compared with the first.

Verifying and managing subscriptions

The confirmation link lands on /alerts/verify, headed Confirm your email. Success shows Email confirmed — “You’re verified. You’ll get a daily digest of changes for the entities you follow.” The link is single-use; clicking it again gives Link already used with “This link isn’t valid anymore. If you already confirmed this email, you’re all set — no further action is needed.” That is not an error.

Once verified, you receive at most one digest per day, sent daily at 11:00 UTC — roughly 6–7 a.m. US Eastern, just after the business-day boundary the digest window is anchored to. Its subject counts the changes, for example 3 updates on your Conterminal alerts, and it is headed Your daily digest with one block per entity. A day with no changes produces no email at all, so silence is the normal state.

Digest summaries quote the underlying status values rather than the badge labels on the page — you will read “changed from accepted to not_accepted” in the email where the grid shows Accepted and Not Accepted. Same data, rawer wording.

The manage page

/alerts/manage is reachable only through the Manage your alerts link in an alert email — there is no login and no way to request the link from the site. It opens on Manage your alerts, shows Signed in as with your address masked to something like j***@example.com, and lists Your subscriptions (3/20) with a Remove button per row.

Remove one entity. Select Remove on its row. This affects that entity only; the rest of your subscriptions and your confirmed address are untouched.
Add one. Under Add a subscription, choose an Entity type — Terminal, Steamship line, Vessel, or Company — enter the Entity slug, and select Add.
Get the slug from the URL. It is the last path segment of the entity's own page. Open the page and copy what follows /terminals/, /lines/, or /vessels/.

Do not trust the slug example.

The Add form's hint offers conterminal.com/terminals/newark-nj as the model. Real terminal slugs carry a generated suffix — for example apm-terminals-fyv1yt — so a slug typed from that example will not match anything. Worse, the form does not check the slug against a real entity: a typo is accepted, consumes one of your 20 slots, and then never produces an alert. Always copy the slug out of the address bar.

The manage link is a one-shot capability that rotates every time you add or remove. Only the link in your most recent alert email works. If you add or remove from a page you left open, keep using that same tab — it rewrites its own URL with the new token — and do not go back to the older email. An expired one shows Link no longer valid: “This management link has expired or was already used elsewhere. Use the link from your most recent alert email.”

Unsubscribing

There are three ways out, and two of them are all-or-nothing.

Your mail client's Unsubscribe button. Both the confirmation email and the digest carry a standard one-click unsubscribe header, so Gmail and Outlook render their own Unsubscribe control. One click stops everything.
The Unsubscribe link in the email footer. It opens /alerts/unsubscribed and reports You're unsubscribed — “You won’t receive any more alert emails from Conterminal for any entity. You can subscribe again any time from a terminal, line, or vessel page.”
Unsubscribe from all alerts on the manage page. The button sits below the list and asks to confirm first: “Unsubscribe from all alerts? You can subscribe again anytime from a terminal, line, or vessel page.”

None of the three is per-entity. All of them stop every alert for that address, for every terminal, line, vessel, and company at once. To stop alerts for a single entity, use Remove on the manage page instead.

Clicking an unsubscribe link twice — or having your mail client prefetch it — reports the same success page rather than an error, which is intentional. Resubscribing later from any entity page reactivates the same address and does not make you confirm again if you already had; your previous subscription list survives, so check the manage page after resubscribing rather than assuming you are back to zero.

The per-address entity cap

One email address can follow 20 entities. That is a single pool shared across terminals, lines, vessels, and companies — not 20 of each. Subscribing to something you already follow is a no-op and does not consume a slot.

The limit surfaces with different wording depending on where you hit it. From an entity page's subscribe form: “That email has already reached the 20-entity alert limit. Manage subscriptions from the link in any alert email, or use a different address.” On the manage page the Add form is replaced entirely by Subscription limit reached — “You’ve reached the 20-entity limit. Remove one above to add a different entity.”

If you are at the cap and the only manage link you have is old, you are stuck: you cannot remove anything without a working manage link, and the subscribe form will keep rejecting you. Wait for the next digest to get a fresh link, or use a different address.

Rate limits

Every alerts action is throttled on a one-hour rolling window. All of them return “Too many requests. Please try again later.” from the server; the pages render it as Too many attempts with “Please wait a few minutes and reload this page.”

Action	Limit per hour	Counted by
Subscribe	20	Your connection
Subscribe	5	The email address you typed, from anywhere
Verify	20	Your connection
Manage (load, add, remove)	30	Your connection
Unsubscribe	30	Your connection

The five-per-hour email limit is what a shared office IP will hit first when several people subscribe the same distribution address.

Troubleshooting

“That email has already reached the 20-entity alert limit.”

The address follows 20 entities. Open the manage link from your most recent alert email and remove one, or subscribe a different address. Note that a mistyped slug added on the manage page still occupies a slot even though it produces no alerts — check the list for entries that do not look like real slugs.

“Too many requests from this connection. Try again in a few minutes.”

The subscribe endpoint allows 20 attempts per hour from one connection and 5 per hour for one email address, whichever you hit first. Wait it out. Repeated submissions do not queue and do not make the verification email arrive sooner.

“Too many attempts” on the verify, manage, or unsubscribe page

Same one-hour throttle, applied per connection: 20 for verify, 30 for manage, 30 for unsubscribe. Wait a few minutes and reload the page — do not open the link repeatedly, because each attempt counts.

A company alert link makes me sign in

Company alert subscriptions use signed-in relationship records, not the public carrier and forwarder directory profiles. Their alert and manage links point at /protected/companies/<slug>, so an unauthenticated click lands on the login page first. The destination is preserved, so signing in takes you straight to the company page. The public directory remains readable without an account, but it does not replace that signed-in alert destination.

I confirmed my email but no digest ever arrives

A digest is only sent when at least one of your entities changed during the window; a quiet day sends nothing. Confirm your list on the manage page first — a slug typo silently produces nothing forever. If your entities visibly changed on their public pages and you still got no email, contact support.

“Missing management link” or “Missing verification link”

You opened /alerts/manage or /alerts/verify without the token that has to be in the URL. These pages cannot look you up by address. Go back to the alert email and click the link rather than typing the address by hand, and do not truncate the query string when copying it.

“This management link has expired or was already used elsewhere.”

The manage token rotates on every add and remove, so an older email's link stops working as soon as you make a change. Use the link from your most recent alert email. If you have not received one since, you have no working link until the next digest.

The terminal page has no email-alert form

You are on a directory reference profile rather than a curated operational profile. Those pages carry facility codes and official links but no subscribe form. You can still follow the terminal by adding its slug on the manage page, if you already have a working manage link from another subscription.

The acceptance grid looks wrong or has not moved

Check the As of timestamp and look for the overdue-refresh line above the table. A stale grid keeps showing its last known statuses. Empty-return acceptance changes daily — confirm same-day with the terminal or the steamship line before dispatching a driver, regardless of what the grid says.

“Couldn't reach the alerts service. Please try again later.”

The request never completed — a network problem or a service outage, not a rejected subscription. Nothing was recorded, so retrying is safe once you have a connection again.