Help
API clients, keys and automation
Administrators use API keys to issue a named client key, optionally bound to one customer with an expiry. Copy its secret once into a secret manager; it cannot be retrieved again. Use Authorization: Bearer followed by the key, never put it in URLs or logs. Choose only the required read or write scopes. Secret reveal and rotation have separate scopes; keys:admin allows key administration but cannot delegate broader customer access, scopes or expiry than the caller. An enabled staff owner is required throughout a key's life. Revoke a key immediately if exposed, then issue a replacement. Revoking an issuing key also blocks every key delegated from it. Revocation takes effect on subsequent database operations. Named keys allow 60 calls per minute; wait the Retry-After seconds after a 429 response. Lists return 25 records per page, with page starting at zero. OpenAPI at /api/v1/openapi.json documents the resource paths. Customers, sites, networks, consent, CA sync status, archive and restore, deployment scripts and audit use the same database rules as the console. Login events currently return an empty list with ingestion unavailable, because event collection is not yet active. API consent redirects require the versioned callback URL to be allowed in the sync app; callbacks use signed one-time state and recheck the key without exposing the key secret. No customer settings are written by this service.
Customer consent and certificate sync
An authorised staff operator starts consent for a saved customer tenant. Complete the Microsoft administrator consent prompt in the same signed-in staff browser within ten minutes. A link cannot be reused or used for another tenant. The sync application requests only read access to Cloud PKI certificate authorities. It never deploys customer settings. Sync checks due customers every five minutes and refreshes successful snapshots hourly and keeps the last complete certificate snapshot if a read fails. Awaiting CA means no certificate authority was returned; stale means the last successful read is over 24 hours old; the NOC alert evaluator flags snapshots older than 24 hours under the business-hours alert policy. Active customers continue using their last good snapshot regardless of age or a failed sync. Failed requires an operator to check consent or backend configuration. Production sync stays unavailable until its dedicated backend certificate is configured.
Staff customers and sites
Sign in with your staff Microsoft account, then verify with an authenticator. For first-time setup, scan the displayed QR code and enter the six-digit code. Restarting an unfinished setup replaces its QR code, so scan the newest one. Your administrator must enable your staff membership. Current membership controls access across the console and consent workflow; disabling membership removes access, and viewers cannot start or complete consent. Viewers can read customers and audit history; operators and administrators can make changes. Add the customer's exact Microsoft tenant ID before starting consent. Add sites with RadSec or hardened UDP, an optional default VLAN and non-overlapping public source networks. IPv4 and IPv6 overlaps are refused across all customers. Secrets are masked until an operator reveals them for thirty seconds; reveal and rotation are audited. Disable a live site before editing or rotating its secret, and coordinate the change with the network engineer. Archive a departing customer to stop new certificate syncs and invalidate consent links. Existing sync work can finish. Their sites are disabled and excluded from the next host configuration bundle; host enforcement depends on adopting that bundle. Ask the customer to remove the sync application from their Microsoft tenant, because this console cannot remove it. Use Show archived customers and Restore customer to recover the record and history. Restoration keeps sites disabled and requires fresh administrator consent and a successful new sync before the previous CA can be trusted. Work started before archival cannot renew this trust. Go live remains unavailable until a freshly trusted customer CA, public network, secret and required valid certificates exist. Audit history identifies the affected customer, site and source network where applicable, with configuration details and no secret values. Audit history and customer lists use separate pages.
Generate and verify a customer deployment
Enter the expected tenant, exact existing root and issuing CA names, a stable owned profile prefix and Windows subject variables. Generation requires an authorised staff session. The script contains public configuration only; your customer Graph session stays in your own Cloud Shell. Copy the deployment SHA256 from the authenticated console and obtain the verifier independently from a trusted Zephyr release. Editing the configuration invalidates its download, including any generation still in progress. Generate again after making changes. Verify the downloaded script before execution; never take an expected digest only from an untrusted download. The default run reads only. Review its output before using Apply. Remove previews reverse-order removal; Apply with Remove removes only owned unassigned profiles. Keep the same tenant, names, prefix and subject variables when downloading an updated script. Ownership remains bound to those exact inputs across compatible releases; unsupported predecessor releases require manual review. Release and input digests are recorded separately in the generated download. Reruns refuse drift, duplicates, foreign ownership and assigned objects. Never run concurrent deployments. CA creation, other platforms, Wi-Fi, wired and device enrollment are unproven. Do not use this path to write the live Precision IT tenant without explicit approval.