Using the API
What holds true for every endpoint — authentication, base URLs, errors, and rate limits
Each product’s API Reference is generated from the running services, so what you read here is what the API does, not what someone remembered to write down. Each one carries the exact request and response schemas and an explorer you can send a call from.
They are built for looking things up. If you are still deciding how to integrate, start with what a flow is or what a direct execution is — the references will make far more sense afterwards.
There are three APIs, one per product, and they are not versions of the same thing:
Everything below is true of every endpoint of all three, so it is stated once here rather than repeated on each page. What each product protects with its own keys — the session key of a flow, the encrypted credentials of a direct execution — is on its Authentication & keys page: Financial Rider, Spain Public Administration, Direct Executions.
Authenticating
Server-to-server calls carry your application secret in a header:
The secret belongs on your server and nowhere else. It authorises creating sessions and reading extracted records for every customer of that application. It must never reach a browser, a mobile binary, or anything a user can open — the widget is the part that faces the end user, and it authenticates with its own short-lived session token instead.
Secrets are issued per application in the console, and can be revoked without affecting the application itself — useful for rotation. A call answers 401 when the secret is unknown or has been revoked, and 403 while the application is still pending approval.
The Direct Executions API adds one thing on top: the end user’s credentials travel inside the request body, and they can be encrypted with your application’s public key so that not even an intercepted body reveals them.
Each application is either sandbox or production, and its secret only works for its own. A sandbox application reaches demo engines only, which return realistic, fabricated records: build and test the whole journey end to end, with no real person and no real institution involved, before anything goes live. A production application reaches real institutions and can still rehearse — in a flow with settings.sandbox: true, in a direct execution by naming a sandbox engine (how).
Base URLs
infonite.io is where every API is moving, and no .io host serves yet. Build against the .tech host today. When a .io host starts serving, its .tech twin becomes deprecated and is retired after an announced migration window — see Authentication & keys.
The explorer on each endpoint page lets you pick between them, so you can try a call without leaving the documentation.
Errors
Every error answers with the same shape — an HTTP status, and a body with one field:
detail is a stable code, not a sentence: branch on it in your integration and show your own message to your own user. It is deliberately terse, and deliberately identical in cases that must not be distinguishable from outside.
The one exception is 422, which carries a validation body naming the field that was rejected — the shape is documented on each endpoint that can return it.
Rate limits
Limits are applied per application and vary by endpoint: the calls that create and read sessions are cheap, the one that returns full extracted results is deliberately tighter, since a result set is a large object that should be fetched once and stored.
Read your budget from the response, do not hardcode it. Every response carries the current limit, what is left of it, and when it resets. A client that watches those headers keeps working when a limit is tuned; one built around numbers copied from a document does not.
Exceeding a limit answers 429 with a detail that names which limit you hit — for example manager_session_results_rate_limit_exceeded — so a retry can back off against the right one.
Every response carries
The webhook pages
A section here is titled Webhooks, and its pages describe calls that go the other way: we send them to your server, over HTTPS, when the event fires. They are documented as endpoints because the payload contract is identical in kind — the schema on the page is exactly what will arrive.
They are the asynchronous half of consuming results; the synchronous half is the state and results endpoints documented above, called on a loop.