About | BuildAPI - We Power the Next Generation of APIs

The problem we work on

Software is easy to copy and hard to license. Put a key in a page and it can be read; put the check on your own server and every customer needs one. Most licence gates end up being a boolean somebody can delete, and the ones that are not tend to take the whole site down the first time the licence server has a bad afternoon.

BuildAPI is the middle: a key that only works on the site it belongs to, ownership of that site actually proved rather than asserted, answers signed so they cannot be forged, and a short cached grant so our problems do not become yours.

What that means in practice

A key is bound to one site

Every key is locked to a domain. A key lifted out of a page and used somewhere else is refused, because the domain it is called from is checked on every request.

Ownership is proved, not claimed

Binding a key to a domain would mean nothing if anyone could name any domain. Control is proved by a DNS record or a file, and re-proved daily.

Answers are signed

Every authorization is HMAC-signed with the key itself and bound to a one-time nonce, so a "yes" cannot be forged in transit or captured and replayed.

Our downtime is not yours

A verified site caches a signed entitlement and keeps serving if we are unreachable. A refusal stops it immediately; only silence is ridden out, and only for as long as the grant is good for.

How a request is decided

One chain, run by every endpoint, in this order. Cheap and decisive checks first, so a flood of bad keys is refused before it costs anything.

1
Is the key real?
Revoked, suspended and expired keys are separated so an integration can tell "switched off for now" from "gone for good".
2
Is it allowed here?
The IP allowlist is enforced against the connecting address, never one the caller names for itself.
3
Is this the right site?
The domain lock, then proof that the domain is owned by the account holding the key.
4
Is there allowance left?
Counted across the account over your own billing anniversary, not the first of the month.
5
Where is it running?
An installation fingerprint, so a copied site is a new installation rather than the licensed one.

Every refusal comes back with a short machine-readable reason, because “403” on its own tells whoever is reading the logs at two in the morning nothing at all. See the endpoint reference →

What this does not do

A licence gate that oversells itself gets trusted for things it cannot do. These are the limits, stated plainly, so you can decide whether it fits before you build on it.

Client-side code can always be read

A key in a browser is visible in page source. That is a property of client code, not a gap in ours. The domain lock is what makes a copied key useless somewhere else; anything that must truly be enforced has to be checked on your server.

A domain lock does not stop cloning by itself

Someone who copies a site onto a domain they genuinely control can prove that domain. What stops them is whether they can get a working key at all — which is a commercial gate, not a cryptographic one.

A grace period is a real window

If we cannot be reached, a verified site keeps working on its cached grant. That is deliberate, and it means a site is not cut off the instant we have a bad afternoon.

Built and run from

United States

Payments partner

Paystack

Industry verticals

34

Try it against your own site

The free plan issues a real key with a real domain lock. Point it at a site you own, publish the record, and watch it refuse a request from anywhere else.

Create a free key

No card required · Read the documentation · How the gate works

We power the next generation of APIs