API Key Restrictions: IPs and Tools
Every NeuralSpace API key can carry two restrictions: which addresses may use it and which tools it can access. The setting lives on the API keys page, takes effect as soon as you save it and is checked on the server before the model is called: a blocked request gets a 403 response and no tokens are charged for it.
Why restrict a key
An API key is access to paid models under your balance. If it leaks, someone else's requests are billed to your account, and the only way to notice is your spending history. Two simple restrictions cover the most common case:
- the key is embedded in a bot or an app that runs on one server — bind it to that server's address, and a stolen copy used from another machine stops working;
- the key is issued for a specific job — leave only the tools it needs, say chat and images, and turn off video, audio and everything else so they are not used "while we're at it".
Where to set the restrictions
- Open the API keys page.
- Under the key you need, press "Restrictions".
- Fill in the allowed IP list and untick whatever the key must not use.
- Press "Save" — the restrictions start working right away.
Settings belong to a particular key: each key has its own address list and its own set of tools. The restrictions work in both the light and the dark theme of the page.
Allowed IP addresses
The address field takes one or several IPs — one per line, up to 50 in total. Leaving it empty means the key is accepted from any address, as before: the rule kicks in only once the list is not empty.
The check uses the real client address, even when requests reach us through a proxy or a server layer — so binding to a server works in setups where the app sits behind a load balancer too. If the server's address changes, just add the new one to the list and save.
Available tools
Below the address list is the tool tree. The top level holds five categories: LLM (chat models), Images, Video, Audio and Other. Unticking a category disables it entirely; with the category on, the ticks inside work per tool — you can keep a couple of specific models and block the rest.
Everything is on by default. We store only what is switched off, so new tools and models we add later are available to the key at once — no need to enable them.
What happens to a blocked request
A request from an address that is not on the list, or to a disabled tool, gets a 403 response with a clear reason, and it is rejected before the model is called — no money is spent on such a call.
Service requests — balance check, model list and API reference — are not restricted: they stay available with any key so that an app can always read its balance and the catalogue.
Where the restrictions apply
Key restrictions are honoured on every execution path: the public API, the MCP server and voice sessions. You cannot disable one mode of operation and allow another — the check runs against the actual tool that executes the request.
Who needs this
Anyone who takes a key beyond their own computer: bot and mobile app developers, teams sharing one key across services, and those giving contractors access for a project. Restrictions are not about distrust — they simply make a key leak cheap.
Frequently asked questions
Can I specify an address range or a subnet?
No, individual addresses are listed — up to 50. If you have more or they keep changing, review the task: usually binding the key to one permanent server is enough.
What if I leave the list empty?
The key works from any address, exactly as before the restrictions. The rule applies only when the list is filled in.
Are the balance, the model list and the docs restricted?
No. These are service requests, available with any key — otherwise an app could not check its balance or list the models.
Do I need to enable new models manually?
No. Only what you untick is disabled; everything else, including new tools, works with the key right away.
Can I change the restrictions later?
Yes, at any time. Open "Restrictions" under the key, adjust the list or the ticks and save — the change applies to the next requests.