Paxton Net2

Paxton Net2 is one of the most widely deployed commercial access-control platforms. This driver talks to an on-site Net2 server over its local REST API (/api/v1/…, HTTPS on port 8080 by default), authenticating with a Net2 operator login via OAuth2 and issuing momentary door release commands, alongside read access to the door list, user list, and event log.

One GEM device represents a single Net2 server. Each door you want to release from GEM becomes a zone whose address is the Net2 door id.

Access control is life-safety adjacent

A door-release command unlocks a physical door. Test every zone binding against a known, non-critical door first, and confirm the Net2 operator account you use is scoped to only the doors GEM should ever open. GEM's role-based access control should further restrict who can invoke the open command in the UI.

Prerequisites

• Net2 server software (v6.x or newer) running on-site with the Net2 API feature enabled in the Net2 server configuration utility. The API is a licensed feature — if it is not enabled, no REST calls will succeed regardless of credentials.
• A Net2 operator account (username + password) with permission to open the doors GEM will control. Create a dedicated, least-privilege operator for GEM rather than reusing an administrator login.
• The Net2 server reachable from the GEM host over HTTPS on the API port. Open the port (default 8080) through the Net2 host's Windows firewall.
• If your Paxton API registration issues a client GUID, have it ready for the optional client_id attribute. Many on-prem deployments do not require one.

Setup

1. Confirm the Net2 API is enabled and note the server IP and API port. From the GEM host, a browser hit to https://<net2-host>:8080/ should return a TLS response (a self-signed-cert warning is expected and fine).
2. In GEM admin, add a device with the Paxton Net2 (Access Control) driver, placed under an Access or Security subsystem. Only one GEM device per Net2 server — doors are added as zones underneath.
3. Set the device attributes:
   • ip — Net2 server host or IP.
   • port — API port. Default 8080.
   • protocol — https (the Net2 API is HTTPS).
   • username / password — the Net2 operator credentials.
   • client_id — only if your Paxton API registration enforces a client GUID. Leave blank otherwise.
4. Save and reload the device. On boot the driver mints an OAuth2 bearer token, loads the door list, and starts polling for reachability.
5. Run the get_doors command to list every door id and name Net2 knows about.
6. For each door you want to release, add a zone under the same subsystem, bind it to the Net2 device, and set its address to the door id (integer) from get_doors.

One zone per door — created by you

GEM does not auto-create zones from Net2 discovery. A door is only actionable once a zone whose address matches its Net2 door id exists and is bound to the Net2 device. Copy the exact id from get_doors.

Authentication flow

The token typically lives about an hour; the driver renews it a minute early and also re-authenticates automatically on any 401.

Attribute reference

Device

Attribute	Required	Description
ip	yes	LAN IP / hostname of the Net2 server.
username	yes	Net2 operator login with door-open permission.
password	yes	Operator password (stored encrypted).
port	no	API port. Defaults to 8080.
protocol	no	http or https. Defaults to https.
client_id	no	Client GUID from a Paxton API registration, if your deployment enforces one.
status_interval	no	Reachability poll interval in ms. Defaults to 30000.

Zone

Attribute	Required	Description
address	yes	Net2 door id (integer) from get_doors, e.g. 917521.

Commands

Command	What it does
open	Momentary door release (grant access) for the zone's door id.
get_doors	Enumerate doors — returns id + name for populating zone addresses.
get_users	Read the Net2 user list (read-only).
get_events	Read recent Net2 access events (read-only).

Door release maps to Paxton's published POST /api/v1/commands/door/{id}/open endpoint. Confirm the path against your Net2 API version if a release ever returns an error despite a valid door id.

Zone address format

The zone address is the numeric Net2 door id exactly as get_doors reports it. Door ids are stable but not sequential — always read them from get_doors rather than guessing.

Known limitations

• Momentary release only. This driver implements timed door release (grant access). Hold-open and re-lock commands are not wired — they vary by Net2 configuration and firmware and were left out rather than guessed. Use a Net2 timezone/schedule for scheduled unlocks.
• No live door-monitor state. Net2 v1 surfaces held-open, forced, and door-contact state through its event stream, which this driver does not subscribe to. The status poll only confirms that each bound door id still exists on the server (zone reachability). get_events gives a read-only snapshot but is not turned into per-door state.
• get_events returns unfiltered recent activity. On a large site this can be a lot of data; query filtering is not yet exposed.

Troubleshooting

Symptom	Check
401 / cannot authenticate	Confirm the operator username/password are valid Net2 credentials, and that the Net2 API feature is enabled and licensed in the server configuration utility.
Connection refused / timeout	Verify the API port (default 8080) is open on the Net2 host firewall and HTTPS is reachable from the GEM server.
TLS / certificate error	Expected — the Net2 server presents a self-signed certificate, which GEM accepts. If it still fails, confirm you set protocol to https.
open returns an error for a valid-looking zone	Run get_doors and confirm the zone address matches a real door id, and that the operator account has permission to open that specific door.
Token keeps expiring / intermittent 401s	Normal token lifetime is ~1 hour; the driver re-authenticates automatically. Persistent failures usually mean the operator account was disabled or its permissions changed on the server.