Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Proxmox Backup Server API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fpbs.proxmox.com%2Fpbs-proxmox" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fpbs.proxmox.com%2Fpbs-proxmox" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with Proxmox Backup Server API.
Create and manage user accounts with role-based access control and permissions
Generate and rotate API tokens scoped to specific users for automation
Configure two-factor authentication (TFA) for user accounts
Authenticate via OpenID Connect with configurable realm providers
Synchronize user directories from external realms (LDAP, Active Directory)
GET STARTED
Manage access control lists (ACLs) with path-based permission assignments
Monitor active datastore operations and their status
Patterns agents use Proxmox Backup Server API for, with concrete tasks.
★ Backup Server User Management
Create, update, and manage user accounts on Proxmox Backup Server for team access to backup infrastructure. The API supports listing users, creating new accounts, updating profiles, and deleting decommissioned accounts. Each user can be assigned to a realm (PAM, OpenID, LDAP) and given specific roles that control what datastores and operations they can access.
Create a new user 'backup-agent@pbs' with admin role via POST /access/users, then generate an API token for that user via POST /access/users/{userid}/token/{token-name}
API Token Automation
Generate scoped API tokens for automated backup workflows. Tokens inherit the permissions of the parent user and can be individually revoked without affecting the user's interactive access. This enables CI/CD pipelines, monitoring systems, and backup orchestration tools to authenticate without sharing user passwords.
List all tokens for user 'admin@pam' via GET /access/users/{userid}/token, then create a new token named 'monitoring' with read-only scope
Access Control Configuration
Define granular permissions for users and tokens across datastores and system resources. The ACL system uses path-based permission assignments where each entry maps a user or token to a role on a specific resource path. This enables multi-tenant backup environments where each team can only access their designated datastores.
Retrieve the current ACL entries via GET /access/acl, then add a new entry granting 'DatastoreUser' role to 'backup-agent@pbs' on path '/datastore/vm-backups' via PUT /access/acl
AI Agent Backup Infrastructure Management via Jentic
AI agents use the Proxmox Backup Server API through Jentic to manage users, rotate tokens, and configure permissions on PBS instances. Jentic handles the cookie-based authentication and CSRF token injection so agents can automate backup infrastructure operations without managing session state directly.
Search Jentic for 'manage Proxmox backup users', load the schema for GET /access/users, and execute to retrieve all configured user accounts with their roles
27 endpoints — proxmox backup server api provides management of backup infrastructure including user access control, authentication, datastore operations, and system administration.
METHOD
PATH
DESCRIPTION
/access/users
List all users on the backup server
/access/users
Create a new user account
/access/users/{userid}/token/{token-name}
Create an API token for a user
/access/acl
Set access control list entries
/access/permissions
Query effective permissions
/access/ticket
Create an authentication ticket
/admin/datastore/{store}/active-operations
List active datastore operations
/access/users
List all users on the backup server
/access/users
Create a new user account
/access/users/{userid}/token/{token-name}
Create an API token for a user
/access/acl
Set access control list entries
/access/permissions
Query effective permissions
/access/ticket
Create an authentication ticket
/admin/datastore/{store}/active-operations
List active datastore operations
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the Proxmox Backup Server API by hand means acquiring an authentication ticket via POST /access/ticket, carrying the PBSAuthCookie, and adding a CSRFPreventionToken header to every state-changing request against your own {host}:8007 instance yourself. Through Jentic you install once, import Proxmox Backup Server from the API Directory, store the credentials once, and your agent calls it.
Permission scoping
Proxmox Backup Server puts the datastore in the URL path (/admin/datastore/{store}/...) and the user in /access/users/{userid}/..., so a rule can pin your agent to one datastore or user: it can read that store's active operations and nothing else. You choose the operations it may call, so writes like creating users or updating the ACL are not included unless you add them.
Credential isolation
Your Proxmox Backup Server credentials are stored once, encrypted, by your own Jentic One instance, which acquires the ticket and injects the cookie and CSRF token at execution time. The raw password never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'manage backup server users' or 'check a datastore's active operations', and Jentic returns the matching Proxmox Backup Server operation with its input schema so the agent calls the right endpoint against the configured instance without reading the reference docs.
Alternatives and complements available in the Jentic catalogue.
Stripe API
Payment processing for billing customers using managed backup services
Use Stripe alongside PBS when running a backup-as-a-service business that bills customers for storage consumed.
Specific to using Proxmox Backup Server API through Jentic.
What authentication does the Proxmox Backup Server API use?
The PBS API uses cookie-based authentication via PBSAuthCookie with a CSRFPreventionToken header for state-changing requests. You obtain a ticket via POST /access/ticket with username and password. Alternatively, API tokens provide stateless authentication. Through Jentic, session management and CSRF tokens are handled automatically.
Can I create API tokens for automated backup jobs?
Yes. POST /access/users/{userid}/token/{token-name} creates a token scoped to that user's permissions. Tokens can be used directly in API calls without session management. You can list all tokens via GET /access/users/{userid}/token and revoke individual tokens via DELETE.
What are the rate limits for the Proxmox Backup Server API?
PBS does not impose explicit per-endpoint rate limits as it is a self-hosted solution. Performance depends on your server resources. However, authentication ticket creation (POST /access/ticket) applies a per-IP throttle to prevent brute-force attacks.
How do I manage user permissions through Jentic?
Search Jentic for 'set Proxmox backup permissions', load the schema for PUT /access/acl, and execute with the path, user, and role. Jentic handles the cookie authentication and CSRF token injection automatically, returning the updated ACL configuration.
Does the PBS API support OpenID Connect authentication?
Yes. The API provides POST /access/openid/auth-url to generate an OpenID authentication URL and POST /access/openid/login to complete the login flow. This enables SSO integration with identity providers like Azure AD, Keycloak, and Google Workspace.
Can I limit what my agent is allowed to do with the Proxmox Backup Server API?
Yes. You run Jentic One yourself, and your own rules decide which Proxmox Backup Server operations and credentials your agent may use. Because this API puts the datastore in the URL path (/admin/datastore/{store}/...) and the user in /access/users/{userid}/..., you can pin the agent to a single datastore or user so it only reads that store's active operations. State-changing calls such as creating users via POST /access/users or updating the access control list via PUT /access/acl stay off limits unless you explicitly grant them.
For Agents
Manage backup server users, access tokens, permissions, two-factor authentication, and realm-based directory sync for Proxmox Backup Server instances.
Use for: I need to create a new user on the Proxmox Backup Server, I want to generate an API token for automated backup jobs, List all users and their permissions on the backup server, Check whether a specific user has TFA configured
Not supported: Does not handle VM provisioning, network configuration, or storage pool creation - use for backup server access control and user management only.
Proxmox Backup Server API provides management of backup infrastructure including user access control, authentication, datastore operations, and system administration. It supports user and token management with role-based permissions, two-factor authentication configuration, OpenID Connect integration, and realm-based directory synchronization. The API runs on the PBS host at port 8007 and uses cookie-based authentication with CSRF token protection.
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>