Osohq Oso Cloud HTTP API

Name: Oso Cloud HTTP API
Brand: Oso Cloud HTTP API
Availability: InStock

✓ Official Vendor SpecIdentity AuthAuthorizationbearer20 EndpointsREST

For Agents

Upload authorisation policies, manage facts, and check whether a user can perform an action on a resource through Oso Cloud. Agents can offload permission decisions instead of hard-coding role checks.

Install Jentic One Beta

Connect the Oso Cloud HTTP API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Oso Cloud HTTP 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://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic 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 Oso Cloud HTTP API.

Upload and version Polar authorisation policies

Insert and delete facts that describe relationships between actors and resources

Bulk-load and bulk-delete facts in a single request for migrations

GET STARTED

Start building with Oso Cloud HTTP API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use Oso Cloud HTTP API for, with concrete tasks.

★ Centralised Authorisation for Microservices

Engineering teams replace bespoke per-service permission checks with a central Oso Cloud policy. Services post facts (membership, ownership, role assignments) and call the authorisation endpoint to decide each request. The Polar policy lives in one place and updates atomically across all consumers, removing drift between services.

Check whether user 'alice@acme.com' can perform action 'edit' on resource 'document:42' by POSTing the (actor, action, resource) triple to /authorize.

Relationship-Based Permissions in B2B SaaS

B2B platforms model parent-child relationships such as organisations owning workspaces owning documents. Oso Cloud stores these relationships as facts and the Polar policy traverses them to compute permissions. The /facts endpoints support inserts, deletes, and bulk operations so the relationship graph stays in sync as customers add and remove members.

Add the fact that user 'bob' has role 'admin' in organisation 'org-7' by POSTing the fact tuple to /facts.

Authorisation Policy as Code

Platform teams ship authorisation changes through their CI pipeline by uploading new Polar policies via POST /policy. Reviewers can diff Polar source between releases, and changes propagate to every consumer once the new version is active. /policy_metadata exposes which version is live and when it was published, supporting safe rollouts and rollbacks.

Upload a new Polar policy by POSTing the policy source to /policy and then verify it via GET /policy_metadata.

AI Agent Authorisation Gate via Jentic

Customer-facing AI agents that act on behalf of users must check authorisation before each action. Through Jentic, the agent searches for 'check user permission' and Oso Cloud's /authorize endpoint surfaces with its schema; the call is executed with a Bearer key held in the vault. This avoids embedding the Oso Cloud key in the agent prompt and keeps authorisation enforcement consistent with the rest of the platform.

Use Jentic to search 'check whether a user can perform an action', load the POST /authorize schema, and execute it with the actor, action, and resource captured in the conversation.

Key Endpoints

20 endpoints — oso cloud is an authorisation-as-a-service offering that decouples authorisation logic from application code.

METHOD

PATH

DESCRIPTION

GET

/policy

Get the current authorisation policy

POST

/policy

Upload a new Polar policy

GET

/policy_metadata

Read policy metadata such as active version

POST

/facts

Insert a fact

DELETE

/facts

Delete a fact

POST

/bulk_load

Bulk-load many facts in one request

POST

/bulk_delete

Bulk-delete many facts in one request

POST

/bulk

Run combined bulk operations

GET

/policy

Get the current authorisation policy

POST

/policy

Upload a new Polar policy

GET

/policy_metadata

Read policy metadata such as active version

POST

/facts

Insert a fact

DELETE

/facts

Delete a fact

POST

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Oso Cloud Bearer API keys are stored encrypted in the Jentic vault. Agents receive scoped access tokens — the raw Bearer key never enters the agent's context.

Intent-based discovery

Agents search by intent (e.g. 'check whether a user can edit a resource') and Jentic returns the matching Oso Cloud operation with its input schema, so the agent calls /authorize, /facts, or /policy correctly without browsing the Oso reference.

Time to first call

Direct Oso Cloud integration: 1-3 days to model the policy, wire fact synchronisation, and add authorisation calls. Through Jentic: under 1 hour — search, load schema, execute.

FAQs

Specific to using Oso Cloud HTTP API through Jentic.

What authentication does the Oso Cloud API use?

Oso Cloud uses HTTP Bearer authentication with an API key. Each request includes Authorization: Bearer <api_key>. Through Jentic, the API key is stored encrypted in the vault and injected at call time, so it never appears in the agent's prompt or logs.

Can I check authorisation for a user with the Oso Cloud API?

Yes. The authorisation question is asked via the API's authorize query, which evaluates the active Polar policy against the (actor, action, resource) triple and returns whether the action is permitted. The same data model also supports list-actions and list-resources queries to enumerate what an actor can do.

What are the rate limits for the Oso Cloud API?

Rate limits are not declared in the Oso Cloud OpenAPI spec; in practice the service applies plan-based throttling and returns 429 with a Retry-After header when a tenant exceeds its quota. For latency-sensitive paths Oso recommends keeping the local agent SDK alongside Cloud rather than calling the HTTP API on every request.

How do I add a relationship fact through Jentic?

Through Jentic, search for 'add an Oso Cloud fact', load the POST /facts schema, and execute it with the fact tuple — for example {predicate: 'has_role', args: ['User:alice', 'admin', 'Org:7']}. Jentic injects the Bearer key from the vault.

Can I bulk-load facts after a data migration?

Yes. POST /bulk_load accepts an array of facts and inserts them in a single request, and POST /bulk_delete removes them in bulk. This is the recommended pattern when synchronising Oso Cloud with another source of truth such as a directory or CRM.

Is Oso Cloud free to use?

Oso Cloud has a free Developer tier suited for evaluation; production usage is on paid plans tied to monthly authorisation requests and tenant counts. The local Oso agent that pairs with Cloud is open source.

Osohq Oso Cloud HTTP API

Connect the Oso Cloud HTTP API to your agent

Capabilities

Start building with Oso Cloud HTTP API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs