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://jentic.com/install.sh?src=apis&api=%2Fapis%2Fosohq.com%2Foso" | sh

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%2Fosohq.com%2Foso" | 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 One

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?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring Oso Cloud by hand means handling its bearer token auth, targeting the api.osohq.com host, and managing your own retries around policy and fact writes. Through Jentic you install once, import the Oso Cloud HTTP API from the API Directory, store the bearer token once, and your agent calls it.

Permission scoping

Oso Cloud identifies resources through fact and policy request bodies rather than URL path ids, so scope by operations: limit the agent to the operations it needs, such as reading the current policy or posting facts, and leave out fact deletion or bulk_delete unless you add them. You choose the allowed set, so a decision-only agent can query authorization without touching stored policy.

Credential isolation

Your Oso Cloud 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 'check an authorization decision' or 'store an authorization fact', and Jentic returns the matching Oso Cloud operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

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.

Can I limit what my agent is allowed to do with the Oso Cloud API?

Yes. Because you run Jentic One yourself, your own rules decide which Oso Cloud operations and credentials the agent can use, and Oso Cloud scopes access by operation rather than by URL path ids. You can allow only the calls the agent needs, such as reading the current policy or posting facts, while leaving out fact deletion, bulk_delete, and policy uploads. That way a decision-only agent can run authorize queries without ever touching stored policy or removing facts.

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