@volter/twin-tiktok 0.1.37 → 1.0.0

package/README.md

@@ -1,310 +1,27 @@
 # @volter/twin-tiktok
 
-A local, stateful, vendor-faithful twin of **TikTok's Login Kit, Display API and Content Posting
-API** — the tiktok.com authorization page, the full OAuth round trip (token, refresh, revoke,
-client_credentials), `GET /v2/user/info/` + `POST /v2/video/list/` + `POST /v2/video/query/`
-with TikTok's real field selection, scope gating and error envelopes, and a creator's video posted
-the way TikTok takes it: `creator_info`, the Direct Post and inbox inits, the chunked `PUT` to a
-signed upload URL, and `status/fetch` walking the publish by World time.
-
-**First, register your app.** TikTok publishes no API that creates a developer app, so the twin
-cannot guess your `client_key`: a world must `POST /_twin/clients` with the key, secret and
-redirect URI its application uses *before* the authorize leg will answer anything but
-`invalid_client`. That one seeding call is the whole setup — after it, point an unmodified TikTok
-integration at the twin and complete a sign-in-with-TikTok flow offline.
-
-```bash
-curl -X POST "$TIKTOK_TWIN/_twin/clients" -H 'content-type: application/json' \
-  -d '{"client_key":"'"$TIKTOK_CLIENT_ID"'","client_secret":"'"$TIKTOK_CLIENT_SECRET"'",
-       "name":"My App","redirect_uris":["https://my.app/api/auth/callback/tiktok"]}'
-```
-
-```bash
-bun run packages/twin/tiktok/src/cli.ts mirror
-# tiktok twin (Login Kit OAuth + Display API) at http://127.0.0.1:54321
-# authorization page: http://127.0.0.1:54321/v2/auth/authorize?client_key=…
-```
-
-## Five things this vendor does that its OAuth siblings do not
-
-This pack exists next to `googleoauth` and `xidentity` because TikTok's protocol differs from both
-in ways that break code copied from either:
-
-1. **Scopes are COMMA-separated** (`scope=user.info.basic,user.info.profile`), not space-separated.
-   A space-separated string is one unknown scope here, and the twin refuses it as `invalid_scope`.
-2. **Consent is GRANULAR.** The documented callback carries a `scopes` parameter — "the
-   authorization scope(s) which the user has granted" — so the granted set may be a SUBSET of what
-   was requested. The authorization page this twin serves offers a checkbox per requested scope,
-   and unchecking one narrows the token and makes the Display API refuse the field that scope gated.
-3. **PKCE is OPTIONAL, and its challenge is HEX SHA-256.** TikTok requires PKCE for desktop apps
-   only (web apps, Dub included, send none), and when it is used the `code_challenge` is the
-   64-character hex digest — *not* RFC 7636's base64url. A helper copied from an X or Google
-   integration produces a challenge the real vendor rejects, and so does this twin.
-4. **The client authenticates in the BODY.** `client_key` + `client_secret` form fields; TikTok
-   documents no HTTP Basic alternative, so an `Authorization` header on the token endpoint is
-   ignored rather than honoured. (Dub sends one — its callback route is shared with a Basic-auth
-   provider — and the exchange must still succeed.)
-5. **`open_id` is PER APP, `union_id` is per human.** The same account authorizing two apps yields
-   two different `open_id`s and one `union_id`, and re-authorizing the same app yields the SAME
-   `open_id`. An app that keys its user records on `open_id` must not see a new person each login.
-
-There are **two error envelopes**, not one: the OAuth endpoints answer the flat
-`{error, error_description, log_id}` body and the v2 API answers the nested
-`{data, error:{code, message, log_id}}` one — which is present on SUCCESS too, with
-`code: "ok"`. The `log_id` is deterministic here (14 digits of UTC `yyyyMMddHHmmss` plus 20
-uppercase hex, the vendor's own shape), because a served byte may not carry a clock or entropy.
-
-It is a **browser-facing protocol pack** (the `googleoauth` class): the authorization page is
-served as HTML at the vendor's real path (`https://www.tiktok.com/v2/auth/authorize`),
-server-rendered from the twin's own kernel projection by the **same React components** the pack
-ships — one renderer, so API↔UI parity cannot drift. The whole decision is a plain `<form>` with a
-checkbox per scope and two submit buttons, so **no JavaScript is required to complete an OAuth
-round trip** against this twin: the pack ships no browser bundle, the stylesheet is inlined, and
-`curl`, redirect-following HTTP libraries and headless browsers all behave identically.
-
-## Posting a video
-
-The Content Posting API as its references describe it (developers.tiktok.com, fetched
-2026-09-27), driven with nothing but `curl`:
-
-```bash
-# a creator and a token that may post (the twin's own doors: TikTok has no API for either)
-curl -X POST "$TIKTOK_TWIN/_twin/accounts" -H 'content-type: application/json' \
-  -d '{"union_id":"11111111-2222-4333-8444-555555555555","username":"volter","display_name":"Volter"}'
-curl -X POST "$TIKTOK_TWIN/_twin/tokens" -H 'content-type: application/json' \
-  -d '{"union_id":"11111111-2222-4333-8444-555555555555","scopes":["user.info.basic","user.info.stats","video.list","video.publish"]}'
-
-curl -X POST "$TIKTOK_TWIN/v2/post/publish/creator_info/query/" -H "Authorization: Bearer $TOKEN"
-curl -X POST "$TIKTOK_TWIN/v2/post/publish/video/init/" -H "Authorization: Bearer $TOKEN" \
-  -H 'content-type: application/json; charset=UTF-8' \
-  -d '{"post_info":{"title":"Release #volter","privacy_level":"PUBLIC_TO_EVERYONE"},
-       "source_info":{"source":"FILE_UPLOAD","video_size":14904527,"chunk_size":5242880,"total_chunk_count":2}}'
-# → {"data":{"publish_id":"v_pub_file~v2-1.…","upload_url":"$TIKTOK_TWIN/video/?upload_id=…&upload_token=…"}, …}
-curl -X PUT "$UPLOAD_URL" -H 'Content-Type: video/mp4' -H 'Content-Range: bytes 0-5242879/14904527' --data-binary @chunk1  # 206
-curl -X PUT "$UPLOAD_URL" -H 'Content-Type: video/mp4' -H 'Content-Range: bytes 5242880-14904526/14904527' --data-binary @chunk2  # 201
-curl -X POST "$TIKTOK_TWIN/v2/post/publish/status/fetch/" -H "Authorization: Bearer $TOKEN" -d '{"publish_id":"…"}'
-# → PROCESSING_UPLOAD, then PUBLISH_COMPLETE with "publicaly_available_post_id":[7063961975802954486]
-```
-
-- **The chunk rules are TikTok's**: a video under 5 MB is one whole chunk; chunks are 5–64 MB;
-  `total_chunk_count` is `video_size / chunk_size` rounded down, the final chunk carrying the rest
-  (up to 128 MB); a video over 64 MB takes more than one chunk; at most 1000 chunks and 4 GB. Chunks
-  go in order: out of order is 416, a size that disagrees with the plan is 400, and each chunk answers
-  206 until the last answers 201. **The twin's own limit is lower, and says so**: it holds a video
-  whole when the last chunk lands (the kernel's blob seam stores bytes, not a stream), so an init
-  over 512 MiB is refused with `invalid_param` naming that limit.
-- **`privacy_level` is the creator's choice from creator_info**: missing, or not one of their
-  `privacy_level_options`, is `privacy_level_option_mismatch` (403).
-- **The upload URL is signed, not looked up.** Like TikTok's, it is a different address from the
-  API — `/video/` under the twin's public base, or `https://open-upload.tiktokapis.com/video/` when
-  the request came through a World's injector naming `open.tiktokapis.com` (the pack claims that
-  host, so the PUT routes back here) — and its `upload_token` is an HMAC over the upload and its
-  expiry, keyed by that upload's own secret drawn from entropy at init. The PUT carries no bearer; a
-  token altered by a character is 403, and so is the URL after its hour. Publish ids, upload ids and
-  post ids are drawn from entropy too, so a World cloned from another never reissues the origin's.
-- **The lifecycle is World time**: `PROCESSING_UPLOAD` while chunks arrive and for the twin's
-  processing interval after (2 s plus 1 s per 10 MiB — TikTok publishes none), then
-  `PUBLISH_COMPLETE` (or `SEND_TO_USER_INBOX` for an inbox upload, which posts nothing to the
-  profile). The Direct Post appears in `/v2/video/list/` from that instant. What TikTok's
-  processing checks and the file's own headers can show fails the publish (`FAILED`, nothing
-  posted): bytes that are no readable video (`file_format_check_failed`), longer than the creator's
-  maximum (`duration_check_failed`), outside 23–60 FPS (`frame_rate_check_failed`) or outside
-  360–4096 px (`picture_size_check_failed`). `publicaly_available_post_id`
-  is written as bare int64 JSON numbers, as TikTok writes them — so a client that `JSON.parse`s a
-  19-digit id into a double loses digits here, not in production.
-- **Each endpoint meters its own minute** at its reference's figure: creator_info 20, the inits 6,
-  status/fetch 30, per user token.
-- **The bytes are the bytes.** Chunks are staged one key each and joined once, when the last lands;
-  the video is stored content-addressed on the kernel's blob seam and read back through its
-  resource-blob helpers, so a branch plays its ancestors' posts. `GET /_twin/media/video/<post id>`
-  (under the twin's public base) serves it with Range — 206, 416 past the end, an open-ended range
-  capped at 8 MiB, an inverted range ignored as RFC 9110 says (200) — and a post that is not
-  `PUBLIC_TO_EVERYONE` plays only with its creator's `access_token`.
-- **No credential is kept in the clear.** Access, refresh and client tokens, authorization codes
-  and rate windows are the twin's `_`-prefixed bookkeeping (never deployed, never pushed), each keyed
-  by the SHA-256 of its credential; an app's client secret, a publish's token and an upload's token
-  are kept as hashes; an upload's signing secret is its own. An app registered through
-  `/_twin/clients` without a secret gets one drawn from entropy, answered once. A presented credential is hashed and
-  looked up.
-
-The one kernel write is the finalize: `video.publish` (the video on the profile, and its `publish`
-row) or `video.inbox_upload`. Staging is never a kernel action, so an abandoned upload leaves nothing
-for a deploy to trip on. **Deploying** that entry to a real TikTok root performs the same flow
-against the vendor (see *The three operations*).
-
-## The mirror: tiktok.com over the twin's state
-
-A creator posts and reads their profile on tiktok.com, so the pack ships tiktok.com's view of what
-was posted — a React app over the twin's own Display API, on the twin's origin:
-
-```bash
-bun run packages/twin/tiktok/src/cli.ts mirror
-# mirror (tiktok.com profile + player): http://127.0.0.1:54321/
-```
-
-- **Log in** as tiktok.com's form asks — the username, then, in place of the password, the access
-  token the twin issued for that creator (`POST /_twin/tokens`). A token for another account is
-  refused on the form; both stay in the tab's sessionStorage.
-- **The profile**: the avatar (the creator's initial — the twin holds no image), `@username` with the
-  verified tick, the nickname, Following / Followers / Likes **only as `/v2/user/info/` returns them**
-  (a token without `user.info.stats` or a persona seeded without counts draws none), the bio, and the
-  Videos tab's 9:16 grid of the creator's posts, newest first, each tile the post's own first frame
-  and its play count.
-- **The player**: a post opens full height and vertical, playing its bytes from
-  `/_twin/media/video/<id>` (Range, the creator's token on the URL) over a blurred copy of itself,
-  with the `@handle`, the caption and its hashtags, the sound line, the action rail carrying the
-  Video Object's own like/comment/share counts, and up/down to the neighbouring posts.
-
-Inside a World it is mounted at `/<org>/<world>/tiktok/mirror/`: the shell (`tiktokMirrorHtml`) has
-`<base href="/">` and relative `assets/`, the client (`buildTiktokMirrorClient`) routes on `#/`, and
-its reads go to the keyed wire with the browser's World session.
-
-## Coverage
-
-Partial and honest. The manifest (`src/tiktok-capabilities.ts`) is the **Login Kit + Display API +
-Content Posting** denominator — the surface a user access token reaches — and it also carries
-TikTok's other open-platform products (Research, Data Portability, Local Services, the mobile/QR
-login variants, the photo post) and the separate business-api.tiktok.com Ads API as honest `todo`s
-rather than silent omissions.
-
-It currently reads **142 done / 218 covered** (76 `todo`, across 25 areas) — and the percentage is
-flattering, so here is the magnitude of what discounts it, measured rather than hand-waved:
-
-- **The eleven endpoints this pack serves are enumerated per BEHAVIOUR** (a parameter honoured, an
-  error produced, a field gated) — the six Login Kit + Display endpoints at about 19 rows apiece,
-  Content Posting at 14 `done` plus 8 pinning/model `todo`s — **while the product families it does
-  not serve are enumerated per OPERATION FAMILY**, about 3 rows apiece. Modelling one of them would
-  add a `done` per behaviour where a few `todo`s sit today.
-- **16 of the 142 `done` rows never issue a request at the twin's wire at all**: three compare the
-  twin's copy of TikTok's published error/scope tables against a literal, twelve drive the
-  connector's pricing, mapping and budget over injected executors, and one checks the mirror
-  module's exports build. They are real claims, but they say nothing about what the served HTTP
-  surface does.
-- **25 of the 142 assert an HTTP status on the flat OAuth envelope that TikTok publishes no status
-  column for.** Its error reference lists the ten `error` values and their descriptions and stops
-  there; the twin answers RFC 6749 §5.2's 400/401, and `tiktok.token.error_http_status` is the
-  `todo` that pins the live ones. If the vendor turns out to answer 200 with an error body — as
-  some OAuth implementations do — those 25 rows are asserting the wrong half of the wire.
-
-The honest correction is to expand the unserved families as each is read from its own reference,
-and to close the pinning `todo`s against the live vendor — never to pad the denominator now with
-rows nobody has read the docs for.
-
-### No first-party spec — the denominator is hand-authored
-
-TikTok publishes **no** machine-readable specification for the open API: no OpenAPI, no SDL, no
-Discovery document. Its reference material is prose, curl examples and hand-written tables, and its
-one first-party generated SDK (`tiktok-business-api-sdk`) speaks the *Business/Ads* API on a
-different host. So the denominator was authored top-down from the published references, all fetched
-**2026-09-13**, and every capability cites the one that grounds it: Login Kit for Web and for
-Desktop; User Access Token Management and Client Access Token Management; the Scopes Overview; Get
-User Info; the Video Object / Video List / Video Query references; the OAuth and API-v2
-error-handling references; and the rate-limit reference. `census.json`'s `spec` slice records that
-trail in full.
-
-The `todo`s are real TikTok surface this twin does not model — most notably the **photo post** and
-**PULL_FROM_URL** (both need the developer portal's verified domains), the **webhook events page** (`authorization.removed`
-with its reason enum, `video.publish.completed`, `video.upload.failed`,
-`portability.download.ready`, and delivery/signature itself), the public unauthenticated
-**oEmbed** read, **Share Kit**, the **Research API**, **Data Portability**, the **Mini Games /
-Mini Dramas / TikTok GO** product families, and the **Business/Ads API** — plus a family of
-**wire-pinning todos**: behaviours
-the twin models from RFC 6749/7009 or from a widely-reported capture because no fetched official
-artefact states them (the HTTP status of an OAuth failure, the authorization-code format and
-lifetime, whether the live vendor always rotates a refresh token, the authorize error page, the
-live consent sheet's affordances, the dimension the 600/minute limit is enforced on). Each such
-`done` names its evidence boundary in the manifest and its pinning `todo`.
-
-### What is real here
-
-- **The complete round trip.** Authorize request → authorization page → 302 to `redirect_uri` with
-  exactly `code`, `scopes` and `state` (the documented callback parameters) → the code is
-  redeemable **exactly once** → `refresh_token` grant (rotating) → revoke kills the whole (app,
-  user) grant. One pack against one state root, so the code minted at the screen is honoured at the
-  token endpoint by construction.
-- **`disable_auto_auth`**, modelled: with `0` and an existing grant covering the request, the page
-  is skipped and a code bounces straight back; a first authorization or a widened scope set still
-  shows it. The default (parameter absent) shows the page — bypassing the human leg is the thing
-  this pack exists to make visible.
-- **Exact callback matching** — a trailing-slash variant is a different Redirect URI, so
-  `redirect_uri`-mismatch bugs reproduce, on the vendor's own error page, with the app never
-  reached.
-- **The Display API reads** — `fields` selection over the documented 14 user fields and 16 video
-  fields, per-scope field gating (`scope_not_authorized`, 401), `max_count` defaulting to 10 and
-  capped at 20, millisecond cursor pagination, the 20-id query limit, and a foreign video id
-  omitted rather than 404'd.
-- **The documented rate limit** — a one-minute sliding window at 600, enforced separately per
-  endpoint, answering HTTP 429 with `rate_limit_exceeded`. TikTok publishes no rate-limit response
-  headers, so the twin invents none.
-- **Vendor-shaped opaque credentials** — `act.` / `rft.` / `clt.` prefixes, and an authorization
-  code carrying the characters that make the documented "URL decoded" requirement observable: the
-  raw callback text does not redeem, the decoded one does.
-- **Fidelity over real transport** — `tiktok-sdk.integration.test.ts` drives the twin through a
-  socket with the exact calls Dub's unmodified source makes (TikTok publishes no official npm
-  client, so ADDING_A_TWIN.md §10's real-transport `fetch` alternative applies).
-
-### What is not
-
-The twin **authenticates nobody**: no password, no 2FA, no risk engine. The tiktok.com "signed in"
-session is a seeded persona row — `POST /_twin/session` switches it, which is the honest local
-equivalent of "the browser is already signed in". There is also no TikTok API that creates a
-developer app, so a world running a real integration registers its own `client_key` through
-`POST /_twin/clients`; the seeded `Twin Demo App` is a convenience, not a claim.
-
-### Twin-only scaffolding (not vendor surface, not counted)
-
-`GET /_twin/consent` (re-render a pending authorization page by request handle) and
-`POST /_twin/consent` (the Continue/Cancel form post — TikTok's real sheet posts to an undocumented
-internal endpoint), `POST /_twin/clients`, `POST /_twin/accounts` (also what creator_info answers:
-`is_private`, `privacy_level_options`, the comment/duet/stitch switches,
-`max_video_post_duration_sec`), `POST /_twin/videos` (a metadata-only video for a Display API
-fixture; a video with its media is posted through the Content Posting API), `POST /_twin/tokens`
-(a user access token with the named scopes — what a World issues in place of the consent leg),
-`POST /_twin/session`, `POST /_twin/rate_limit` (arm a deterministic 429) and
-`GET /_twin/media/video/<post id>` (a published video's bytes; TikTok's CDN is not Open API
-surface). This list is the audit trail the conformance
-census deliberately excludes — keep it in lockstep with `twinControl`'s branches in
-`tiktok-twin.ts`.
-
-## The three operations
-
-- **pull** — `syncTikTokFromReal(execute)` observes the real account behind the operator's own user
-  token (`GET /v2/user/info/`, every modelled field) over an **injected executor**, and their
-  videos when `videos: true` (the video reads need the separate `video.list` scope, so they are
-  opt-in rather than silently skipped). Live runs use `liveTikTokExecute(accessToken)`, the ONE
-  place a real TikTok request may be issued, guarded by the fail-closed rate budget
-  (`tiktok-budget.ts`: TikTok's own 600-per-minute scheme, live-fetched 2026-09-13). The app
-  registry and the token's scope set are **not observable** (no API reads TikTok apps; TikTok has
-  no token introspection) — reasoned gaps, not fakes. Accounts are keyed by `union_id`, so one
-  human is one twin account however many apps they authorize.
-- **write** — the default: local consent flows mint local credentials and local posts, no real calls.
-- **perform** — a World's post crosses when its root is TikTok: `performTikTokAction` sends a
-  `video.publish` entry through the vendor's own Direct Post flow (creator_info, whose
-  `privacy_level_options` must include the entry's privacy level; `video/init` with the chunk plan
-  TikTok's rules require; each chunk `PUT` to the returned `upload_url` **presigned** — without the
-  sealed credential, on the upload host; `status/fetch` until `PUBLISH_COMPLETE`), and a
-  `video.inbox_upload` through the inbox init to `SEND_TO_USER_INBOX`. The bytes come off the blob
-  seam a chunk at a time. The pack budget wraps the executor with one ledger per sealed credential
-  (its keyed fingerprint — every World posting as one account spends one allowance), per World root
-  only when none is sealed:
-  creator_info, the init and every status read are charged (at 600 over each reference's per-minute
-  figure), an answer that arrived is never dropped, and the chunk `PUT`s are not charged — once a
-  publish has started, the budget cannot stop it. The wait reads status every 3 s and stops at
-  120 s, failing retryably — as does a 429 or 5xx from TikTok, or a chunk TikTok does not take; the
-  publish it opened and its upload URL are kept in this World's byte annex (never an entry, never a
-  changeset), so the next deploy asks that publish where it stands and resumes its missing chunks
-  instead of posting twice. It opens a fresh publish only when TikTok says the old one is gone
-  (`invalid_publish_id`, or `FAILED`): `uploaded_bytes` is a count of what arrived, and no count
-  means TikTok will not still post it. Nothing else
-  crosses: apps, users, tokens and grants have no TikTok write API, and each entry says so.
-
-## Serving
-
-`world-tiktok serve` starts one server for the WHOLE surface; point `www.tiktok.com` (the
-authorization path only), `open.tiktokapis.com` (the Login Kit, Display and Content Posting paths
-only) and `open-upload.tiktokapis.com` (`/video/` only) at it — the pack descriptor's path-scoped
-`hosts` entries do exactly that, so an unmodelled TikTok call refuses loudly instead of landing in a
-twin that cannot serve it. `mirror` is the same twin with the tiktok.com mirror at `/`, and prints a
-ready-to-open authorization URL for the authorization page too; `conformance` runs the endpoint
-census (one real probe per claimed endpoint + the hand-enumerated router surface + a reachability
-witness per resource type).
+The TikTok twin (Protocol 3), serving what Postiz calls ([journeys/demand.json](./journeys/demand.json),
+[journeys/decisions.json](./journeys/decisions.json)). TikTok publishes no OpenAPI document of these APIs; the open
+lane's spec is written from developers.tiktok.com's reference pages (`open/spec/SOURCE.md`).
+
+- **The open lane** (open.tiktokapis.com, open-upload.tiktokapis.com, www.tiktok.com/v2/auth/authorize/):
+  - the authorize page, where a TikTok person logs in and consents; the redirect carries `code`, `scopes`, `state`;
+  - the token (a code once, a refresh token once; `act.`/`rft.` tokens drawn from the World's secret, kept by SHA-256);
+  - user info (fields gated by scope; `video_count` counted from the person's public videos) and creator info;
+  - posting: a video directly or to the creator's inbox by chunked upload (the chunk plan checked, the bytes kept as
+    blobs), photos pulled from URLs the app verified (through the World: a URL it does not serve fails the pull),
+    and the post's status, moved only by `src/semantics/states.ts`;
+  - the videos a direct post makes (the Video Object; duration and size read from the MP4's boxes, the cover a
+    labeled placeholder), listed newest first by cursor and queried by id.
+- **The business lane** (business-api.tiktok.com, `business/spec/SOURCE.md`): Postiz's TikTok Business provider.
+  Every answer is HTTP 200 with TikTok's `code` (0, or 40001/40002/40102/40104/40105/40107/40110/40131):
+  - the business app's token (the same authorize page, a code once, a refresh token once, 24-hour access tokens);
+  - the account's profile and analytics (`fields` a JSON array) and its public posts' counts, paged by cursor;
+  - publishing a video or photos by URL: TikTok pulls them through the World, so a URL nothing in the World serves
+    fails the pull (FAILED, `video_pull_failed`/`photo_pull_failed`); the status moves only by `src/semantics/states.ts`;
+  - the locations a post may tag and the Commercial Music Library's tracks, searched and listed by genre.
+
+The developer site's app, its redirect URIs and URL properties, TikTok's people and a video's audience are the World's
+doors (`POST /_twin/app-credentials`, `/_twin/apps` with `redirect_uris` and `business_redirect_uris`, `/_twin/people`,
+`/_twin/videos/{id}/stats`, `/_twin/locations`, `/_twin/tracks`). The credential door answers TIKTOK_CLIENT_ID,
+TIKTOK_CLIENT_SECRET, TIKTOK_BUSINESS_CLIENT_ID and TIKTOK_BUSINESS_CLIENT_SECRET.

package/business/spec/SOURCE.md

@@ -0,0 +1,17 @@
+# TikTok API for Business v1.3: the Accounts API and Discovery
+
+- **Why this document:** TikTok publishes no OpenAPI document of these endpoints (its SDK repository's yml files,
+  tiktok/tiktok-business-api-sdk @ f809c39652, are the Marketing API's). This document is written from the v1.3
+  documentation, one operation per endpoint. The portal (business-api.tiktok.com/portal/docs) renders in the browser;
+  each page's text is its docs gateway's answer, which each operation names (`externalDocs`) and the pack cites:
+  `https://business-api.tiktok.com/gateway/api/doc/client/node/get/v2/?identify_key=<v1.3>&doc_id=<page>&language=ENGLISH`
+  (the v1.3 key `c0138ffadd90a955c1f0670a56fe348d1d40680b3c89461e09f78ed26785164b`, from the portal's own bundle). Pages: Accounts API Authentication (1738084387220481),
+  Authorization (1738083939371009), Get profile data (1762228399168514), Get post data (1762228421622786), Publish a
+  public video post (1762228496095234), Publish a photo post (1803630424390658), Get the publishing status
+  (1816387106635778), Get the location tags (1870580030749698), Get popular tracks from the Commercial Music Library
+  (1825119063013505), Get TikTok account permission scopes (1765927978092545), Appendix - Return codes
+  (1737172488964097), fetched 2026-09-30.
+- **Its host:** business-api.tiktok.com.
+- **Corrections:** none.
+- **Read by:** the twin orchestrator, 2026-09-30.
+- **Vendored bytes (sha256):** `openapi.json` `ad0a7a19e49fba66c359b3ef12dbe8daeb112a36e1cc0a14f0e28f94fb26d4f9`.