light logo
How to Create and Manage API Keys in Simbase

An API key authenticates your requests to the Simbase API. Every key carries a set of permissions chosen when you create it, and those permissions are fixed from then on. One key can serve several integrations, but a key per integration is the safer setup. Keys are created and managed in the dashboard, under Integrations → API.

Create an API key

  1. Sign in to dashboard.simbase.com.

  2. Go to Integrations → API.

  3. Click Create New API Key.

  4. Give the key a name that says what it is for, for example Usage Guard Toolkit. The name is only a label. It appears in your key list and nowhere else.

  5. Under Resources, set the permissions the key needs. See Permissions below.

  6. Click Create API Key, then copy the key.

Copy the key nowSimbase shows the key once, in a "Keep your key safe" dialog. Click the key to copy it, then store it in a password manager or your platform's secrets store. If you lose it, there is no way to see it again. Delete the key and create a new one.

Check the demo below for step by step instructions:

Permissions

Permissions are set per resource, at one of three levels. None means the key cannot touch that resource at all, and it is the default on every row. Read retrieves data and changes nothing. Write creates, updates and deletes, and selecting it also selects Read on the same row, because anything that writes has to read first.

Not every resource offers all three. Account and Usage are read-only, so they show None and Read. SIM card state, Reset, Registration and Auto-disable are actions rather than data, so they show None and Write.

The resource tree

Resource

  • All resources

  • Account

  • Usage

  • SIM cards

  • — SIM card details

  • — SIM card state

  • — Reset

  • — SMS

  • — Registration

  • — Auto-disable

  • Utilities

  • — Geo

  • Integrations

  • — Webhooks

Parent and child rows

SIM cards, Utilities and Integrations each have an arrow next to the name. Click it to expand the individual permissions underneath.

  • Setting a parent sets every child to the same level, or to the highest level that child offers. Setting All resources to Write gives Account and Usage Read, because Read is the most they support.

  • Setting a child on its own leaves the parent showing nothing selected. That is expected. A parent only displays a level when all of its children agree.

Choosing a level

Grant the least the integration needs. A key that can only read usage cannot disable a SIM if it leaks.

The integration…

In the API reference these appear as scope names built from the same tree. SIM card details maps to simcards.details:read and simcards.details:write.

Advanced settings

Turn on Show advanced settings for two optional fields. Both can be left blank.

IP restrictions

Limits the key to a single trusted IP address or a range in CIDR notation. Requests from any other address are rejected. Leave the field blank for no restriction. The key list then shows 0.0.0.0/0 under Allowed IPs, which means any address.

Fixed addresses onlyUse an IP restriction when the integration runs from a fixed address, such as your own server or a NAT gateway. Hosted automation platforms like Make.com and Zapier call from a rotating pool of addresses, so restricting the key by IP will break them.

Expires in (number of days)

The number of days from creation until the key stops working. Enter 31 and the key expires 31 days from now. Leave the field blank and the key never expires.

Short-lived keys are worth using for one-off migrations, contractor access, and anything you would otherwise have to remember to revoke.

Manage your keys

The API list shows every key on the account: its name, a truncated Key ID, the permission level it was created with, when it was last used, and its IP restriction. Last API call is shown in your account timezone, and Allowed IPs reads 0.0.0.0/0 where there is no restriction.

The Key ID is only there to tell keys apart. It is truncated and cannot be used to authenticate.

Permissions are fixed at creation and cannot be edited afterward. To change what a key can do, create a new key with the permissions you want, switch your integration over, then delete the old one.

The three-dot menu at the end of each row has a single option: Delete. A deleted key stops working immediately, and requests using it fail authentication.

Using the key

Send the key as a bearer token on every request:

Request

GET /v2/simcards HTTP/1.1
Host: api.simbase.com
Authorization: Bearer YOUR_API_KEY

Full endpoint documentation lives at developer.simbase.com.

Common questions

No. Permissions are set at creation and fixed from then on. Create a replacement key with the permissions you need, move your integration across, then delete the old key.

No. The full key is shown once, when it is created. The list only shows a truncated Key ID, which cannot be used to authenticate. Delete the key and create a new one.

That the key has no IP restriction and will accept requests from any address. It is what you get when you leave the IP restrictions field blank.

Nothing stops you reusing one key across several integrations, but a key per integration is worth the extra minute. It lets you scope each one to only what it needs, tell from the Last API call column which is still in use, and delete or rotate one without breaking the others. A shared key has to carry the union of everyone's permissions, and revoking it takes down everything at once.

Related

light simbase logo

© 2026 Simbase. All rights reserved.

Pricing
OverviewSupport plans
Support
Submit a TicketStatus
Privacy & SecurityBlogIndustriesContact