← All guides

Use the API

Operator Tokens

The bearer credentials issued for this organization — console API keys and mobile-app enrolment tokens — listed, auditable and revocable in one place. SentinelOps keeps them here because a long-lived credential is a standing risk: it must be masked after issue, expire, carry a device limit, and be killable the instant it leaks. For the tenant it is the ledger of every non-password way into their console and fleet, with full visibility of what each token is, who created it, when it was last used and how often.

The table

Each token shows the User it is tied to, a masked value (ABCD-****-7F92), Type (console or mobile), Platform, Status, Created and Expires dates, Last used, use count, Device limit and who created it. A token’s full value exists only in the response that created it — the list never shows it again.

Generate a token — field by field

Generate token opens a form: User (or "not tied to a user"), Type (Mobile enrolment or Console API), Platform (Any / iPhone / iPad / Android), Valid for (hours, default 720, max 8760) and Device limit (default 1; 0 = unlimited). The token inherits the chosen user’s permissions, capped at your own, and is displayed once — with a QR for a mobile enrolment, or to copy for a console key.

Regenerate and new QR

Regenerate revokes the current token and issues a replacement immediately (anything using the old one stops working). New QR likewise issues a fresh token with its QR — because an issued token is never recoverable, a new QR necessarily means a new token and revokes the old one. Both actions confirm first.

Revoke and activity

Revoke (needs the revoke permission) kills a token at its next request. Activity opens the audit entries that mention the token — the action, the actor, the source IP and the result — so a suspicious use can be traced before or after revoking.

Automation

A library of vetted script templates you can run on an endpoint now or on a schedule, carrying an approval lifecycle so impactful scripts are reviewed before they execute. SentinelOps has it to turn routine operator work into reusable, governed building blocks rather than copy-pasted one-offs. For the tenant it is a curated, auditable catalog of what can be run against their machines, with an optional second-operator gate on every run. Templates and settings are per-tenant.

At a glance

The summary tiles count Templates, how many Categories they span, and whether Change approval is On or Off for this tenant. "Seed built-in catalog" adds the built-in templates to this tenant (existing ones are left untouched).

Change management

A checkbox — "Require approval for automation runs on this tenant". When on, every automation run needs a second operator to approve it before it dispatches; the setting saves immediately.

Template library

Platform tabs (All, Linux, Windows, macOS, Android, Cross-platform) each with a count — a specific-OS tab also surfaces cross-platform templates, and "All" groups each script under its OS then by category. Each template shows its name, OS, interpreter, description and an approval badge (approved / in review / rejected / draft).

Review a template

With automation.manage a "Review…" button moves a template through the Draft → Submit for review → Approve / Reject lifecycle with an optional note. An author cannot approve their own script; an unapproved script cannot be run without the execute-unapproved permission, so review is the gate that makes a template runnable by everyone.

Run a template

"Run…" opens a dialog: pick the Endpoint (the list is filtered to OS-matching devices), fill any template parameters, and optionally set a Schedule (leave blank to run now). The run is dispatched, scheduled, or queued for approval depending on the per-tenant setting, and is audited. "Edit" changes the saved template (shared with the Scripts library).

Scripts (fleet)

Dispatch one script across a group/tag selection of endpoints at once, with each job gated by approval, and keep a reusable library of scripts. SentinelOps has it so ad-hoc remediation scales to many machines without losing the two-person control and audit on executing code. For the tenant it is how a fix or check is rolled out fleet-wide safely; the selector is scoped to the current organization and the script is staged to a private temporary file on each endpoint, never inside a managed root.

At a glance

The summary tiles count Endpoints, how many are Online, and how many Groups exist — the pool you can target.

Dispatch a script — selectors

Device group (a dropdown of groups, or "Any group") and Tags (comma-separated, all must match) choose the targets. A live counter under the body shows how many endpoints match the selector, and Dispatch is disabled until at least one matches.

Dispatch a script — interpreter & lifetime

Interpreter is sh, bash, powershell or python3 (only interpreters an endpoint’s administrator allowlisted will actually run). Job lifetime is 1 hour, 6 hours or 24 hours — after which an unrun/unapproved job expires. The Script body is the code to run.

Approval model

If you are an administrator or engineer, the script.run jobs dispatch immediately under your authority and are audited under your name. Otherwise each job requires a second operator to approve it before it executes. Devices outside their maintenance window are skipped, and the toast says how many.

Script library

The built-in catalogue plus your own saved scripts, searchable. "Use" loads a script into the dispatcher above (and sets the matching interpreter); "Edit" changes the saved script; "New script" creates one. This is the same library shared with Automation.

Last rollout

After a dispatch, a panel lists each endpoint’s job and status; "Refresh status" re-polls them so you can watch the rollout move from awaiting-approval through succeeded/failed.