Build1 publisher2 min readPublished Updated
Seven line items separate a £30,000 internal API from a £100,000 public one
A dev.to costing post puts internal APIs at £10,000 to £30,000 and public ones above £100,000 for much the same endpoints, with the difference sitting in token flows, sandboxes, docs and per-consumer tracing.
The Engineer · Build desk
What happened
- A dev.to costing post argues that estimating custom API work from endpoint counts is usually wrong by a factor of three, because the endpoints themselves are the cheapest part of the job.
- The partner tier is where API keys stop being enough, needing token flows with scopes, expiry and rotation plus per-consumer permissions checked on every request instead of inferred from the key.
- Public APIs add self-service registration, key management, published rate limits, a status page and a support process on top of the same underlying resource model.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost A buyer comparing two quotes on endpoint count is comparing the fortnight of handler work and leaving £70,000 of scope unpriced.
- decision Who is allowed to call the API sets its price before any code exists, so the audience question belongs in the first scoping meeting.
- exposure Skip per-consumer error rates and correlation identifiers and the first integrator to hit errors becomes a support ticket nobody can trace, with the support team absorbing the cost.
- constraint Once named integrators depend on a published contract, the release calendar is theirs too: a breaking change cannot simply go out on a Tuesday afternoon.
API keys are simple and appropriate for internal use, according to the post; partner and public APIs generally need a token-based flow with scopes, expiry and rotation, plus per-consumer permissions enforced on every request [8]. Enforcing that per request puts the permission check inside each handler, not in one key lookup at the edge. The post ties the width of its partner band, £40,000 to £100,000, to the number of resources and the strictness of the security requirements [4].
The endpoint work barely moves. A dozen endpoints reading and writing data you already hold is a fortnight for a competent backend developer, the post says [2], and the same set of endpoints costs very different amounts depending on who consumes them [17]. Internal work is put at £10,000 to £30,000 [3]. A public or product API with self-service onboarding and a published contract starts around £100,000 and keeps costing after launch [5]. Same handlers, £70,000 apart between the top of one band and the floor of the other [1]. Midpoints give £20,000 internal against £70,000 partner, a step of 3.5x [2], and the post says endpoint-count estimates come out wrong by a factor of three [1].
The author wrote that the budget goes on the gap between having an API and having an API other people rely on [6].
Seven line items carry that gap: design and contract, authentication and authorisation, rate limiting and quotas, documentation, a sandbox, observability, testing [7][4]. Two are worth pricing on their own. The sandbox needs realistic data, resettable state and the same validation rules, and the post calls it one of the most commonly omitted items in an API quote and one of the most frequently demanded features after launch [10]. Contract tests are the ones that fail the build when a response shape changes unintentionally [12].
For the bands to transfer, the described scope has to hold. That means roughly a dozen resources over data you already have, documentation measured in weeks of work [13], and rate limits communicated in response headers with an override path for the customer who legitimately needs more [9]. The post is one practitioner's price list, and it does not say which projects the numbers come from [5]. I'd use the checklist before I'd use the figures. "Working through this list against a quote is the fastest way to see what has been left out," the author wrote [16].
What to watch
- Any published hours, day rates or project sample behind the three bands, which would make them testable against a real quote.
- Whether a supplier's quote itemises the sandbox on its own line or folds it into a single testing figure.
- Whether usage-based billing is in scope, since that adds a metering and reconciliation system to the build.