Async jobs and watches, without writing a client first

Start a batch or a watch from the dashboard, follow it while it runs, and read the result there. It calls the same handlers an API key calls, mirrored under /v1/me for a browser session, so the two surfaces return identical bodies and cannot drift into billing differently.

• A batch refunds every target that fails or comes back empty while the job is still running, so a half-failing batch bills for the half that worked.
• A watch polls on our side and charges only when the content actually moved. Identical polls are free, and the fingerprint ignores the fields that change on every fetch — timestamps, and the media URLs platforms re-mint per request.

A watch bills what the same call bills

A watch charged list price even for a result the endpoint itself declared worth less. The live case is twitter.profile, which returns almost nothing to a logged-out caller and charges nothing through the API — through a watch it was charging in full. One result, two prices, which is the thing a single execution path exists to prevent. The poller honours the endpoint’s own valuation now, and takes no charge at all when that is zero.

The cost of a watch is quoted as a ceiling, and as a day

The sentence you read before confirming a watch said you are charged the list price per change. List price is an upper bound, not a fee, so it now says “up to”. It also states the worst case for a whole day at the interval you picked, because a rate is not a budget: five-minute polling is 288 possible charges a day, and that is the number worth seeing before you agree to a recurring one.

Work we cannot honour is refused when you create it

Job and watch creation never checked parameters against the endpoint’s own schema, so a mistyped one came back accepted and failed later — while the synchronous route rejected the identical input immediately. That is worse for a watch than a job: an invalid watch is not merely doomed, it accumulates failures on a schedule until it deactivates itself. Parameters are validated at creation now, every target in a batch included.

• events accepts only change, the one event the poller implements. It used to accept any string, store it, echo it back, and ignore it — so a caller filtering on something else was told the filter was accepted and then received everything.
• A deployment with no queue refuses an async job instead of accepting one nothing would ever run. Creation charges nothing, so no money was involved, but a 202 said the work was accepted when no worker would ever see it.

Whether an endpoint can be watched is now in the spec

Search, trending and popular endpoints re-rank the same query on every request. A watch on one of those would bill on the churn instead of on news, so they are deliberately not subscribable — and that flag now ships as x-subscribable on every operation in openapi.json. An agent can read it before it tries, rather than learning it from a rejection.

Every endpoint is open to every account

A free-tier gate held every endpoint that needs a residential proxy behind a funded team. That contradicted the “every endpoint, no feature gating” line on the pricing page, and it answered 402 to teams whose balance was perfectly healthy — the same confusion between an auth error and a billing error we call out elsewhere. The gate is deleted. The signup grant is what changed instead: it pays out once the email address is verified, since an open door and an unverified mailbox together are just a credits faucet.

The pricing page lists only what can actually be sold

It advertised monthly tiers carrying rollover credits, a priority poll queue and a support response commitment. None of the three had been built, and billing sells one-time credit packs only, so the tiers described a product that did not exist. They are gone, the free grant is described as the one-time grant it is rather than a renewing allowance, and the prices that remain are checked against the catalog checkout reads by a test that fails when the two disagree.

The service is called TrueScrape

The working name was “Social Data API” — a description standing in for a name — and an older codename still survived inside the MCP server, which introduced itself under that name and read its own bespoke API-key header. One name now, and the MCP surface authenticates with the same x-api-key as everything else.

The dashboard shows your account rather than a fixture

It used to render from a mock file with a note in it saying to replace this once sessions exist. Sessions had existed for a while; only the browser half was missing. Keys, balance, usage, request history and team are your own data now, and the mock file is deleted rather than bypassed. Where a page could not be built honestly it says so on its face — a history filter the request log has no column for is absent, not faked with a plausible number.

First build

One Creator, Post, Comment, Transcript and Ad object across every platform in the registry, with the untouched upstream payload available beside the normalised one. Synchronous calls, batches, async jobs and watches all run down a single execution path — validate, preflight, cache, charge, run, settle — so no route can bill differently from another. Failures, empty results and cache hits are refunded at that settle step, not by a rule written twice in two places.

• Every endpoint publishes its own price, cache policy and proxy requirement in openapi.json and llms.txt, and is exposed as an MCP tool built from the same definition.
• Cross-field parameter rules — which combinations an endpoint will actually accept — are published rather than discovered by trial.