---
title: "Strait of Malacca approaches - Singapore throughput (MPA)"
method: GET
path: "/api/v1/maritime/chokepoints/malacca/throughput"
tags: ["Global Economy & Trade"]
---

# Strait of Malacca approaches - Singapore throughput (MPA)

`GET /api/v1/maritime/chokepoints/malacca/throughput`

Vessel movements at Singapore from the Maritime and Port Authority of Singapore, updated hourly. Arrivals and departures cover the N hours BEFORE now; expected arrivals cover the N hours AFTER it, so each side publishes its own window bounds rather than sharing one. Singapore sits at the eastern end of the Strait of Malacca. The strait itself has three littoral states and no transit-authorising authority, so no operator count of it can exist; this port authority is the nearest state record. Read it as port throughput, not as strait transits. A side is published only when it was measured: if upstream returned nothing readable inside that side's window it is absent rather than zero. Count exactness and flag exactness are independent: a side whose records were not all readable or not all inside its window carries `count_lower_bound` instead of `count` and is left out of `total_movements`; a side whose counted movements include any with no readable flag carries `top_flags_lower_bound` instead of `top_flags`.

## Query parameters

- `hours` integer — Window length in hours. Realised sides look back from now, expected arrivals look forward from it (Singapore time).

## Response `200`

Singapore arrivals, departures and expected arrivals.

- EnvelopeMalaccaThroughputData
  - `data` MalaccaThroughputData, required — Singapore port throughput as the nearest state record for Malacca.
    - `port` string
    - `chokepoint_context` string, required — Which chokepoint this port speaks to, and how loosely.
    - `window_hours` integer, required — Length of each window.
    - `reference_time_sgt` string, required — The instant all three windows are anchored on, Singapore time, which is what MPA's API expects. NOT a window end: realised sides run backward from it and `due_to_arrive` runs forward, so the bounds live on each side rather than here.
    - `timezone` string
    - `arrivals` MovementSummary — One movement type over its own window. EXACTLY ONE OF `count` AND `count_lower_bound` IS PRESENT, and which one it is IS the statement about how well the side was read. `count` appears only when every record upstream returned was readable and fell inside the window; the moment anything was rejected or fell outside it, the readable subtotal is served as `count_lower_bound` and there is no `count` at all, so a consumer reaching for the number it quotes gets nothing rather than an undercount. `total_movements` is built from `count` fields only. THE FLAG BREAKDOWN IS A SECOND PREDICATE. Exactly one of `top_flags` and `top_flags_lower_bound` is present. Count exactness and flag exactness are independent: a side can publish exact `count` (every movement happened and was timed) beside `top_flags_lower_bound` when any counted movement had no readable flag. It used to be a single `top_flags` published unqualified on both kinds of side, so a consumer reading the distribution rather than the total got an exact-looking figure that omitted a vessel the same object had counted. `window_start_sgt` and `window_end_sgt` ARE THE BOUNDS THAT WERE ENFORCED, not a nearby description of them. A record whose `newest_timestamp_sgt` would fall outside them is counted under `out_of_window_records` instead, so no value inside this object can contradict the interval the same object declares. NOTE ON THIS MODEL'S ROLE. These routes return a prebuilt JSONResponse, which FastAPI passes through untouched, so `response_model` here does NOT filter or validate the payload - it declares the SCHEMA. A reviewer read a missing field as data being stripped at the wire; measured, the field was always served and it was the published schema that under-declared it. That is a smaller defect than reported and a real one still: `/openapi.json` is the contract consumers and our own generated clients read, and a response that describes itself incorrectly is the exact class this programme exists to remove. Nothing enforces the match, so the schema test is what holds it.
      - `count` integer, nullable — Vessel movements in the window. Present ONLY when the count is exact: every record upstream returned was readable and inside the window. Absent whenever `count_lower_bound` is present.
      - `count_lower_bound` integer, nullable — Readable in-window movements, when some records were NOT readable or NOT in the window. The true figure is at least this. Present instead of `count`, and never summed into `total_movements`.
      - `window_start_sgt` string, required — Start of the interval this side is measured over, Singapore time, and the exact bound records were tested against. Realised sides look backward from the reference instant and `due_to_arrive` looks forward, so each side carries its own.
      - `window_end_sgt` string, required — End of the interval this side is measured over, Singapore time, and the exact bound records were tested against.
      - `newest_timestamp_sgt` string, required — Most recent movement counted here, converted to Singapore time. Zone-bearing upstream values are converted, not relabelled. Always within [`window_start_sgt`, `window_end_sgt`]: a record outside them is not counted here and cannot date this side.
      - `top_flags` FlagCount[], nullable — Most frequent flags in the window, EXACT: every counted movement is in it. Absent whenever `top_flags_lower_bound` is present. NOTE that this is a SEPARATE claim from `count`, and a side can carry an exact count with a lower-bound breakdown: a movement whose flag is unreadable still happened, so it is counted, but it cannot be attributed and the distribution then does not contain it.
        - `flag` string, required — Vessel flag code as MPA reports it.
        - `vessels` integer, required — Vessels of that flag in the window. Exact: appears only inside `top_flags`, which is published only when the side carries an exact `count`.
      - `top_flags_lower_bound` FlagCountLowerBound[], nullable — Most frequent flags among the movements that could be ATTRIBUTED, published instead of `top_flags` whenever some record was not readable, not in the window, or carried no readable flag. A consumer reading the distribution is told what it cannot see.
        - `flag` string, required — Vessel flag code as MPA reports it.
        - `vessels_lower_bound` integer, required — Readable in-window vessels of that flag. The true figure is at least this. Present instead of `vessels`.
      - `movements_with_no_readable_flag` integer, nullable — Movements counted on this side that carry no readable flag, so they are absent from the breakdown above. Absent when there were none. This is why `count` and the flag distribution are two claims: a side with an exact count of 2 could publish an exact-looking breakdown naming one vessel, and the missing one's flag could also change the top-eight ordering.
      - `rejected_records` integer, nullable — Records upstream returned that carried no readable movement time. Absent when none were. A side with nothing readable inside its window is not reported as zero at all - it is absent, like any other failed side.
      - `out_of_window_records` integer, nullable — Readable records whose movement time fell OUTSIDE the window this side declares - the signal that the gateway ignored, clamped or over-ran the requested `hours`. Absent when none did.
    - `departures` MovementSummary — One movement type over its own window. EXACTLY ONE OF `count` AND `count_lower_bound` IS PRESENT, and which one it is IS the statement about how well the side was read. `count` appears only when every record upstream returned was readable and fell inside the window; the moment anything was rejected or fell outside it, the readable subtotal is served as `count_lower_bound` and there is no `count` at all, so a consumer reaching for the number it quotes gets nothing rather than an undercount. `total_movements` is built from `count` fields only. THE FLAG BREAKDOWN IS A SECOND PREDICATE. Exactly one of `top_flags` and `top_flags_lower_bound` is present. Count exactness and flag exactness are independent: a side can publish exact `count` (every movement happened and was timed) beside `top_flags_lower_bound` when any counted movement had no readable flag. It used to be a single `top_flags` published unqualified on both kinds of side, so a consumer reading the distribution rather than the total got an exact-looking figure that omitted a vessel the same object had counted. `window_start_sgt` and `window_end_sgt` ARE THE BOUNDS THAT WERE ENFORCED, not a nearby description of them. A record whose `newest_timestamp_sgt` would fall outside them is counted under `out_of_window_records` instead, so no value inside this object can contradict the interval the same object declares. NOTE ON THIS MODEL'S ROLE. These routes return a prebuilt JSONResponse, which FastAPI passes through untouched, so `response_model` here does NOT filter or validate the payload - it declares the SCHEMA. A reviewer read a missing field as data being stripped at the wire; measured, the field was always served and it was the published schema that under-declared it. That is a smaller defect than reported and a real one still: `/openapi.json` is the contract consumers and our own generated clients read, and a response that describes itself incorrectly is the exact class this programme exists to remove. Nothing enforces the match, so the schema test is what holds it.
      - `count` integer, nullable — Vessel movements in the window. Present ONLY when the count is exact: every record upstream returned was readable and inside the window. Absent whenever `count_lower_bound` is present.
      - `count_lower_bound` integer, nullable — Readable in-window movements, when some records were NOT readable or NOT in the window. The true figure is at least this. Present instead of `count`, and never summed into `total_movements`.
      - `window_start_sgt` string, required — Start of the interval this side is measured over, Singapore time, and the exact bound records were tested against. Realised sides look backward from the reference instant and `due_to_arrive` looks forward, so each side carries its own.
      - `window_end_sgt` string, required — End of the interval this side is measured over, Singapore time, and the exact bound records were tested against.
      - `newest_timestamp_sgt` string, required — Most recent movement counted here, converted to Singapore time. Zone-bearing upstream values are converted, not relabelled. Always within [`window_start_sgt`, `window_end_sgt`]: a record outside them is not counted here and cannot date this side.
      - `top_flags` FlagCount[], nullable — Most frequent flags in the window, EXACT: every counted movement is in it. Absent whenever `top_flags_lower_bound` is present. NOTE that this is a SEPARATE claim from `count`, and a side can carry an exact count with a lower-bound breakdown: a movement whose flag is unreadable still happened, so it is counted, but it cannot be attributed and the distribution then does not contain it.
        - `flag` string, required — Vessel flag code as MPA reports it.
        - `vessels` integer, required — Vessels of that flag in the window. Exact: appears only inside `top_flags`, which is published only when the side carries an exact `count`.
      - `top_flags_lower_bound` FlagCountLowerBound[], nullable — Most frequent flags among the movements that could be ATTRIBUTED, published instead of `top_flags` whenever some record was not readable, not in the window, or carried no readable flag. A consumer reading the distribution is told what it cannot see.
        - `flag` string, required — Vessel flag code as MPA reports it.
        - `vessels_lower_bound` integer, required — Readable in-window vessels of that flag. The true figure is at least this. Present instead of `vessels`.
      - `movements_with_no_readable_flag` integer, nullable — Movements counted on this side that carry no readable flag, so they are absent from the breakdown above. Absent when there were none. This is why `count` and the flag distribution are two claims: a side with an exact count of 2 could publish an exact-looking breakdown naming one vessel, and the missing one's flag could also change the top-eight ordering.
      - `rejected_records` integer, nullable — Records upstream returned that carried no readable movement time. Absent when none were. A side with nothing readable inside its window is not reported as zero at all - it is absent, like any other failed side.
      - `out_of_window_records` integer, nullable — Readable records whose movement time fell OUTSIDE the window this side declares - the signal that the gateway ignored, clamped or over-ran the requested `hours`. Absent when none did.
    - `due_to_arrive` MovementSummary — One movement type over its own window. EXACTLY ONE OF `count` AND `count_lower_bound` IS PRESENT, and which one it is IS the statement about how well the side was read. `count` appears only when every record upstream returned was readable and fell inside the window; the moment anything was rejected or fell outside it, the readable subtotal is served as `count_lower_bound` and there is no `count` at all, so a consumer reaching for the number it quotes gets nothing rather than an undercount. `total_movements` is built from `count` fields only. THE FLAG BREAKDOWN IS A SECOND PREDICATE. Exactly one of `top_flags` and `top_flags_lower_bound` is present. Count exactness and flag exactness are independent: a side can publish exact `count` (every movement happened and was timed) beside `top_flags_lower_bound` when any counted movement had no readable flag. It used to be a single `top_flags` published unqualified on both kinds of side, so a consumer reading the distribution rather than the total got an exact-looking figure that omitted a vessel the same object had counted. `window_start_sgt` and `window_end_sgt` ARE THE BOUNDS THAT WERE ENFORCED, not a nearby description of them. A record whose `newest_timestamp_sgt` would fall outside them is counted under `out_of_window_records` instead, so no value inside this object can contradict the interval the same object declares. NOTE ON THIS MODEL'S ROLE. These routes return a prebuilt JSONResponse, which FastAPI passes through untouched, so `response_model` here does NOT filter or validate the payload - it declares the SCHEMA. A reviewer read a missing field as data being stripped at the wire; measured, the field was always served and it was the published schema that under-declared it. That is a smaller defect than reported and a real one still: `/openapi.json` is the contract consumers and our own generated clients read, and a response that describes itself incorrectly is the exact class this programme exists to remove. Nothing enforces the match, so the schema test is what holds it.
      - `count` integer, nullable — Vessel movements in the window. Present ONLY when the count is exact: every record upstream returned was readable and inside the window. Absent whenever `count_lower_bound` is present.
      - `count_lower_bound` integer, nullable — Readable in-window movements, when some records were NOT readable or NOT in the window. The true figure is at least this. Present instead of `count`, and never summed into `total_movements`.
      - `window_start_sgt` string, required — Start of the interval this side is measured over, Singapore time, and the exact bound records were tested against. Realised sides look backward from the reference instant and `due_to_arrive` looks forward, so each side carries its own.
      - `window_end_sgt` string, required — End of the interval this side is measured over, Singapore time, and the exact bound records were tested against.
      - `newest_timestamp_sgt` string, required — Most recent movement counted here, converted to Singapore time. Zone-bearing upstream values are converted, not relabelled. Always within [`window_start_sgt`, `window_end_sgt`]: a record outside them is not counted here and cannot date this side.
      - `top_flags` FlagCount[], nullable — Most frequent flags in the window, EXACT: every counted movement is in it. Absent whenever `top_flags_lower_bound` is present. NOTE that this is a SEPARATE claim from `count`, and a side can carry an exact count with a lower-bound breakdown: a movement whose flag is unreadable still happened, so it is counted, but it cannot be attributed and the distribution then does not contain it.
        - `flag` string, required — Vessel flag code as MPA reports it.
        - `vessels` integer, required — Vessels of that flag in the window. Exact: appears only inside `top_flags`, which is published only when the side carries an exact `count`.
      - `top_flags_lower_bound` FlagCountLowerBound[], nullable — Most frequent flags among the movements that could be ATTRIBUTED, published instead of `top_flags` whenever some record was not readable, not in the window, or carried no readable flag. A consumer reading the distribution is told what it cannot see.
        - `flag` string, required — Vessel flag code as MPA reports it.
        - `vessels_lower_bound` integer, required — Readable in-window vessels of that flag. The true figure is at least this. Present instead of `vessels`.
      - `movements_with_no_readable_flag` integer, nullable — Movements counted on this side that carry no readable flag, so they are absent from the breakdown above. Absent when there were none. This is why `count` and the flag distribution are two claims: a side with an exact count of 2 could publish an exact-looking breakdown naming one vessel, and the missing one's flag could also change the top-eight ordering.
      - `rejected_records` integer, nullable — Records upstream returned that carried no readable movement time. Absent when none were. A side with nothing readable inside its window is not reported as zero at all - it is absent, like any other failed side.
      - `out_of_window_records` integer, nullable — Readable records whose movement time fell OUTSIDE the window this side declares - the signal that the gateway ignored, clamped or over-ran the requested `hours`. Absent when none did.
    - `total_movements` integer, nullable — Arrivals plus departures. Present only when BOTH realised sides carry an exact `count`; absent when either failed to load or returned a lower bound, because a total built from a lower bound would understate the port while looking authoritative.
    - `note` string, required — States what the figure is NOT. The Strait of Malacca has three littoral states and no transit-authorising authority, so no operator count of it exists; this is port throughput at Singapore, the nearest state record, and must not be read as strait transits.
  - `meta` SugraMeta, required — Metadata on a /api/v1/* response envelope built through `helpers.response.sugra_response`, which is how routes are expected to answer. A route that assembles its own `meta` dict carries only the keys it writes itself, so an optional field below can be absent because this response has nothing to report OR because that route does not build its envelope here - the two are not distinguishable from the outside (API-43).
    - `endpoint` string, required — Requested endpoint path.
    - `data_time` string, required — ISO 8601 timestamp the data on this response is stamped with. It is the source's own timestamp whenever the source supplied one this API could read; when it did not, this field falls back to the value of `response_time` and `data_age_days` is omitted, so the PRESENCE of that field is the signal to read - with the one exception named in its own description, a route that substitutes its own current time for a source timestamp it never received. Usually UTC (`Z`), but a source stating its own numeric offset keeps it (2026-04-16T14:30:00+09:00) rather than being converted a second time. For a source that publishes by period this is the period's START (see `period`) and for one that publishes by calendar day it is that day's midnight - in neither case a moment at which anything was observed or released.
    - `response_time` string, required — ISO 8601 UTC timestamp when this response was produced.
    - `provider` string, required — API name and version.
    - `data_age_days` number, nullable — Age of the data in days at the moment this response was produced, i.e. `response_time` minus `data_time`. Present ONLY when the timestamp this response is stamped with is a clock time that could be read as a real instant. It is ABSENT - never 0 - in every other case. Absent when no readable source timestamp was supplied, because `data_time` then repeats `response_time` and a zero age would assert that the data is current precisely where its true age is unknown. Absent when the source names a calendar day, a month, a quarter or a year (see `period`): the instant is then a boundary this API anchored at midnight, and time since a day or a quarter BEGAN is a different quantity from the age of the data - a daily series is out by up to a day, a quarterly one by up to a quarter. A midnight counts as such a boundary whichever zone it is stated in, and whether the source stated it or this API anchored it. The one case this field cannot see is a route that substitutes its own current time for a source timestamp it never received: the substituted value is a real, readable instant and is indistinguishable from one the source stated, so the age reads as roughly 0. The shared cache-and-fetch helper behind most routes stopped doing that (API-43), but the presence of this field is a statement about the timestamp the response carries, not a guarantee about the route that supplied it. Rounded to 0.001 day (86.4 seconds), so 0.0 is a real measured age anywhere within roughly +/-43 seconds and not a stand-in for unknown; a source stamping an instant in the future reports a negative value (-0.001 or less) rather than being clamped. Sources publish on very different cadences, so a non-zero age is normal, not an error. Preserve absence in client code: a generated client that materialises a missing optional number as its numeric default turns 'age unknown' back into 'age zero', which is the exact confusion this field exists to remove.
    - `source` string, nullable — Identifier of the primary upstream source used for this response.
    - `attribution` string, nullable — Human-readable attribution mandated by an upstream source (e.g. a securities regulator or self-regulatory organization). Present only on responses whose source requires the owner and source to be clearly identified. Do not remove or alter it when using the response.
    - `fallback_used` boolean, nullable — True when the primary source failed and a fallback produced the data.
    - `fallback_chain` string[], nullable — Ordered list of sources attempted, in the order they were tried.
    - `cached` boolean, nullable — True when this response was served from the internal cache.
    - `stale` boolean, nullable — True when the cached response was returned after the upstream rate-limited or errored. Clients can use this to detect degraded data.
    - `period` string, nullable — Unit of observation, when the source publishes by period rather than by instant. `data_time` carries the period's START instant so it stays machine-readable; this field preserves what that instant used to mean, which the conversion would otherwise erase. Present only for such sources, and only when the source hands the API the label itself - a client that converts the period to its start instant before building the envelope loses the label, though not the age exclusion, which is decided by the instant. Note that `data_age_days` is omitted whenever this is present, because an age measured from a period start is not a freshness figure.
    - `notes` string, nullable — Data-quality caveat about THIS response - how old the underlying report is, a chokepoint AIS lower-bound, or that a source-reported `data_time` could not be read and the response time is shown instead. Distinct from `attribution`, which is a licensing obligation. Multiple caveats are joined with ' | '. Present only when there is one.

## Other responses

- `401` — Missing or invalid `x-api-key` header. JSON body with a stable `code` distinguishing `missing_api_key` (no header sent) from `invalid_api_key` (header sent, key not accepted); any other 401 source carries the generic `unauthorized` with its detail as `reason`. Plus `hint`. `plan` is always null on 401 - an unauthenticated request has no plan; quota exhaustion is 429, not 401.
- `422` — Validation Error
- `429` — Daily rate limit exceeded. Check `X-RateLimit-Reset` for the next window.
- `503` — Upstream source is temporarily unavailable. Retry after a short delay.

## Changes

- **2026-09-01** `85caa556892f` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/sugra/apis/sugra-api/changes/api/v1/maritime/chokepoints/malacca/throughput/get.md)

---

[API](https://skmtc.dev/sugra/apis/sugra-api.md) · [All operations](https://skmtc.dev/sugra/apis/sugra-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/sugra/sugra-api/revisions/cdcc60731935/schema)