Install Jentic One Beta

Connect the Den API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Den 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%2Fopenworklabs.com%2Fopenworklabs" | 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%2Fopenworklabs.com%2Fopenworklabs" | 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 Den API.

Build permission sets from the permission catalog, change their permissions, and read any member's effective permissions

Invite people by email and role, change a member's role, and transfer workspace ownership

Cap member spend with gateway usage limit policies measured in micro-USD and review reset requests

GET STARTED

Start building with Den API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Den API for, with concrete tasks.

★ Agent-run workspace administration through Jentic

An admin's AI agent can handle routine OpenWork housekeeping without a hand-built client. Through Jentic the agent searches for 'invite a member to the organization', loads the Den invitation operation with its input schema, and sends the email and role the body requires, with the den_ API key injected in the x-api-key header at call time. It can then confirm the new member's access by reading their effective permissions.

POST /v1/invitations with email 'sam@example.org' and role 'member', then after acceptance read GET /v1/members/{memberId}/permissions for that member

Spend guardrails for model usage

Teams sharing an organization model gateway need a ceiling on cost. Den's usage limit policies take a name and limits measured as estimated provider cost in integer micro-USD, with calendar windows that reset at 05:00 UTC, and can be assigned to members. Members who hit a cap file a reset request that admins list and review.

POST /v1/gateway/usage-limit-policies with name 'Eng monthly' and a monthly limit, assign it through POST /v1/gateway/usage-limit-policies/{policyId}/assignments, and check GET /v1/gateway/usage-limits/members/{memberId}

Scheduled Automations with run history

Recurring jobs such as a weekly status digest run as Automations: a Desktop Automation runs on one of the owner's connected desktops and a Cloud Automation runs in OpenWork Cloud. Den keeps durable run history, so a job can be triggered on demand with POST /v1/automations/{id}/run and audited afterwards through its runs list.

Call POST /v1/automations/{id}/run for the weekly digest Automation, then read GET /v1/automations/{id}/runs to confirm the latest run

Model provider setup for an organization

Admins choose which model providers members can use. Den creates an organization LLM provider from a models.dev catalog template or a custom configuration, with name and source required, and can limit it to specific members or teams. A test-connection operation checks a custom endpoint before it goes live.

Look up a provider with GET /v1/llm-provider-catalog, then POST /v1/llm-providers with name, source, providerId, and modelIds for the chosen models

Audit review for compliance checks

When a security reviewer asks what changed, retained audit history answers it. GET /v1/audit/operations filters by actorId, action, outcome, origin, resourceId, and resourceType within a time range, and GET /v1/audit/operations/{operationId}/events returns the events behind one operation. Audit capture requires the auditLogs feature to be on for the organization.

Call GET /v1/audit/operations with resourceType for permission sets and a from and to range for the last 7 days, then fetch events for each operation

Key Endpoints

496 endpoints — the den api administers openwork organizations: who can use the workspace, which models and tools members reach, and what runs on their behalf.

METHOD

PATH

DESCRIPTION

POST

/v1/invitations

Create an organization invitation

POST

/v1/permissions/sets

Create a permission set

GET

/v1/members/{memberId}/permissions

Get a member's effective permissions

POST

/v1/llm-providers

Create an organization LLM provider

POST

/v1/gateway/usage-limit-policies

Create a usage limit policy

POST

/v1/automations/{id}/run

Run an Automation now

POST

/v1/workflows/{configObjectId}/run

Run an exact Workflow version

GET

/v1/audit/operations

List retained audit operations

POST

/v1/invitations

Create an organization invitation

POST

/v1/permissions/sets

Create a permission set

GET

/v1/members/{memberId}/permissions

Get a member's effective permissions

POST

/v1/llm-providers

Create an organization LLM provider

POST

/v1/gateway/usage-limit-policies

Create a usage limit policy

POST

/v1/automations/{id}/run

Run an Automation now

POST

/v1/workflows/{configObjectId}/run

Run an exact Workflow version

GET

/v1/audit/operations

List retained audit operations

Why Jentic?

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

Setup

Wiring Den by hand means telling apart its den_ API key in x-api-key, session bearer tokens, and the separate SCIM and worker tokens, then paging cursors across hundreds of routes. Through Jentic you install once, import Den from the API Directory, store the key once, and your agent calls it.

Permission scoping

Den puts resource ids in the URL path, such as /v1/automations/{id}, /v1/workflows/{configObjectId}, and /v1/permissions/sets/{permissionSetId}, so a rule can pin your agent to one Automation or one Workflow and the operations you pick. You choose the operations it may call, so destructive ones like DELETE /v1/org or DELETE /v1/members/{memberId} are not included unless you add them.

Credential isolation

Your den_ API key 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 'invite a member' or 'run an Automation now', and Jentic returns the matching Den operation with its input schema, so the agent finds the right route among hundreds without reading the reference.

FAQs

Specific to using Den API through Jentic.

What authentication does the Den API use?

Per its OpenAPI spec, most Den routes accept either an organization API key that starts with den_, sent raw in the x-api-key header, or a Den session token sent as Authorization: Bearer. Some routes use other bearer tokens: SCIM provisioning uses a token issued from POST /v1/scim/token, and a worker heartbeat route uses a per-worker token. Public routes such as GET /health and the OAuth discovery documents need no credential.

Can the Den API run an Automation on demand?

Yes. POST /v1/automations/{id}/run triggers an Automation immediately and accepts an optional executionTarget. Den keeps durable run history, which you read per Automation through GET /v1/automations/{id}/runs or across a time range with GET /v1/automation-runs using the required from and to parameters.

What are the rate limits for the Den API?

The OpenAPI spec does not specify request rate limits. It does describe gateway usage limit policies that cap model spend per member in micro-USD. Check the OpenWork documentation at https://openworklabs.com/docs for current request limits.

Is there an OpenWork Den MCP server?

You don't need an MCP server to give your agent the Den API. Jentic connects it directly from the API Directory: import it, store your den_ key once, and your agent calls the member, permission, provider, and Automation operations on demand without loading another server's tool definitions into its context.

How do I invite a member through Jentic?

Search Jentic for 'invite a member to the organization', load the POST /v1/invitations operation, and execute it with the email and role fields the body requires. Den sends the invite email and returns 502 if the email provider fails, so the agent can report that clearly. To run it on your own infrastructure, install Jentic One from its GitHub repo.

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

Yes. A worked example: allow GET /v1/automations, POST /v1/automations/{id}/run, and GET /v1/automations/{id}/runs for one Automation id, and the agent can trigger and check that job while member removal, API key creation, and organization deletion stay out of reach. Every call it makes is logged.

Can the Den API provision users from an identity provider?

Yes. Den exposes SCIM v2 routes under /api/auth/scim/v2 for users and groups, authenticated with a SCIM token issued from POST /v1/scim/token. Organization SSO is configured separately through POST /v1/sso/saml or POST /v1/sso/oidc, tested, and then enabled with POST /v1/sso/enable.

Openworklabs Den API

AI ReadinessFoundational (C)53/100

See full scorecard

Official vendor OpenAPI document · agent-readyIdentity AuthAuthorizationapiKey, bearer496 EndpointsREST

For Agents

Administer an OpenWork organization: invite members, assign permission sets and roles, configure LLM providers and usage limits, and run Automations and Workflows with recorded run history.

Use for: Invite a new teammate to our OpenWork organization as a member, Get the effective permissions for a specific member, I need to add an Anthropic provider for the whole organization, Set up a monthly usage limit policy for the engineering team

Not supported: Does not serve model completions directly, host source code, or bill customers. Use for administering OpenWork organizations: members, permissions, model providers, usage limits, plugins, and Automations only.

The Den API administers OpenWork organizations: who can use the workspace, which models and tools members reach, and what runs on their behalf. It manages members, teams, invitations, permission sets, SSO, and SCIM provisioning, and sets per-member gateway usage limit policies priced in micro-USD. It also configures organization LLM providers and inference gateway model groups, publishes plugins, skills, and marketplaces, and schedules Automations and Workflows that run on a connected desktop or in OpenWork Cloud with durable run history.

Jentic One on Github View OpenAPI Document

Show dimension breakdown

Foundational Compliance

Base layer of spec validity and structural soundness.

Grade: A-Signals: 4

89%

Lint Results

Aggregated quality score from linter diagnostics, weighted by severity.

100%

Resolution Completeness

Percentage of `$ref` references that resolve successfully.

100%

Specification Validity

Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).

Structural Integrity

Structural correctness score based on schema issues using logarithmic dampening.

Developer Experience & Jentic Compatibility

Clarity, completeness, and ingestion readiness for developers and tooling.

Grade: C+Signals: 4

Example Density

How richly the API is illustrated with examples.

100%

Example Validity

Percentage of examples that conform to their schemas.

53%

Response Coverage

Percentage of operations with complete response definitions (success, client error, server error).

87%

Tooling Readiness

Health of API ingestion, bundling, and resolution within Jentic pipelines.

AI-Readiness & Agent Experience

Semantic breadth, depth, and agent comprehension for AI systems.

Grade: DSignals: 4

19%

Description Coverage

Coverage of descriptions across API elements.

Error Standardization

Coverage of RFC 9457 Problem Details for error responses.

100%

OperationId Quality

Coverage, uniqueness, and casing consistency of operationIds for AI inference.

56%

Summary Coverage

Coverage of summaries across operations/tags/info.

Agent Usability

Functional utility, complexity comfort, and AI orchestration readiness.

Grade: D-Signals: 1

43%

Complexity Comfort

Agent comfort level based on API operational and structural complexity.

Security

Trust, risk posture, and security compliance.

Grade: B-Signals: 1

61%

Authentication Strength

Average quality of security schemes based on authentication method strength (weakest link for OAuth2).

AI Discoverability

Findability, semantic richness, and reasoning readiness.

Grade: B+Signals: 1

69%

Descriptive Richness

Clarity and depth of descriptions across API elements.

Connect the Den API to your agent

Capabilities

Start building with Den API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Openworklabs Den API

Jentic AI Readiness Score

Den API

Foundational Compliance

Lint Results

Resolution Completeness

Specification Validity

Structural Integrity

Developer Experience & Jentic Compatibility

Example Density

Example Validity

Response Coverage

Tooling Readiness

AI-Readiness & Agent Experience

Description Coverage

Error Standardization

OperationId Quality

Summary Coverage

Agent Usability

Complexity Comfort

Security

Authentication Strength

AI Discoverability

Descriptive Richness