> This page is for The Console. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://infonite.dev/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://infonite.dev/_mcp/server. # Capabilities Every application starts able to do everything — **in sandbox**. A capability works there from the first minute, against rehearsal data, and never reaches a real person. Production reach is the part we grant, one capability at a time, and [*App Settings → Capabilities*](https://www.infonite.tech/console/app-settings/) is where you see what you hold and ask for the rest. > **Note** > > **Sandbox is not a trial version of a capability.** It is the same code, the same schemas and the same responses; what differs is who is on the other end. That is why you can build the whole integration before asking us for anything. --- ## The screen ![The Capabilities screen in the Console, grouped by family: Direct Executions granted for production, Financial Rider with a request waiting since 26 September, and the rest at sandbox reach with a Request button on each row](/_fern-files/_img/6e1077fa6dcca36bb44dc071aa489013d2d2ac4b4879080fd3d35fa2fb6f2ff8.webp)![The Capabilities screen in the Console, grouped by family: Direct Executions granted for production, Financial Rider with a request waiting since 26 September, and the rest at sandbox reach with a Request button on each row](/_fern-files/_img/9d176639ee531a1dd541198307036520cc25ccc41c17fda5a151de73ec06c6ab.webp) The catalogue is grouped by **family**, and each row answers three questions: #### Reach `SNBX` or `PRO`. Sandbox is where every capability starts; production is the one we grant. #### Granted The day production reach was given. *Sandbox from the start* means nobody had to give it. #### What is in flight A **Request** button, or the date somebody asked. Open the date to read the request, change it, or take it back. **Anyone on your team sees this screen.** Asking is a manager's act, because it commits the organization — so a developer reads what the application holds without a Request button, which is the answer to a surprising number of "why am I getting a 403". --- ## Asking for production ![The request dialog over the Capabilities screen: the capability being asked about, an explanation of what production reach means, and an optional message field](/_fern-files/_img/f835832e6b6112912b81bc695d62ad0ed540319560acee734f33d261922da17c.webp)![The request dialog over the Capabilities screen: the capability being asked about, an explanation of what production reach means, and an optional message field](/_fern-files/_img/ac8ac60a9c81951a35d7d80ef88c5653e46450a560c83e227ace71b94bc0ac6d.webp) #### Tell us what it is for The message is optional, and it is the part a person reads before deciding. What you need it for, when you go live, what you have already tested in sandbox: any of it shortens the conversation. #### It lands in the same queue as everything else An administrator answers it. While it is open, the row shows the date instead of the button — asking twice for the same capability is refused, so a second click cannot make two of them. #### Change your mind, or your wording Open the date. Any manager of the application can correct the message or withdraw the request while it is still open. A withdrawal is not a refusal from us and is not recorded as one — it says there is no longer a question, and you can ask again whenever you like. > **Note** > > **Going to production is a separate request, and it asks for capabilities too.** [Moving the application itself to production](/console/organizations-and-applications) needs at least one product enabled — an application that is live but can do nothing is not much use — so that form lets you pick the products in the same act, and raises the requests together. --- ## What each family grants ### Product A product is **what the application does**. Every application needs at least one to be worth moving to production. | Capability | What it grants | | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Direct Executions** · `product:direct_executions` | Launch executions from your own backend and read the results — no hosted screen and no redirect. The whole [Direct Executions](/direct-executions/overview) surface. | | **Financial Rider** · `product:financial_rider` | The hosted experience over the end user's banks: we build the screens, you get the data. The whole [Financial Rider Flow](/flows/financial-rider/overview). | | **Spain Public Administration** · `product:es_public_administration` | The hosted experience where the end user connects the [Spanish administrations](/flows/spain-public-administration/overview). | ### Access How an access is performed, beyond sending the credentials on every run. | Capability | What it grants | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Tokenized access** · `login:tokenized_access` | Run an access again later through a [token](/guides/credential-tokenization) instead of holding the end user's password — recurring access, on the engines that support it. | ### Data A source of **ours** — data we hold, rather than something extracted from the end user's own account. | Capability | What it grants | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **Spanish vehicles registry** · `data:vehicles_registry_es` | The Spanish [vehicles registry](/guides/data-models/vehicles), keyed by plate or by owner. | ### Data enrichment A pass over data that has **already been retrieved**. Enrichment never fetches anything on its own: it makes more of what an execution already brought back. | Capability | What it grants | | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Accounts enrichment** · `data_enrichment:accounts_read` | Categorisation and everything derived from retrieved [accounts](/guides/data-models/banking/accounts) and their movements. | | **Cards enrichment** · `data_enrichment:cards_read` | The same over [cards](/guides/data-models/banking/cards) and their transactions. | | **Labor check** · `data_enrichment:labor_check` | What an employment record implies — an income floor, work statuses ([labor check](/guides/data-models/labor-check)). | --- ## Where a missing capability shows up Not as an empty response. An API call that needs production reach your application does not hold is **refused** with `403` and a `detail` that names the capability — `insufficient_capabilities@` followed by its code, the one beside each name in the tables above, and several separated by commas when more than one is missing (`insufficient_capabilities@login:tokenized_access,product:financial_rider`). The part before the `@` never changes, so branch on it. If you meet one in sandbox, it is not a capability problem: sandbox grants them all. The screen is the fastest way to check. The row says the reach; if it says `SNBX` and your call needs production, that is the answer.