Endpoint and customer context
Read tenant-scoped customers, sites, endpoints, availability, inventory, alerts, and operational summaries without supplying a tenant selector.
RMM API · signed webhooks · tenant scoped
Connect Nizlo to the workflows your MSP already trusts.
Use permission-limited personal access tokens for external automation and signed outbound webhooks for event-driven work. The same tenant, role, and audit boundaries remain in force outside the browser.
Current API boundary
The management API is versioned under /api/v1. Browser sessions manage tokens; bearer credentials cannot manage their own token lifecycle. Agent and enrollment credentials are separate and are not interchangeable with technician API tokens.
Tickets, jobs, and activity
Work with ticket queues, inspect job history, and review auditable technician activity according to the token holder's current role and selected token permissions.
Patching and reports
Inspect patch posture and policies, request supported report exports, and keep automation inside the same permission checks used by the Nizlo console.
Outbound webhooks
Receive signed device, alert, script, and patch events through durable deliveries with test, delivery-history, and failed-delivery retry controls.
Personal API access
Short-lived authority that stays attached to a person.
- Choose 30, 90, 180, or 365-day expiration
- Select only permissions the technician already holds
- Receive the full 256-bit token exactly once
- Revalidate expiry, revocation, technician state, and role authority on every request
- Revoke tokens from the authenticated account console
Read endpoints with a bearer token
curl \
-H "Authorization: Bearer nizlo_pat_…" \
"https://app.nizlo.com/api/v1/devices?page=1&pageSize=25"Use the narrowest token permissions that satisfy the workflow. Responses remain tenant scoped; supplying another tenant ID does not widen access.
Event-driven workflows
Subscribe only to events you are ready to handle.
New webhook endpoints begin at the current tenant audit cursor, so enabling an integration does not unexpectedly replay older activity. Test deliveries use the same signing, retry, and delivery-diagnostics path as operational events.
device.createddevice.onlinedevice.offlinealert.createdalert.resolvedscript.completedpatch.completedWebhook verification
Verify X-Nizlo-Signature: v1=<hex HMAC-SHA256> over <timestamp>.<exact request body>, reject stale X-Nizlo-Timestamp values, and deduplicate X-Nizlo-Delivery. Any 2xx response acknowledges a delivery.
Frequently asked questions
Integration details without roadmap claims.
Does Nizlo provide an RMM API?
Yes. Nizlo management endpoints are versioned under /api/v1. Authenticated external automation can use a personal access token created by an active technician. Interactive OpenAPI documentation may be access-restricted in production.
How are Nizlo API tokens scoped?
A technician selects 1–32 permissions and a 30, 90, 180, or 365-day lifetime. Effective access is always the intersection of those token permissions and the technician's current role, so removing role authority takes effect immediately.
Does Nizlo support service accounts?
Not currently. Personal access tokens remain accountable to an active technician identity and tenant. Independent non-human service accounts are a later milestone and should not be assumed during an integration evaluation.
How are webhook deliveries verified?
Nizlo signs the timestamp and exact request body with HMAC-SHA256. Receivers verify X-Nizlo-Signature, reject stale timestamps, and deduplicate the X-Nizlo-Delivery identifier.
Validate with a controlled pilot
Start read-only, verify signatures, then expand deliberately.
Start the 14-day no-card trial, create a narrowly scoped token, and prove one workflow before connecting broader operational authority.