API
A stable, versioned read and scaffolding API, authenticated with a tenant key.
Joopler exposes a stable, versioned v1 API for programmatic access and for the Terraform provider. It is a contract: changes are additive, and breaking changes ship under a new version prefix, never in place.
Authentication
Mint a tenant API key on the Developers page and send it as a bearer token:
Authorization: Bearer jpl_...Keys are scoped:
- read: GET endpoints only.
- write: GET endpoints plus the scaffolding write routes below.
Enforcement is default-deny: any mutating route not on the write allowlist is rejected for a key, whatever its scope.
Read endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/control-status | Live pass/fail for every control |
| GET | /v1/controls | The control catalog |
| GET | /v1/policies | Policy library and status |
| GET | /v1/people | Workforce roster and MFA |
| GET | /v1/evidence | Signed evidence ledger records |
| GET | /v1/environment | Connected systems, cloud, IdP, subprocessors, workforce |
| GET | /v1/vendors | Vendor and subprocessor register |
Write endpoints (write-scoped key)
The scaffolding of your program, also managed by the Terraform provider.
| Method | Path | Effect |
|---|---|---|
| PUT | /v1/controls/:key/owner | Assign or clear a control's owner |
| PUT | /v1/policies/:key/owner | Assign or clear a policy's owner |
| POST | /v1/controls/bulk | Bulk-assign owners and workflow state |
| POST | /v1/vendors | Create a vendor or subprocessor |
| PUT | /v1/vendors/:id | Update a vendor |
| PUT | /v1/audit-target | Set the audit-readiness target date |
| PUT | /v1/integrations/:key | Configure a connector |
What a key cannot do
Some actions are deliberately outside the key surface: policy sign-off and evidence attestation (human acts), credential and token management, provisioning, and billing. Terraform manages the structure of your program; a human signs the claims. See Compliance as code.
Connect an AI agent
The read API is a clean surface for an AI agent to reason over your live compliance posture. On the Developers page, mint a read-scoped key and copy the ready-made agent brief - a short, paste-ready instruction block that tells an agent the base URL, how to authenticate, and which read endpoints exist. It is plain text, so it works with any assistant: paste it into your agent's system instructions and provide the read key as an environment variable. No MCP server or SDK is required - the agent just makes authenticated GET requests.
Because the key is read-only, the agent can pull and reason over your controls, policies, evidence, people, environment, and vendors, but it cannot change anything.
Report and govern an agent you operate
Reading your posture is one thing; an agent that ACTS on your systems is governed
through a different credential and a different surface. Register the agent, issue it
a jpt_ credential on its page, and it can report its runs and ask whether it may
act:
| Endpoint | What it does |
|---|---|
POST /v1/agents/runs | Open a run (idempotent on runId) |
POST /v1/agents/runs/{runId}/steps | Append steps - model calls, tool calls, handoffs, approvals |
POST /v1/agents/runs/{runId}/end | Close the run and sign the completed trace |
POST /v1/agents/check | Ask whether an action may proceed, BEFORE executing it |
POST /v1/mcp-servers | Report a tool server and the tools it advertises |
An agent credential is bound to one agent: it can report and act as that agent and
no other, and it reaches nothing else in the API. A jpl_ API key cannot be used
here, and an agent credential cannot read your program - the two surfaces are
deliberately separate.
See Agent governance for the full flow and the
@joopler/agent-sdk client.