X API reference
Owned read pricing, and why a SaaS does not qualify
Owned Read is a $0.001-per-resource rate — a fifth of a normal post read — that applies only when the authenticated user is also the owner of the developer app, so a product with customers is charged the standard rate no matter whose data it is reading.
The trap, in the order you fall into it
You are costing out a bookmarks product. You find the pricing page, read that posts are $0.005 each, and then notice a second column: Owned Read, $0.001. You check the list of endpoints that qualify, and GET /2/users/{id}/bookmarks is on it. Your unit costs just fell by 80% and the business model got much easier.
Then you read the qualifying condition. X states it as:
“The following endpoints qualify for Owned Read pricing when {id} matches the authenticated user and that user is the owner of the developer app”Two conditions, joined by and. The first is satisfied by any well-behaved application: you are reading the bookmarks of the person whose token you hold. The second is the one that decides it. In a product with customers, the authenticated user is a customer — not the developer who registered the app. The condition is not met, and the rate is $0.005.
What the difference is worth
| Bookmarks imported | At $0.005 (standard) | At $0.001 (owned) |
|---|---|---|
| 100 | $0.50 | $0.10 |
| 500 | $2.50 | $0.50 |
| 1,000 | $5.00 | $1.00 |
| 3,000 | $15.00 | $3.00 |
| 5,000 | $25.00 | $5.00 |
At a consumer price point that 5× is the whole business. A 5,000-bookmark import at $25 against a $6 monthly subscription takes most of a year to recover; the same import at $5 pays back in a month. Which is precisely why the condition deserves reading twice rather than skimming.
Who does qualify
The rate is aimed at developers operating on their own account: a script that archives your own posts, a personal dashboard, a bot posting from the handle that registered the app. There, both halves of the condition hold — the ID being read is the authenticated user, and that user is the app owner — and the endpoints on the Owned Read list are genuinely a fifth of the price.
The distinction is not about who owns the data. Your customer owns their bookmarks in every sense that matters, and they authorised you to read them. Owned Read is about who owns the app, which is a different question, and the answer for any multi-tenant product is “not the person whose token is in use”.
How to plan around it
Plan at $0.005 and treat anything better as upside. That is a costing decision, not a concession: if you model at $0.001 and the interpretation goes the other way, every number in your plan is wrong by 5× on the single largest line, and you find out after launch when the first large import lands. Modelling at $0.005 and being pleasantly surprised costs you nothing.
It is also worth asking X support directly before launch, in writing. The condition is one sentence covering a case — a multi-tenant application acting for consenting users — that it does not obviously have in mind, and a clear answer is cheaper to obtain than to guess at. Note that whichever rate applies, it is still charged per resource returned and still deduplicated within the same UTC day, so the design that keeps costs down does not change.
We built the thing this describes
Sift reads your bookmarks once, sorts them into categories, and emails you what you saved. The rules on this page are the reason it costs what it costs — a one-result probe instead of a full page, one paid pass per UTC day, and never an expansion parameter.
Connect X