Torii’s capabilities are discoverable — the live catalog at GET /v1/task-sources is always the source of truth. The full matrix is listed below for reference, but query the endpoint when you need the authoritative, up-to-the-deploy set.

​
Supported platforms & actions

Each ✓ is a real source.action you can pass to POST /v1/tasks. A blank cell means the platform genuinely lacks that verb (calling it returns unsupported).
Write verbs. threads, truthsocial, and weibo also support publishing — post.create, comment.create, delete — which require a write-scoped token and confirm: true. See Authentication.

​
Account requirements

Some platforms crawl from public endpoints; others need a provisioned social account (a real login, captured once via the operator dashboard). The requirement is per platform, not per action — if a platform needs a login, it needs one for every action it offers. Each catalog row carries this as a stateful boolean on GET /v1/task-sources (stateful: true ⇒ account required; absent ⇒ open). Gate on that field rather than hardcoding this table — it stays correct across deploys.
Calling an account-required action with no provisioned (or a lapsed) login returns error.code: session_expired — an honest “this profile needs a human re-login”, never a silent empty result or a misleading blocked. Provision or re-login the account, then retry. Check a profile’s live health on GET /v1/profiles.
Automatic account failover. When you have more than one ready account for a platform, a blocked / session_expired / rate_limited result on one account makes Torii transparently retry on your other ready accounts — one at a time, never two sessions on one account. This applies to every read action (search, posts, user, detail, comments, hot, recommended, trending), not just search. You get blocked back only when every one of your accounts is walled; a single account’s bad day (a search-wall, a lapsed cookie) never surfaces as a failure. The envelope’s warnings note how many accounts were tried.Failover is scoped to you: the candidate accounts are the ones your bearer token owns — the same owner isolation as everywhere else, so one tenant’s block never reaches for another’s accounts. (health is exempt — it is a per-account probe, so it reports the account you named.) Writes never fail over: publishing is tied to a specific identity, so a blocked publish is returned as-is.
Two independent gates. Account required (this section, via stateful) is about the platform login. Write (above, via the write flag) is about your token’s scope. A publish verb (weibo.post.create, …) needs both: a provisioned Weibo account and a write-scoped token with confirm: true.

​
What each action does

​
List every capability (live)

​
Returns one row per real platform.action. Use it to populate a source picker or to check a capability before you call it.
A row’s name is exactly the "source.action" you pass to POST /v1/tasks ({"source":"youtube","action":"search"}).

​
The capability map

​
The same catalog, grouped by content kind, each provider carrying the actions it actually supports — because a provider is real for specific actions (Instagram has trending but not search; Threads is download-only). There is deliberately no provider-level “real” flag; the per-provider actions list is the truth.

​
Feed categories

​
For platforms whose hot / recommended feed has named tabs (e.g. TikTok’s Comedy, Sports), returns the tab list you can pass as params.category.

​
Refs: what query accepts

For a creator or post action, params.query is flexible — Torii resolves it: So the string a user copies from a platform’s share button works as a ref — no cleanup on your side.