API keys
Create and manage REST API keys for iApprove — control which companies and resources each key can access, lock keys to specific IP addresses, and review where each key is used or abused.
API keys
The API Keys tab (Tenant Settings → API Keys) is where tenant administrators create and manage API keys for the iApprove REST API.
API keys are required to authenticate machine-to-machine integrations — for example, pulling approved invoices into an ERP, or syncing creditor data with an accounting system. The API Access add-on must be enabled on at least one company before API keys can be created.
Key table
| Column | Description |
|---|---|
| Name | A human-readable label for the key (e.g. "Production ERP integration") |
| Key ID | The key's unique identifier — the iak_<keyid>_… prefix of the full token |
| Scopes | Which resources (invoices, creditors, documents) the key can access, and at what level (Read / Write / Delete) |
| Companies | Which companies this key is authorised to access |
| Expires | Expiry date, or "Never expires" |
| Last used | When the key was last used to make an API request |
| Status | Active / Expired / Revoked. A red warning badge appears here when the key has had blocked or suspicious attempts in the last 24 hours |
Creating a key
Click Create API key. In the form:
- Name — Give the key a descriptive name so you can identify it later.
- Expiry — Set an expiry date (default: one year from today), or check "Never expires" for keys that should not rotate automatically.
- Companies — Select which companies the key can access. Only companies with the API Access add-on enabled appear in the list.
- Permissions — For each resource (invoices, creditors, documents), choose the access level: None, Read, Write, or Delete. Grant only the minimum required.
- Allowed IPs — Optionally restrict the addresses the key may be used from (see below).
After saving, the full API token is shown once in a modal dialog — copy it immediately and store it securely (a password manager or secrets vault). The secret cannot be retrieved again; you will need to rotate the key if it is lost.
Restricting a key to specific IP addresses (firewall)
In the Allowed IPs section of the key form you can lock a key so it only works from addresses you trust — for example your server's fixed public IP, or your office network's address range.
- Click Add rule to add an entry. Each rule is either a Single IP (e.g.
203.0.113.7) or an IP range with a from and to address (e.g.203.0.113.1–203.0.113.254). - Add as many rules as you need — a request is allowed if it matches any rule.
- Use Add my current IP to insert the address you are connecting from right now.
- Add an optional note to each rule (e.g. "Office", "Production server") so you can recognise it later.
If you add no rules, the key is open and can be used from any IP address — so existing keys keep working exactly as before until you choose to lock them down.
Once rules are set, any request from an address outside the list is rejected with 403 Forbidden — both when obtaining an access token and on every data request. Because the check is applied to every call, you can truthfully tell auditors the key only works from your approved addresses. Tightening the rules takes effect within about 15 minutes (the lifetime of an already-issued access token).
Tip: most integrations connect from a single, stable server IP — add that one address and you are done. If your provider uses a pool of outbound addresses, add each one, or a range that covers them.
Key usage — "from where was this key used, or abused?"
Click the Usage icon (activity graph) on any key to open its usage log. This answers, per key, where it has been used and whether anyone has tried to misuse it. Each row is an hourly summary showing the date/hour, the IP address, the company, the outcome, and a count.
Outcomes include:
| Outcome | Meaning |
|---|---|
| OK | A successful, authorised call |
| Blocked IP | A request rejected by the key's IP firewall (it came from an address not on the allow-list) |
| Bad secret | Someone presented this key's ID with the wrong secret — a sign the key ID is known and the secret is being guessed |
| Expired / Revoked | An attempt to use a key that is no longer valid |
Use the Show filter to switch between All activity and Abuse only. The tenant-wide Abuse button at the top of the tab gathers blocked and suspicious attempts across all of your keys in one place, and the red badge on a key row flags abuse in the last 24 hours at a glance.
Rotating a key
Click the rotate icon on an active key to generate a new secret. The old secret is immediately invalidated; any integration using it will start receiving 401 Unauthorized until updated. The rotation is recorded in the activity log.
Revoking a key
Click the revoke icon (slash through circle) to permanently disable a key. Revoked keys cannot be re-activated — create a new key instead. A revoked key can be deleted to remove it from the list.
Activity log
Expand Activity log at the bottom of the tab to see a timeline of administrative changes to your keys: creation, editing, rotation, revocation, and deletion. The log shows who made each change, from which IP, and when. (This is separate from the per-key Usage log above, which records where each key is actually used.)
Security recommendations
- Use a separate key per integration — never share one key across multiple systems.
- Lock each key to the IP address(es) it will be used from.
- Set an expiry date and rotate on a schedule (annually at minimum).
- Grant only the scopes the integration actually needs (principle of least privilege).
- Check the Usage log periodically, and act on any blocked or "bad secret" attempts.
- Revoke keys immediately when an integration is decommissioned or a secret is compromised.