A tool page is fine until you need it two hundred times. Then you want a URL you can POST to. ToolForte's REST API is exactly that: the deterministic tools from the site (validators, converters, generators, parsers), plus a set of render endpoints that turn HTML or a URL into a PDF or a screenshot with headless Chrome.

This post is the version of the developer docs I would want on a first afternoon: enough to make one call work, then the things that bite later.

One key, one header

Sign in, open your account page, and create a key under API keys. It is shown once. We store a hash of it, so if you lose it you make a new one; nobody at ToolForte can read it back to you.

Every request carries the key in the X-API-Key header. That is the whole authentication story. There is no OAuth dance, no token refresh, and no separate sandbox key: the same key works for every endpoint.

The request shape

Every tool lives at POST https://toolforte.com/api/v1/tools/, where the slug is the same one you see in the tool page's address. The body is JSON with the tool's inputs, the answer is JSON with its outputs.

A first call, validating an IBAN:

curl -X POST https://toolforte.com/api/v1/tools/iban-validator -H "X-API-Key: tf_..." -H "Content-Type: application/json" -d '{"iban":"NL91ABNA0417164300"}'

The answer tells you whether the checksum holds, which country layout it matched and which bank code it carries. The developers page has the input and output fields for every endpoint, with a curl line each, and /openapi.json is the same information as an OpenAPI 3 document you can import into Postman or feed to a client generator.

What a call costs, and what happens when you run out

One API call costs one credit. A free account gets 1,000 credits a month, which resets on the first. ToolForte Pro is 7,500 a month for €19, and you can buy extra credits at any time (100 for €1.00, 1,000 for €5.00, 5,000 for €20.00 at the time of writing); bought credits never expire and are spent only after the monthly allowance is gone.

There is no per-second throttle. The only limit is the balance. When it is empty the API answers 429 with headers that say what the limit was, what is left (zero) and when it resets, and the JSON body says the same in words. Read the 429 body in your client. The most common support question I get is a script that retried a 429 in a tight loop for an hour, which achieved nothing except a full log.

If you would rather never see a 429, the account page has an automatic top-up: pick a threshold, an amount, and a monthly ceiling. It charges the card you last paid with, at the public price, and stops at the ceiling.

The render endpoints are different

HTML to PDF, URL to PDF and URL to screenshot run headless Chrome on our servers, and that is the one place a document you send is written to disk. The output goes into a private bucket and comes back as a signed link that expires after 24 hours; a daily job deletes the files themselves. A render costs 25 credits, because it is seconds of CPU rather than microseconds of arithmetic.

curl -X POST https://toolforte.com/api/v1/render/html-to-pdf -H "X-API-Key: tf_..." -H "Content-Type: application/json" -d '{"html":"

Invoice 2026-041

Two rules I learned the hard way. First, the URL endpoints only fetch public addresses: private networks and cloud metadata endpoints are refused, on purpose, and the terms say so. Second, download the file when you get the link. A link found in a log a week later is dead.

Where it fits in a real system

The pattern I see most is validation at the edge. A form accepts an IBAN or a VAT number, the backend calls the validator before it writes the row, and a wrong value is refused with the reason the API gave. That is one credit per submission, which on a free account covers about thirty submissions a day.

The second pattern is test data. A seed script asks the test IBAN generator for fifty valid Dutch IBANs and the BRP generator for fifty synthetic people, pins a seed so the data is the same on every run, and loads them into the test database. I wrote that one up in the test data post.

The third is document output: an invoice rendered from your own HTML template rather than a PDF library you have to maintain. If your invoices are simple, the invoice generator on the site does it without any code at all.

Things that are deliberately not there

There are no endpoints for the browser-only tools that work on a file in memory, like the image resizer or PDF merge, because uploading a file to a server is exactly what those pages exist to avoid. The render API covers the cases where a server is the right place.

There is no webhook for a finished render. Renders finish within the request. If yours takes longer than the timeout, it is too big for this API, and I would rather tell you than queue it.

And there is no separate pricing for the API. Same credits, same balance, same page.