IP Access Control

How It Works

IP access control operates in one of two modes, configured per-tenant:

Enabling IP Access Control

Enable IP access control by updating your tenant settings. The example below enables allowlist mode with a mix of individual IPs and CIDR ranges — only these addresses will be permitted to log in.

PATCH/api/v1/settings🔒 Auth

Enable IP access control in allowlist mode with permitted addresses.

RequestResponse

cURLJavaScriptPythonGoPHP

curl -X PATCH https://id.vyntech.com.au/api/v1/settings \ -H "Authorization: Bearer eyJhbGciOiJFZERTQSIs..." \ -H "Content-Type: application/json" \ -d '{ "ip_access": { "enabled": true, "mode": "allowlist", "addresses": [ "203.0.113.42", "203.0.113.100", "10.0.0.0/8", "172.16.0.0/12", "192.168.1.0/24" ] } }'

Request Body

{
  "ip_access": {
    "enabled": true,
    "mode": "allowlist",
    "addresses": [
      "203.0.113.42",
      "203.0.113.100",
      "10.0.0.0/8",
      "172.16.0.0/12",
      "192.168.1.0/24"
    ]
  }
}

CIDR Range Examples

CIDR notation lets you specify entire network blocks instead of individual IPs. Here's a quick reference for common patterns:

Switching to Blocklist Mode

If you want to allow all IPs except specific known-bad actors, switch to blocklist mode. Any IP in the list will be denied; all others are permitted.

PATCH/api/v1/settings🔒 Auth

Switch to blocklist mode with known malicious IPs.

RequestResponse

cURLJavaScriptPythonGoPHP

curl -X PATCH https://id.vyntech.com.au/api/v1/settings \ -H "Authorization: Bearer eyJhbGciOiJFZERTQSIs..." \ -H "Content-Type: application/json" \ -d '{ "ip_access": { "enabled": true, "mode": "blocklist", "addresses": [ "185.220.101.0/24", "23.129.64.0/24", "198.51.100.50" ] } }'

Request Body

{
  "ip_access": {
    "enabled": true,
    "mode": "blocklist",
    "addresses": [
      "185.220.101.0/24",
      "23.129.64.0/24",
      "198.51.100.50"
    ]
  }
}

Adding & Removing IPs

Updates to the address list are replace-based, not additive. When you PATCH the addresses array, the entire list is replaced with the new value. To add or remove entries, follow this pattern:

• 1.Read the current settings to get the existing address list
• 2.Modify the array in your application (add new entries or filter out removed ones)
• 3.Write the full updated array back via PATCH

PATCH/api/v1/settings🔒 Auth

Replace the full address list (read → modify → write pattern).

RequestResponse

cURLJavaScriptPythonGoPHP

# 1. Read current settings CURRENT=$(curl -s https://id.vyntech.com.au/api/v1/settings \ -H "Authorization: Bearer eyJhbGciOiJFZERTQSIs...") # 2. Add new IP to existing list (using jq) UPDATED=$(echo $CURRENT | jq '.ip_access.addresses += ["198.51.100.0/24"]') # 3. Write back curl -X PATCH https://id.vyntech.com.au/api/v1/settings \ -H "Authorization: Bearer eyJhbGciOiJFZERTQSIs..." \ -H "Content-Type: application/json" \ -d "{\"ip_access\": {\"addresses\": $(echo $UPDATED | jq '.ip_access.addresses')}}"

Request Body

{
  "ip_access": {
    "addresses": [
      "203.0.113.42",
      "203.0.113.100",
      "10.0.0.0/8",
      "172.16.0.0/12",
      "192.168.1.0/24",
      "198.51.100.0/24"
    ]
  }
}

Safety Considerations

• •Always include your admin IP or CIDR range before enabling allowlist mode.
• •Keep a break-glass API key (with a fixed, known IP) that can bypass restrictions if needed.
• •Test configuration changes in a staging tenant before applying to production.

Combining with Risk Engine

IP access control and the risk engine are complementary security layers that can run simultaneously:

A typical layered setup: use allowlist mode to restrict logins to your corporate network, then let the risk engine catch anomalies within that network (compromised devices, credential stuffing from inside the VPN, unusual login times).

Best Practices

What's Next