Issue, scope, and revoke an API key
Create a named integration credential with explicit capabilities, copy the one-time secret, and verify its lifecycle.
Before you start
- An integration purpose and owner.
- The relevant external surface permitted for this tenant and enabled in the deployment.
- MFA available for key creation.
Screenshots show the Rapport interface with example data. Use your organization’s devices and values. Select an image to view it at full size.
Inspect existing keys and permissions
Open Admin → API Keys. Check the key inventory for an existing credential associated with the intended integration. Inspect its scopes, expiry, last use, and revoked/expired status. Review External integrations on this page before creating a key: a credential alone does not enable REST, MCP, or Employee resolver access.
Name the credential for its application
Choose Generate API key and enter Name, for example ServiceNow CI sync. Name it for the application/environment so another administrator can identify its owner and purpose later. In Expires (optional), choose the intended end date if this integration should be time-bounded.
Choose the specific scopes
Select at least one scope. Use the three groups to distinguish reading data, dispatching actions, and patch management. A device-health reader does not automatically get patch vulnerability exposure or action permissions.
| Field or control | What to do |
|---|---|
| Fleet and devices | endpoint_read reads devices/fleet and supports MCP read; alert_read reads alerts; ci_read reads CMDB-shaped endpoint data. |
| Actions | command_dispatch runs remediations/commands and supports MCP act; ci_write writes CI references; incident_create raises events/incidents and supports MCP events. |
| Patch management | mcp_patch_read reads posture, updates, and rollouts; mcp_patch_act permits scan/install/create/pause actions. These are explicit independent grants. |
Generate and store the one-time secret
Choose Generate, complete the MFA check, and use Copy API key while Key generated is open. Store the eqi_… value in the integration’s secret store before choosing Done. The value cannot be retrieved later from the key list; closing the dialog discards the display of the secret.
Test the credential in the intended integration
Choose View API docs and use the approved Base URL. Send the key in Authorization: Bearer <key> or X-API-Key: <key>, then call /v1/health. Check the returned tenant and scopes against the key you intended to issue. Follow with the smallest read request the application needs before enabling changes.
Rotate or revoke the key
For rotation, generate a replacement, install it in the external application, and verify the replacement works before revoking the old key. To revoke, choose the row’s trash/revoke control and confirm that key. Verify its revoked state in the refreshed inventory. Revocation prevents future use of that credential; inspect and cancel any previously dispatched operational work separately if needed.
If something doesn’t work
The generated secret was lost.
It cannot be retrieved. Create a replacement, update the integration’s secret store, test it, and revoke the unused key.
Health works but a route is forbidden.
Compare the route’s required scope with the key’s selected grants and the surface’s permission mode. Patch scopes and write scopes are not implied by device-read access.
Every request fails despite an active key.
Check the approved external address, deployment enablement, tenant consent, authentication header, and key expiry/revocation.