What HDB’s Carpark API Can Tell You, and What It Cannot

HDB’s carpark availability API reports a timestamped count, not a parking promise. In a full snapshot at 6:43am Singapore time on 3 September 2026, the feed contained 2,024 carpark records. Seventy-nine of the 2,003 records reporting car lots showed zero car lots available. By arrival, every count may have changed.

Little Big Red Dot fetched the official HDB Carpark Availability dataset and validated total and available fields by lot type. The snapshot is reproducible from the saved API response and its timestamp. It should not be interpreted as a forecast of the next hour.

What the four core fields mean

Field Meaning Common mistake
carpark_number The identifier for the carpark record Treating it as a street address
update_datetime When that carpark’s availability was updated Using only the response timestamp
total_lots Reported capacity for that lot type Adding different lot types as interchangeable spaces
lots_available Reported available count for that lot type at update time Assuming a space is reserved for the reader

Lot type matters. In the snapshot, C represented car lots, Y motorcycle lots and H heavy-vehicle lots. An app should label the type instead of displaying one combined number.

What the national snapshot contained

Lot type Reporting records Total lots Available lots Zero-availability records
Car (C) 2,003 707,437 385,059 79
Motorcycle (Y) 208 18,030 11,966 27
Heavy vehicle (H) 210 661 67 196

These are sums across the feed, not a statement that all spaces are publicly interchangeable or available on identical terms. One invalid lot record was excluded from the aggregation because its available count exceeded its reported total.

Freshness is per carpark

The overall API item carried a timestamp of 6:43:37am. Individual carpark records had their own update times. When the file was fetched at 6:45am, 243 carpark records were more than 15 minutes old. A responsible app should display or evaluate the carpark-level age rather than stamping every record “live” from the outer response.

A stale count is not automatically wrong, but its uncertainty is higher. If a carpark is near capacity and the update is old, treat the information as weak.

A driver decision tree

  1. Select the exact carpark identifier, not only a neighbourhood name.
  2. Choose the needed lot type.
  3. Read the carpark’s update time.
  4. If availability is zero, choose another carpark before driving there.
  5. If availability is low or stale, keep a nearby fallback.
  6. Check rates, opening hours, height and season-parking restrictions elsewhere.

The API answers “what did this system last report?” It does not answer “will a visitor be admitted when they arrive?”

What the API does not contain

  • A reservation or guaranteed space
  • A forecast of departures and arrivals
  • Complete pricing and grace-period rules
  • Vehicle-height or charging restrictions
  • Walking accessibility to the reader’s destination
  • An explanation for a delayed sensor or invalid record

Use separate authoritative sources for those questions. The data.gov.sg API guide explains the dataset access patterns; it does not turn a snapshot into a service guarantee.

For developers: fail visibly

Validate that available lots are numeric, non-negative and not greater than total lots. Preserve the source timestamp and individual update time. If parsing fails, show “unavailable” rather than zero; zero means a valid report of no available lots, which is a different state.

Cache carefully and label the age. Avoid hammering the endpoint. Store the source URL and schema assumptions with the application so field changes can be diagnosed.

What other public datasets teach

Our MRT station-exits dataset guide shows why an identifier and coordinates still need real-world interpretation. The sports-facilities dataset analysis makes the same distinction between a listed place and a currently usable service.

The honest display

Show the carpark, lot type, available count and age together. Add a fallback when the number is low. The API is valuable because it narrows uncertainty; it becomes misleading only when an app hides the timestamp or promises a space it cannot reserve.

Calculate a freshness flag

For each carpark, subtract update_datetime from the current Singapore time. Display the result in minutes. Choose a threshold appropriate to the application and label older records “stale” rather than silently discarding them or presenting them as current.

The 15-minute flag in our analysis is an editorial diagnostic, not an HDB service standard. A developer should justify its own threshold and test how the interface behaves when the clock, time zone or timestamp is missing.

Do not aggregate away scarcity

Adding 50 available lots at one carpark to zero at another creates a neighbourhood total that may not help a driver near the full facility. Preserve individual identifiers and walking context. If an app shows an area summary, let the user open the contributing records.

Validation table

Condition Display state
Valid fresh numeric record Show count and age
Valid zero Show “0 available”, not unavailable
Available exceeds total Flag invalid and withhold count
Fetch or parse failure Show data unavailable
Old update Show count with stale warning

Accessibility and destination fit

The nearest available carpark may not have the best sheltered or step-free path. Combine availability only with authoritative location and access data, and state the limitation when a route has not been verified.

Archive a test snapshot

Keep a small, privacy-safe response fixture for automated tests, including multiple lot types, zero availability, a stale timestamp and an invalid row. Do not use a live API as the only test dependency. The production interface should still show the current source timestamp.

Use the lot-type field

Do not add car, heavy-vehicle and motorcycle rows into one availability number. Preserve the lot type and show only the user’s relevant class. A carpark with available motorcycle lots can still have zero car lots, so an unlabelled total can send a driver to the wrong conclusion.

Vanessa Koh
Vanessa Koh
Vanessa Koh is Little Big Red Dot's Tech & Auto Editor. She makes technology and cars accessible and practical for everyday readers. She translates specs into real-world value and tells you whether a new phone, laptop, smart device, or car is actually worth your attention and your money.

Latest articles

Related articles