InstaAlert Engine™ — Network Provisioning Guide

1. The Problem You're Solving Every Day

Every new device, every new tenant, every new integration requires network configuration:

Task	Traditional Approach	Time
Add new tenant	Create VLAN, configure trunk ports, add ACLs, update firewall	2-4 hours
Add new device type	Firewall rules, NAT config, routing updates, test connectivity	1-2 hours
Enable cross-system coordination	Inter-VLAN routing, firewall exceptions, custom integrations	4-8 hours
Onboard new site	Replicate all above for every tenant/device combination	Days

The complexity compounds. More tenants, more devices, more rules. Every integration is a network problem.

2. The Shift: Network Config → API Registration

InstaAlert Engine moves segmentation from the network layer to the application layer:

Traditional	With InstaAlert Engine
VLAN per tenant	Tenant ID in API registration
ACL per device pair	Capability-based routing
Firewall rules per integration	Webhook URL in device config
Routing tables per segment	Campus Graph location hierarchy
Hours of configuration	One API call

The Key Insight

Devices don't talk to each other anymore. They talk to the engine. The engine handles routing, isolation, and coordination.

3. Device Registration: Step by Step

1

Device connects to network (any network)

The device only needs internet access. No special VLAN assignment. No trunk port configuration. Standard DHCP or static IP on any segment.

Requirement

HTTPS outbound to InstaAlert Engine API (port 443)

2

Device registers via API

The device (or its controller) calls the registration API with tenant, location, and capabilities:

POST /api/v1/devices
Authorization: Bearer sk_live_tenant_api_key

{
  "type": "access_point",
  "tenantId": "tenant-a",
  "location": {
    "building": "Engineering Hall",
    "floor": "2",
    "zone": "West Wing"
  },
  "capabilities": ["broadcast_ssid", "client_isolation", "power_adjust"],
  "webhookUrl": "https://controller.example.com/ap/12345/cmd"
}
          

3

Engine assigns to Campus Graph

The device is now part of the location hierarchy and isolated to its tenant:

// Device is now in:
Tenant A → Engineering Hall → Floor 2 → West Wing → AP-12345

// Automatically isolated from:
Tenant B (different API key = no visibility)
Other buildings (location-based routing)
          

4

Device receives events via webhook

When events occur that match the device's location and capabilities, the engine calls its webhook:

// Engine sends to device webhook:
POST https://controller.example.com/ap/12345/cmd

{
  "event": "emergency_mode",
  "action": "enable_guest_ssid",
  "priority": "high",
  "location": "Engineering Hall Floor 2"
}
          

4. Device Types You Can Register

Any device with HTTP or webhook capability can participate:

📡 WiFi Access Points

SSID management, client isolation, power levels

"type": "access_point"

🖥️ Display Screens

Alert display, evacuation maps, announcements

"type": "display_screen"

🚪 Door Controllers

Lock, unlock, access control

"type": "door_controller"

🔊 PA Systems

Audio announcements, zone control

"type": "pa_system"

❄️ HVAC Controllers

Temperature, ventilation, zone control

"type": "hvac_controller"

💡 Lighting Controllers

On/off, dimming, schedules

"type": "lighting_controller"

📹 Camera Systems

Recording triggers, PTZ control

"type": "camera_system"

🔬 Lab Equipment

Safety interlocks, status reporting

"type": "lab_equipment"

5. Multi-Tenant Example: 3 Tenants, 50 Devices, Zero VLANs

A

Tenant A: University IT

# 20 devices registered with Tenant A API key
API Key: sk_live_university_it_xxx

# Devices see only Tenant A locations and events
# Cannot access Tenant B or C data
          

B

Tenant B: Research Lab

# 15 devices registered with Tenant B API key
API Key: sk_live_research_lab_xxx

# Completely isolated from Tenant A and C
# Own Campus Graph, own events, own webhooks
          

C

Tenant C: Medical Center

# 15 devices registered with Tenant C API key
API Key: sk_live_medical_center_xxx

# Full isolation, own compliance tracking
# HIPAA-ready segmentation without network changes
          

What You Didn't Configure

No VLANs created
No ACLs written
No firewall rules added
No routing tables updated
No inter-VLAN policies

6. WiFi/AP Provisioning Specifically

Access points are a perfect fit for API-based provisioning:

1

Register AP with location

POST /api/v1/devices

{
  "type": "access_point",
  "tenantId": "campus-network",
  "location": {
    "building": "Library",
    "floor": "3",
    "zone": "Study Area"
  },
  "capabilities": [
    "broadcast_ssid",
    "client_isolation",
    "band_steering",
    "power_adjust",
    "guest_network"
  ],
  "metadata": {
    "mac": "AA:BB:CC:DD:EE:FF",
    "model": "AP-500",
    "controller": "wlc-01.campus.edu"
  },
  "webhookUrl": "https://wlc-01.campus.edu/api/ap/AABBCCDDEEFF"
}
          

2

AP receives orchestration commands

When an event triggers that affects Library Floor 3:

// Engine sends to AP webhook:
{
  "event": "high_density_mode",
  "trigger": "event_scheduled",
  "actions": [
    { "capability": "power_adjust", "value": "high" },
    { "capability": "band_steering", "value": "prefer_5ghz" },
    { "capability": "guest_network", "value": "enable" }
  ]
}
          

Controller Integration

For existing WiFi infrastructure, register the controller as the webhook endpoint. The controller translates API commands to vendor-specific protocols (CAPWAP, proprietary, etc.).

7. What Changes in Your Workflow

Before	After
"New tenant needs a VLAN"	"New tenant gets an API key"
"Configure firewall for new device"	"Device registers with webhook URL"
"Set up inter-VLAN routing"	"Engine routes by location and capability"
"Troubleshoot connectivity issues"	"Check audit log for event delivery"
"Replicate config at new site"	"Register devices, same API"

8. Getting Started

Get API credentials — Contact us for tenant API key
Define your Campus Graph — Buildings, floors, zones
Register first device — Use sandbox to test
Verify webhook delivery — Send test event, confirm receipt
Scale — Register remaining devices via API or bulk import

Try the Sandbox

Visit the Developer Portal to test API calls with demo data before production deployment.