Developer API portal: 7 things to check before you pick one
Last updated

Developer portals are easy to demo and hard to trust. The questions that matter come after the first key works. Here are seven things to check before you pick a self-hosted portal, with DEV3 Tolldeck as the worked example.

1. Are the docs generated from your OpenAPI file?
Import once, keep one source of truth. Check that external references are refused instead of fetched, that Markdown in descriptions is sanitised and that old versions can be deprecated with a sunset date.

2. How are keys stored?
A portal that can show a developer's key later can leak it. Tolldeck stores a peppered hash and the last four characters, shows the key once, rotates with a grace period and revokes at once.

3. What happens at the quota edge?
Fifty parallel requests with ten units left should produce exactly ten successes. Ask how the portal counts without a database transaction, and what happens when the upstream fails.

4. Gateway or verify-and-report?
A proxy is the simplest to run; your own gateway calling a verify endpoint scales further. Look for both, with the same decisions behind them.

5. Can you see the traffic?
Usage by product, app and operation, error rates, latency percentiles and a sampled log explorer turn support tickets into a lookup.

6. Do the invoices add up?
Base fee, whole overage blocks and tax per line, in integer money, one invoice per subscription and month.

7. Who keeps it running?
One Node process and MongoDB, plus cron for rollups and invoicing. Gateway mode suits moderate traffic.
Limits to weigh
HTTP and JSON APIs only: no GraphQL, gRPC or WebSocket proxying. Payments are simulated until you connect a gateway. The replay cache and rate limiter live in the process. Check those against your needs.
Docs, guides and changelog — OpenAPI reference, guides and a changelog with breaking-change badges.






