---
title: "Feature detail batch (lazy-loaded)"
method: POST
path: "/features/details/batch"
tags: ["features"]
---

# Feature detail batch (lazy-loaded)

`POST /features/details/batch`

Fan-out variant of `/features/{id}/details` for callers that need to
resolve many features at once. POST is used so the id list isn't
constrained by URL length.

Per-id caching is identical to the single endpoint (Redis-backed
keyed on the id), so a batch that's a superset of previously
requested ids costs nothing extra for the overlap. Partial success
is preserved: a single failed upstream fetch sets `cache: "error"`
with an `error` string on that entry without failing the whole
request — or `cache: "error-cached"` when a recent failure was replayed
from the negative cache instead of calling the source again. Missing
ids land in the response with `not_found: true`.

A large batch against cold caches can run out of the request's time
budget before every id has been tried. The response array is positional,
so the ids that were never attempted come back with
`cache: "skipped"` and an `error` saying so, rather than as blanks. This
one is worth retrying — unlike `error-cached`, nothing has failed and a
smaller batch will resolve them. Entries already resolved in the same
response are unaffected, and their detail is cached, so the retry only
pays for what is left.

Bounded by the plan's `max_batch_size`, and by a system ceiling of 500
ids per request that applies to every caller.

## Request body

- object
  - `ids` string[], required

## Response `200`

Per-id detail results (one entry per requested id, in order)

## Other responses

- `400` — Invalid JSON body or empty ids array
- `403` — Batch exceeds plan's max_batch_size

---

[API](https://skmtc.net/road511/apis/road511-traffic-api.md) · [All operations](https://skmtc.net/road511/apis/road511-traffic-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/road511/road511-traffic-api/revisions/92944ef90bfd/schema)