canonical: https://jentic.com/apis/openpolicy.local/openpolicy # Open Policy Agent (OPA) REST API Jentic publishes the only available OpenAPI specification for Open Policy Agent (OPA) REST API, keeping it validated and agent-ready. OPA is a general-purpose policy engine that lets services delegate authorization, admission, and configuration decisions to declarative Rego policies. The REST API exposes endpoints to upload and remove policies, push and query data, evaluate ad-hoc queries, and compile partial-evaluation results, supporting cloud-native authorization patterns across Kubernetes, microservices, and CI pipelines. ## For AI agents Upload Rego policies, push policy data, and evaluate authorization queries against a running Open Policy Agent instance. ## Scope Does not handle user authentication, secret storage, or audit log shipping - use for Rego policy management and authorization decisions only. ## Capabilities - Upload, retrieve, and delete Rego policy modules by ID - Push and read JSON data documents at arbitrary paths under `/v1/data` - Evaluate an ad-hoc Rego query against the loaded policies and data - Run partial evaluation via `/v1/compile` to produce residual queries - Probe instance health via the /health endpoint for readiness checks - Use the v0 data path for input-only evaluations without a wrapping document ## Use cases ### Externalised authorization for microservices A microservice delegates authorization decisions to OPA by POSTing the request context to `/v1/data/{path}` and reading the allow result, instead of embedding rules in code. This keeps policy changes out of service deploys and centralises audit, particularly useful when many services share the same authorization model. Example prompt: PUT a Rego policy under `/v1/policies/rbac`, then POST input to `/v1/data/rbac/allow` and read the result field. ### Kubernetes admission control via OPA An admission controller calls OPA to decide whether a Kubernetes resource creation is allowed, based on namespace, labels, and image registry policy. OPA's `/v1/data` path returns a structured allow/deny decision with reasons that the controller surfaces back to kubectl. Example prompt: POST the admission review payload to `/v1/data/kubernetes/admission` and parse the deny array from the response. ### Partial evaluation for SQL filter generation An application uses OPA's `/v1/compile` endpoint to perform partial evaluation, turning a high-level access policy into a residual query that can be folded into a database WHERE clause. This pushes row-level filtering down to the data layer while keeping the rules declarative. Example prompt: POST a compile request to `/v1/compile` with the user query and unknowns, then translate the residual into a SQL WHERE fragment. ### Agent-driven policy management through Jentic An AI platform agent that maintains authorization rules across environments calls OPA via Jentic to deploy and verify Rego policies. Jentic exposes the policy and data endpoints as discoverable tools so the agent can promote a policy from staging to production with a single tool call. Example prompt: Search Jentic for 'upload a Rego policy to OPA', load the PUT `/v1/policies/{id}` operation, and deploy a new policy module. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | PUT | `/v1/policies/{id}` | Upload or replace a Rego policy module | | GET | `/v1/policies/{id}` | Retrieve a policy module by ID | | POST | `/v1/data/{path}` | Evaluate a policy decision at a data path | | POST | `/v0/data/{path}` | Evaluate input-only data with v0 semantics | | POST | `/v1/query` | Run an ad-hoc Rego query | | POST | `/v1/compile` | Run partial evaluation | | GET | `/health` | Check instance health | ## Key resources - **Policies** — Upload, retrieve, and delete Rego policy modules - **Data** — Push and query JSON data documents under `/v1/data` - **Query** — Evaluate ad-hoc Rego queries - **Compile** — Run partial evaluation to produce residual queries - **Health** — Probe instance liveness and readiness ## Why Jentic - **Setup:** Wiring the Open Policy Agent REST API by hand means pointing at your local OPA host, framing Rego policy uploads and data documents correctly, and building the query and compile request bodies yourself. Through Jentic you install once, import the Open Policy Agent API from the API Directory, and your agent calls it. - **Permission scoping:** OPA puts the policy id in the URL path (`/v1/policies/{id}`), so a rule can pin your agent to one policy: it can read that policy and nothing else. You choose the operations it may call, so writes like uploading a policy or evaluating data are not included unless you add them. - **Credential handling:** Any network credential your OPA deployment sits behind, such as a proxy or mTLS front end, 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. - **Discovery method:** Agents search Jentic by intent such as 'upload a Rego policy' or 'evaluate an authorization decision', and Jentic returns the matching policies, data, query, or compile operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Auth0 API** — Authenticate the user, then delegate authorization to OPA - **Okta API** — User and group directory whose claims feed OPA's input - **HashiCorp Nomad API** — Workload scheduler often paired with OPA for policy enforcement ## FAQ ### Why is there no official OpenAPI spec for Open Policy Agent (OPA) REST API? The OPA project does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Open Policy Agent (OPA) REST API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Open Policy Agent API use? OPA's REST API exposes no built-in authentication scheme in this spec - it is intended to run as a sidecar or local service trusted by the calling process. In production, deployments typically place OPA behind mTLS or a reverse proxy. Through Jentic, network credentials for the proxy stay in the vault rather than in the agent's prompt. ### Can I evaluate a Rego policy decision via the API? Yes. POST input data to `/v1/data/{path}` where {path} matches the policy's package, and OPA returns the evaluated result. For ad-hoc queries that don't map to a stored policy, use POST `/v1/query` instead. ### What are the rate limits for the Open Policy Agent API? OPA runs in-process or as a local sidecar, so there is no central rate limit - throughput is bounded by the host's CPU and the cost of the specific Rego rules being evaluated. Profile policies under load rather than relying on a vendor quota. ### How do I deploy a new Rego policy through Jentic? Run pip install jentic, search 'upload a Rego policy to OPA', load the PUT `/v1/policies/{id}` operation, and execute it with the policy id and Rego module body. Jentic handles the request shaping and returns the parsed response. ### What's the difference between `/v0/data` and `/v1/data`? The v1 path expects an input field wrapping the request and returns a structured result document, while v0 takes the input directly and returns the evaluated result without a wrapper. v1 is the modern surface; v0 is retained for backward compatibility with early OPA integrations. ### Can I limit what my agent is allowed to do with the Open Policy Agent API? Yes. Because you run Jentic One yourself, your own rules decide which OPA operations and credentials the agent may use, and it can only call what you list. Since OPA puts the policy id in the URL path at `/v1/policies/{id}`, you can pin the agent to a single policy and grant read-only access to it. Write operations like uploading a policy with PUT `/v1/policies/{id}` or evaluating data at `/v1/data/{path}` are excluded unless you explicitly add them.