Netbox API token scope enforcement for IP address creation in test environment

Question

Netbox API token‑based authentication
The goal is to confirm that an API token created with only the 'read' scope blocks write‑like operations such as creating a new IP address through the /api/ipam/ip-addresses/ endpoint when testing an integration without production credentials.
However, anecdotal reports suggest that certain endpoints may still permit implicit creation of related objects (e.g., temporary IP allocations) even when the token lacks write permissions, because the permission check is bypassed for objects already present in the request payload.
This uncertainty raises questions about the reliability of scope‑based restrictions in a test environment and whether additional constraints are needed to prevent unintended state changes.

Does the IPAM endpoint enforce the read scope for POST requests that include a new address?
Are temporary allocations or cached objects subject to the same scope restrictions?
What additional token scopes or endpoint‑specific permissions are required to reliably block unintended state changes in a test environment?

Tasadduq Burney · Answer

Direct answer
A token that only has the read scope (i.e., no ipam.add_ipaddress permission) will be rejected with HTTP 403 Forbidden when you try to POST a new IP address to /api/ipam/ip-addresses/. Temporary allocations or cached objects are subject to the same check – they also require the add permission and will be blocked.
Confirmed facts

Netbox evaluates token scopes before entering the view logic; missing ipam.add_ipaddress results in a 403 response.
The setting AUTH_TOKEN_PERMISSIONS (default True) must be enabled for token scopes to be honored.
User‑level permissions do not override a missing token scope.

Likely explanation
If a token lacks the specific add permission for the IPAM IP‑Address model, Netbox’s permission middleware returns PermissionDenied early, preventing any creation logic – including paths that might try to create temporary objects as part of the request.
Steps to reliably block unintended state changes in a test environment

Create or edit an API token in Users → Tokens.
Under Object permissions, select IPAM → IP Addresses and ensure only the view (read) permission is checked; leave add, change, and delete unchecked.
Save the token and use it in the Authorization: Token <token> header.
Verify by sending a test POST, e.g.:

curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Token $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"address":"192.0.2.1/32"}' \
     https://netbox.example.com/api/ipam/ip-addresses/

Expect a response code of 403. A 201 indicates the token has unwanted add scope.
Missing diagnostic detail
If you are running Netbox < 3.2, the token‑scope enforcement behavior differed; confirming your Netbox version would change the recommendation.

Netbox API token scope enforcement for IP address creation in test environment

Netbox API token‑based authentication

1 answer

Direct answer

Confirmed facts

Likely explanation

Steps to reliably block unintended state changes in a test environment

Missing diagnostic detail

Your perspective belongs here.

1 question comment

Key Point

Practical Check