Service Accounts / API Users Without Technician Licensing

It would be useful for Jitbit to support dedicated service accounts for API and integration use that do not consume an Agent/Technician license.

Currently, API access is tied to a normal Jitbit user account. If an integration requires technician-level or administrator-level API access, it therefore needs an account with that level of access, even though no human is actually using the account.

Ideally, Jitbit could provide a dedicated Service Account user type intended specifically for API access.

Suggested capabilities

• Each service account has its own independently generated and revocable API key.
• Service accounts cannot interactively sign in to the Jitbit web interface.
• Service accounts do not consume an Agent/Technician license.
• Each service account can be assigned a role or permission scope defining what it can access through the API.
• Actions performed by the account are recorded against that specific service account in ticket history and audit logs.

Permission levels

It would be useful to separate the account's scope from whether it has read-only or read/write access.

For example:

• Read Only / Technician - Can read the tickets and other data normally visible to technicians, but cannot make changes.
• Read/Write / Technician - Can access and modify the same data a normal technician could.
• Read Only / Administrator - Can read administrative and system-wide information without being able to change it.
• Read/Write / Administrator - Can perform administrative API operations where required by an integration.

A Technician-scoped service account should have the same general visibility that a technician has, rather than being treated like an individual technician whose API access is limited to tickets assigned specifically to that service account.

Why this would be useful

This would allow integrations and automation to follow least-privilege principles without requiring organizations to create shared human accounts or consume paid technician licenses for identities that exist solely for machine-to-machine API access.

It would also make API integrations easier to secure, audit and manage, since each integration could have its own service identity, API key and appropriate permission level.