Jobs at TwitterAPIs

About TwitterAPIs

TwitterAPIs is a pay-per-call Twitter and X data API. There is no subscription, no seat count and no developer-account application: a customer signs up, gets $0.50 in credit without a card, and starts calling. The surface is 109 public endpoints, 65 reads and 44 writes, plus an MCP server exposing 109 tools so an agent can call the same surface a script does.

The pricing is drawn by what a call costs us to serve rather than by plan. The standard read rate covers 62 of them and takes in every simple write, because a like or a follow is the same amount of work as a read. The 24 free ones are free for a specific reason: they are the calls a customer makes to find out why a paid call failed, and pricing those would mean the person who just spent their balance is the one who cannot see it. The 19 at twice the read rate are there because they hold a connection open or fan out into several upstream requests, not because a model is running behind them.

That design decision is most of the engineering culture here. Numbers that customers pay against live in one place and are read from there, and the surfaces that publish them are checked against the router rather than against each other.

Job description

This is a backend role on the API itself, not on the marketing site and not on internal tooling. You would work on the service that sits between a customer request and X, the billing path that prices every call before it returns, and the monitoring surface that customers point at accounts and keywords they care about.

The work is unusually measurable. A regression here is a customer being charged the wrong amount, an endpoint returning an empty body instead of an error, or a documented route the router does not serve. All three are caught by checks rather than by opinion, and the checks are part of the job: if a class of bug can happen twice, the second one should be refused by something that runs on its own.

It is an early role. There is no separate platform team to hand an incident to, and there is no product manager translating a request into a ticket. You would read the customer message, decide whether it is a bug or a missing endpoint, and ship the answer.

Responsibilities

• •Own endpoints end to end: the route in the scraper service, its price entry, its OpenAPI block, and the reference page that documents it. An endpoint that ships without all four is not finished.
• •Keep the proxy path fast and cheap under load, which mostly means connection reuse, response compression and not re-fetching what a cache already holds.
• •Work on billing correctness. Every call resolves to a price before it returns, and a slug the biller does not know falls back to the standard read rate, so an unpriced endpoint silently undercharges rather than erroring.
• •Harden the retry and session layer against an upstream that changes without notice, and make the failure legible in the response instead of returning an empty body.
• •Add the monitoring and webhook surface that customers use to watch accounts and keywords, including the delivery retries behind it.
• •Write the migrations, and keep the schema small enough that someone can read the table list and understand the product.

The systems you would own

There are four of them, and they are small enough that one engineer can hold all four in their head, which is the point of joining now.

The first is the scraper service, the process that sits in front of X and turns a request for tweets into whatever upstream call currently returns them. Most new endpoints are blocked on obtaining the right query identifier rather than on writing the handler, so the interesting work is in the capture and the fallback behaviour, not the route file. When upstream changes shape without telling anyone, this is the layer that either degrades honestly or starts returning empty arrays that look like a quiet day.

The second is billing. Every call resolves to a price before it returns, and a slug the price table does not recognise takes an unknown-slug fallback rather than erroring, which means a missing price entry undercharges silently instead of failing loudly. That asymmetry produces a specific family of bug worth understanding before you arrive. We currently carry three price entries whose routes are not served at all, because the upstream endpoints they were written for return 404 on every host and have no replacement, and four served endpoints with no price entry that take the fallback instead of a rate somebody chose. One of those four is a real customer-facing defect: a management endpoint published at zero cost still gets pre-authorised at the fallback rate, so a customer sitting at a zero balance is refused on a call that is supposed to be free. Fixing that is a good first week.

The third is the published surface. The router, the price table, the OpenAPI document, the docs pages and the MCP server all have to enumerate the same 109 endpoints, and the parity checks compare each of them against the router rather than against each other, because two documents agreeing proves nothing about the thing they describe. An endpoint live but documented nowhere is an endpoint nobody can call.

The fourth is monitoring: the endpoints customers use to watch accounts and keywords, and the webhook delivery behind them. Delivery is the part that is easy to build and hard to keep honest, because a failed callback that nobody is told about is indistinguishable from a subject who simply did not post.

Skills

We care about what you have actually built more than where you built it. These are the things the work touches every week.

• •Strong Node.js / TypeScript experience
• •REST API design and proxy patterns
• •PostgreSQL / database optimization
• •Docker, Linux, CI/CD

The current stack is Node.js, TypeScript, Supabase, Docker, PM2, Cloudflare, running on Hetzner. You do not need to have used all of it. You do need to be able to read a service you did not write and change it without breaking the billing path.

Good to have

None of these are requirements. Each one shortens the ramp.

• •Experience with a metered or usage-billed product, where a wrong number is a refund rather than a redeploy
• •Having run a scraper or proxy fleet against a hostile upstream, and knowing why the retry loop is the hard part
• •OpenAPI authoring, including keeping a generated document honest against the router that serves it
• •MCP or another agent tool protocol, since a large share of the traffic here arrives from agents rather than browsers
• •Comfort reading someone else's Postgres schema and being the person who says the migration is wrong

Work model

Fully remote, from anywhere. There is no office to be near and no relocation attached to the role. The team overlaps around GST (UTC+4), which is also when support is staffed, Monday to Saturday between 10:00 and 20:00, so a few hours of overlap with that window makes incidents easier. Outside that, the work is asynchronous and judged on what shipped.

Compensation is $20K to $40K a year plus 0.5% to 2% equity. The range is wide because it moves with experience and with where you are, and the equity is real rather than a rounding error, which is the trade an early role offers in place of a larger salary. We would rather say the number up front than discover in week three that it was never going to work.

How we ship

Everything goes through a branch and a pull request, including a fix to production, and the checks run on the machine that opens it rather than on a hosted runner. The public site alone carries more than seventy of them, and they are not style checks: they diff the endpoint list against the router, refuse a price that disagrees with the biller, refuse a count in page copy that no constant backs, and refuse a documented route the API does not serve.

The habit behind that is worth stating plainly, because it is the main thing that would be asked of you. When a bug is found, the fix is the first half of the job and a check that refuses the same bug next time is the second half. A note in a commit message is read once and then never again by the person about to repeat the mistake. A check runs on its own. We also red-test them: a check nobody has watched fail on a deliberately broken input is unverified, not passing.

The corollary is that a number a customer pays against lives in exactly one file and is read from there by everything that shows it. When a price or an endpoint count moves, it moves once, and the surfaces that publish it follow automatically instead of being edited by hand and drifting apart. If you have ever chased the same figure through six files, you already know why this is written down.

How we hire

A short call about what you have built, then a paid piece of real work from the actual backlog, then a conversation about how you approached it. There is no take-home puzzle with no relationship to the job and no panel of people who have not read your code. If the paid piece goes well, it is usually the fastest part of the process.

How to apply

Email emma@twitterapis.com with the subject line Backend Engineer, API Infrastructure. Send a link to something you built and one paragraph on the hardest bug you fixed in it. A CV is optional. There is no application form and no third-party job board in the loop, so nothing is lost in a queue.

If you want to understand the product before writing, the fastest route is to sign up, spend the free credit, and tell us what you would change. The answers index and the pricing page cover most of what a candidate asks on the first call.

Questions candidates ask

Do I need experience with the X or Twitter API specifically?

No. Almost nobody arrives with it, because the useful version of that experience comes from working against an upstream that does not want to be automated, and that is not X specific. What matters more is having debugged something where the failure was silent rather than loud.

Is this really fully remote, or remote with a catch?

Fully remote. There is no office and no relocation. The only scheduling constraint is that support runs Monday to Saturday between 10:00 and 20:00 GST, so some overlap with that window makes incident handling easier.

What does the paid work trial involve?

A real item from the backlog, scoped to a few days, paid at the rate the role implies. You use the actual repository and open an actual pull request. We would rather see how you handle a codebase you did not write than how you handle a puzzle nobody will ever run.

How small is the team?

Small enough that the person who ships an endpoint also prices it, documents it, and answers the support message when a customer finds the edge case. If you want a narrow slice of a large system, this is the wrong role.

What happens if I want to look at the product first?

Sign up and spend the $0.50 of credit, no card required. Reading the OpenAPI document is the fastest way to understand the shape of the thing, since every endpoint carries its own price as a field.

Do you take contractors or part-time?

Write in and say what you have in mind. The role is written full-time because that is what the work needs, but a strong part-time arrangement is worth a conversation rather than an automatic no.