Asks the shipping line about this shipment now, bypassing our stored answer, and waits for it within a timeout (25 seconds by default). The response is the same detail GET /v1/containers/{id} returns, plus a refresh block saying what happened. When the line answered in time, refresh.refreshed is true, refresh.from_cache is false and refresh.updated_at is the time of that answer. When it did not, the detail is the last answer we hold, refresh.from_cache is true and refresh.reason says why (line_timeout, line_no_answer, refresh_failed); on a timeout the ask keeps running and refresh.refreshing_in_background is true, so a later GET serves its answer.

Limit: one force update per shipment per API key every 5 minutes (per signed-in user on the dashboard). The limit is shared with compat force_update for the same key and reference. Beyond it the answer is 429 with a Retry-After header and error.retry_after in seconds.

Scope: requires a read_write key, like every POST. A read-only key is refused with 403.

Billing: metered as one ordinary tracking call. It never counts the shipment a second time towards the unique-shipment allowance.

{id} is the container id, or a container, bill of lading or booking number the account tracks. An archived shipment is not refreshed (409): restore it first.