tiktok/post — one video by its URL, with the four counters

The call

Parameters (1)

That list is the whole list, and anything else is ignored in silence. An undeclared parameter is not rejected — it produces no error, no warning and no filtering. Check a parameter against this table before assuming a narrower result came back.

What the parameter list does not tell you

THE PARAMETER IS `url`, AND THAT IS THE POINT. You do not need to resolve a handle, find a video id or page a profile first: you paste the link you already have. Same contract as `bluesky/post` — one document, identified by the document, not by the account that published it.

⚠️ THE COUNTERS ARE ROUNDED UPSTREAM, AND NOT BY US. A real call on 4 October 2026 returned likes of exactly 2,000,000 and views of exactly 5,500,000. Those are not our numbers and they are not coincidences: TikTok's public page serves `2M` and `5.5M`, and a rounded figure parsed into an integer looks precise while carrying as much as half a million of error. Do not compute a ratio from them and do not diff two readings to infer growth — the difference you would be measuring is the rounding step, not the audience. For an exact count on this platform there is no route, here or anywhere, because the platform does not publish one.

The envelope is the shared one: `author`, `items`, `has_more` and `next_cursor`. For a single video `items` holds one entry and `has_more` is false — the shape does not change just because the answer is one row, which is what makes the same client code read a post and a profile's feed.

`metrics` on the item carries the four counters. Where a counter is absent from the upstream page it is absent here too, not zero. That distinction is the contract of this API and it is the difference between 'we did not read it' and 'nobody did it'.

Why there is no success body on this page

The 200 body for this endpoint is not transcribed here. Reading it needs a client key, and there is no client key on the machine these pages were built from — internal keys exist only as hashes, by design. An example we never received would look exactly like one we did, so instead of composing one, the response shape is documented field by field on the schema pages below. Those are generated from the contract and tested against it in both directions; an invented example would be tested by nothing.

Response shapes (4)

• PostItem — The normalised post shape. `metrics` carries likes, replies, reposts and quotes — and nothing else, because nothing else exists on every platform we read.
• PostsEnvelope — Every posts endpoint answers with this envelope. Eight fields, all required: you can read `success` and `credits_used` without checking whether they came.
• Author — The normalised profile shape, identical across all platforms. All twelve fields are nullable, and that is the design: a field we cannot read comes back null, never 0, because a zero would be a claim about the account.
• ApiError — Every 4xx and 5xx from the API carries this object. The `error` value is a stable string you can branch on; the extra fields appear only for the errors that have something to report.

Error codes (8)

Every one of them carries the same body shape: ApiError. The error value is a stable string you can branch on — branch on that, never on the message text.

400 · 401 · 402 · 404 · 405 · 451 · 503 · 502

Machine-readable

This endpoint is in /openapi.json (OpenAPI 3.1), with its cost on the operation itself. If you are generating a client, use the spec rather than this page — and note that the spec is filtered by what is switched on right now, so it is the better answer to "can I call this today".