Simbase's built-in Usage Limits check usage when CDRs arrive from the network, typically every few hours. If you need tighter checks (every 30 minutes, every 5 minutes, on demand) or custom logic (notify on warning, disable only certain SIMs, exclude business hours), the Usage Guard Toolkit is a no-code automation you can build yourself using the Simbase API and Make.com.

This article covers what the Toolkit does, when it's the right answer, and how to set it up.

What the Toolkit does

A scheduled automation that:

1. Polls Simbase's usage API for every SIM in your account (or a filtered subset)

2. Compares usage for each SIM against a threshold you define

3. Disables SIMs that exceed the threshold via the Simbase API

4. Notifies you (Slack, email, webhook, Google Sheets log, whatever you wire up)

It's built on Make.com because it's visual, no-code, and most customers can get it running in under 15 minutes. The same logic works in Zapier, n8n, or a custom script. Make.com is just the path Simbase has documented.

When the Toolkit is the right answer

Pick the Toolkit over (or alongside) the native Usage Limits when you need:

• Shorter check intervals. Native Limits run on CDR arrival; the Toolkit can run as often as your automation platform allows

• Custom notification flows. Want a Slack ping at 80% of cap and disable at 100%? Build it

• Multi-tier thresholds. Warn, then disable, then alert ops, all in one flow

• Business-rule conditions. Skip disabling on weekends, ignore certain tags, only disable test SIMs, and so on

• Cross-system integration. Sync usage to your CRM, log every disable event to a data warehouse, and so on

Stick with the native Usage Limits when:

The default behaviour (disable on cap exceeded, optional monthly auto-reset) is what you want.

• You don't want to maintain a third-party automation

• You don't need custom notifications or business logic

You can use both: native Usage Limits as a baseline, with the Toolkit handling edge cases. They don't conflict.

What the Toolkit cannot do

Same constraint as native Usage Limits: it depends on Simbase usage data, which depends on CDR arrival from the network. A Toolkit running every 5 minutes is still working from CDRs that may be hours old.

For a true real-time hard cap, you'd need to monitor data usage on the device itself and have the device shut down the connection when it hits the limit. That's outside what Simbase or Make.com can deliver.

Blueprint

If this looks complicated, don't worry. This tutorial will guide you step-by-step through building your own Usage Guard Toolkit. You don't need to write any code, and we'll show you exactly how to set it up using Make.com.

Setting up the Toolkit

Step 1: Choose your automation platform

Make.com is recommended for first-time users:

• Visual flow builder, no coding required

• Free tier is enough for small fleets

• Paid tiers handle larger fleets and shorter intervals

Zapier, n8n, Pipedream, or a custom Python/Node script all work. The rest of this guide uses Make.com; the same modules and logic apply elsewhere.

Step 2: Create a Simbase API key

1. Sign in to dashboard.simbase.com

2. Go to Integrations → API Keys

3. Click Create API Key

4. Name it Usage Guard Toolkit (or similar)

5. Enable Write permission. Leave other settings at default

6. Click Create and copy the key

Treat the API key like a password. Anyone with this key can manage your SIMs. Store it in your automation platform's secrets / connection manager, not in plain text.

Step 3: Import the Make.com blueprint

Simbase publishes a pre-configured blueprint you can import in one step:

1. Download the blueprint (look for Simbase-Usage-Guard-Toolkit.blueprint.json, ~27 KB).

2. In Make.com, create a new scenario

3. Use Import Blueprint and select the downloaded JSON

4. Open each of the three HTTP modules and replace the placeholder YoUrApiKeYHeRe with your API key

5. Adjust the usage threshold in the comparison module (default example: 10 GB)

6. Test the scenario manually before enabling the schedule

The blueprint handles the basic flow: fetch usage → iterate over SIMs → check against threshold → check current SIM state → disable SIMs that aren't already disabled.

Step 4: Customise for your needs

The blueprint is a starting point. Common customisations:

• Threshold conversion. The API returns usage in bytes, in binary gigabytes: 1 GB = 1,073,741,824 bytes, so 10 GB = 10,737,418,240. This is not the same convention as the dashboard, where a Usage Limit of 1 GB means 1,000 MB. A 10 GB Toolkit threshold is roughly 7% higher than a 10 GB Usage Limit — if you want the two to line up, set the Toolkit comparison to 10,000,000,000 instead

• Pagination. Needed above roughly 500 SIMs. See Pagination for large fleets below

• Notifications. Add a module to send a Slack/email/webhook when a SIM exceeds the threshold

• Tag filter. Apply the check only to SIMs with a specific tag (for example, production only, exclude test)

Iterating over the SIM array

The usage API returns an array of SIM objects under the data.simcards field. To process each individually in Make.com:

1. In the HTTP module, set Parse response to Yes

2. Add an Iterator module

3. Set the iterator's array to data.simcards from the HTTP response

Each iteration is then a single SIM you can compare and act on.

Pagination for large fleets

The blueprint doesn't include pagination by default. It works for fleets up to a few hundred SIMs without modification. For larger fleets:

• Check the API response for "has_more": true

• If true, read the cursor value

• Make another request to /v2/usage/simcards?cursor=<value>

• Repeat until has_more is false

In Make.com, this is implemented with a Repeater and an HTTP request loop, which is outside the scope of the basic blueprint.

Disclaimer

The Usage Guard Toolkit is do-it-yourself. While it uses the official Simbase API, Simbase does not take responsibility for:

• Missed caps due to CDR or API delays

• SIMs not being disabled in time

• Resulting overage, costs, or service interruption

Test your setup carefully, monitor it regularly, and don't rely on it as your sole safeguard for SIMs where cost overruns would be catastrophic.

Common questions

Related

• Usage Limits, the native, lower-friction alternative

• Auto-Disable function, calendar-based disable

• API, the underlying interface

• Tags, useful for scoping the Toolkit to subsets of the fleet