BounCA API
Agent-ready OpenAPI document · curated by JenticSecuritySecrets Managementbearer, apiKey14 EndpointsREST
Know of an official OpenAPI document? Contribute it →
For Agents
Issue, renew, revoke, and download X.509 certificates from a self-hosted BounCA certificate authority across 14 endpoints.
Use for: Issue a new server certificate for hostname api.internal.example, Revoke certificate id 42 because the private key was exposed, Renew the intermediate CA that expires next month, Download the PEM bundle for certificate id 100 to deploy on a load balancer
Not supported: Does not handle hardware security module key storage, secret rotation, or DNS-01 ACME challenges - use for self-hosted X.509 certificate issuance, revocation, renewal, and CRL handling only.
Jentic writes and maintains this OpenAPI specification for BounCA API, keeping it validated and agent-ready. BounCA also self-serves its own Swagger 2.0 document at /api/swagger.json on every instance. BounCA is a self-hosted PKI certificate authority management tool built on Django REST Framework that issues and manages Root CAs, Intermediate CAs, and end-entity certificates for servers, clients, and code signing. The API exposes login, certificate creation, revocation, renewal, CRL handling, and certificate download so platform teams can automate internal PKI from CI pipelines or AI agents. Authentication uses a bearer token issued via /auth/login/ or a session cookie.
Install Jentic One Beta
Connect the BounCA API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the BounCA 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.
1
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%2Fbounca.org%2Fbounca" | sh2
Step 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%2Fbounca.org%2Fbounca" | 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.
Capabilities
What an agent can do with BounCA API.
Issue Root CAs, Intermediate CAs, and end-entity certificates from a self-hosted PKI
Revoke a certificate and update the corresponding certificate revocation list
Renew an existing certificate before expiry without rotating the private key
Download issued certificates in PEM bundles for distribution to services
Read certificate metadata including issuer, subject, serial, and expiry
Authenticate with a username and password to obtain a bearer token
Generate or refresh the CRL for a certificate authority
Use Cases
Patterns agents use BounCA API for, with concrete tasks.
★ Automated internal certificate issuance from CI
Platform teams running a self-hosted BounCA wire certificate issuance into their CI pipeline so that each new internal service gets a freshly issued certificate without a ticket. The pipeline calls POST /auth/login/ for a token, POST /certificates/ with the CSR or subject details, and GET /certificates/{id}/download/ to fetch the PEM bundle. Most platform teams ship the integration in a couple of days.
Authenticate with username deploy and password from the vault, issue a server certificate for CN api.internal.example with a 365-day validity, and return the certificate id
Certificate revocation and CRL refresh
Security operations revoke a certificate when a host is decommissioned or a private key is suspected compromised, and they need a fresh CRL distributed to consumers. POST /certificates/{id}/revoke/ revokes the certificate and POST /certificates/{id}/crl/ regenerates the CRL for downstream distribution. Both operations are scriptable and typically wrap into an incident response runbook.
Revoke certificate id 999 with reason 'keyCompromise', then regenerate the CRL for its issuing CA and confirm the new CRL serial
Pre-expiry renewal of long-lived certificates
Platform teams renew CAs and long-lived service certificates before they expire to avoid outages. POST /certificates/{id}/renew/ creates a new certificate with the same subject, and GET /certificates/{id}/info/ confirms the new expiry. A nightly job that scans for certificates expiring in the next 30 days and renews them prevents silent failures.
List certificates expiring within 30 days, then call the renew endpoint for each and report the new expiry dates
Agent-driven internal PKI via Jentic
An AI agent embedded in a platform team's chat workflow handles requests like 'issue a cert for grafana.internal valid for one year' by calling BounCA. Through Jentic the agent searches for 'issue a BounCA certificate', loads the schema, and executes the call while the bearer token stays in your Jentic One instance.
Search Jentic for 'issue a BounCA certificate', load the schema, and execute it for CN grafana.internal with a 365-day validity, returning the download URL
Key Endpoints
14 endpoints — jentic writes and maintains this openapi specification for bounca api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
POST
/auth/login/
Authenticate and receive a bearer token
POST
/certificates/
Issue a new certificate
GET
/certificates/
List certificates in the BounCA host
POST
/certificates/{id}/revoke/
Revoke an issued certificate
POST
/certificates/{id}/renew/
Renew an existing certificate
GET
/certificates/{id}/download/
Download the certificate PEM bundle
GET
/certificates/{id}/info/
Read certificate metadata
POST
/certificates/{id}/crl/
Regenerate the CRL for the issuing CA
POST
/auth/login/
Authenticate and receive a bearer token
POST
/certificates/
Issue a new certificate
GET
/certificates/
List certificates in the BounCA host
POST
/certificates/{id}/revoke/
Revoke an issued certificate
POST
/certificates/{id}/renew/
Renew an existing certificate
GET
/certificates/{id}/download/
Download the certificate PEM bundle
GET
/certificates/{id}/info/
Read certificate metadata
POST
/certificates/{id}/crl/
Regenerate the CRL for the issuing CA
Why Jentic?
What agents get from Jentic-routed access to this vendor.
Setup
Wiring BounCA by hand means logging in at /auth/login/ for a bearer token, pointing at your own self-hosted host, and carrying that token through the certificate lifecycle calls. Through Jentic you install once, import the BounCA API from the API Directory, store the token once, and your agent calls it.
Permission scoping
BounCA puts the certificate id in the URL path (/certificates/{id}/revoke/, /certificates/{id}/renew/), so a rule can pin your agent to one certificate. You choose the operations it may call, so destructive ones like revoke are only included if you add them, and an agent that only issues or downloads certificates can be scoped to those paths.
Credential isolation
Your BounCA bearer token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'issue a BounCA certificate' or 'revoke a certificate', and Jentic returns the matching BounCA operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using BounCA API through Jentic.
Does BounCA publish an official OpenAPI specification?
Yes. BounCA is a Django REST Framework application that ships drf-yasg, so every BounCA instance self-serves a Swagger 2.0 document at /api/swagger.json and /api/swagger.yaml. BounCA's own hosted instance serves it at https://app.bounca.org/api/swagger.json, covering 23 paths. This Jentic specification is written from the endpoints documented on bounca.org and declares the bearer token and session cookie schemes that the self-served document leaves out, so use whichever matches your deployment. Get started with Jentic One, the self-hosted execution layer.
What authentication does the BounCA API use?
BounCA supports HTTP bearer tokens issued by POST /auth/login/ and Django session cookies. For programmatic and agent use, prefer the bearer token; in Jentic the token is stored in the vault and injected at execution so it never enters the agent's context.
Can I issue a server certificate with the BounCA API?
Yes. POST /certificates/ with the certificate type set to a server cert and the required subject information; BounCA returns the new certificate id, and GET /certificates/{id}/download/ fetches the PEM bundle for deployment.
How do I revoke a certificate and refresh the CRL through Jentic?
Run pip install jentic, then search Jentic for 'revoke a BounCA certificate', load the POST /certificates/{id}/revoke/ schema, and execute it with the certificate id and revocation reason. Follow with the /crl/ endpoint to regenerate the CRL.
What are the rate limits for the BounCA API?
BounCA is self-hosted, so there are no vendor-imposed rate limits in the spec; throughput is bounded by the host running BounCA. Use the bulk listing endpoint with pagination instead of per-id loops, and serialize CRL regeneration to avoid concurrent CA updates.
Can I renew an existing certificate before it expires?
Yes. POST /certificates/{id}/renew/ creates a new certificate that reuses the same subject and CA as the original. Combine it with GET /certificates/ filtered by expiry to build a recurring renewal job.
Can I limit what my agent is allowed to do with the BounCA API?
Yes. Because you run Jentic One yourself, your own rules decide which BounCA operations and credentials the agent may use, so you can grant an agent only issuing and download paths like POST /certificates/ and GET /certificates/{id}/download/ while withholding destructive ones such as POST /certificates/{id}/revoke/. Since BounCA puts the certificate id in the URL path, a rule can also pin the agent to a single certificate for renewal or revocation. The bearer token is stored by your instance and injected at execution, so the operator, not the agent, controls what it can call.
GET STARTED