canonical: https://jentic.com/apis/openworklabs.com/openworklabs

# Openworklabs Den API

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.

## For AI 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.

## Scope

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.

## Capabilities

- 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
- Register organization LLM providers from the provider catalog and group inference gateway models
- Cap member spend with gateway usage limit policies measured in micro-USD and review reset requests
- Schedule, activate, and run Automations on a connected desktop or in OpenWork Cloud, then list their runs
- Run an exact Workflow version under a named plugin and inspect the snapshot receipt it records
- Query retained audit operations filtered by actorId, action, outcome, or resourceType

## Use cases

### 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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

| 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 |

## Key resources

- **Members, teams, and invitations** — Invite by email and role, change roles, transfer ownership, and create or update teams
- **Permissions** — Permission catalog, permission sets, set history, and each member's effective permissions
- **SSO and SCIM** — Register SAML or OIDC SSO, verify domains, and provision users and groups over SCIM v2
- **LLM and inference providers** — Organization LLM providers, provider catalog, inference gateway providers, and model groups
- **Gateway usage limits** — Usage limit policies, assignments, member limits, and reset requests
- **Automations and Workflows** — Create, activate, run, and list runs of Automations; run and version Workflows with snapshot receipts
- **Plugins, config objects, and marketplaces** — Publish skills and agents as config objects, bundle them into plugins, and list them in marketplaces
- **Audit** — Retained audit operations, operation events, export pages, and capture settings

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 53 / 100
- **Maturity:** Foundational
- **Dimensions:**
  - Foundational Compliance: 72 / 100
  - Developer Experience & Jentic Compatibility: 60 / 100
  - AI-Readiness & Agent Experience: 44 / 100
  - Agent Usability: 43 / 100
  - Security: 61 / 100
  - AI Discoverability: 69 / 100
- **View full report:** https://jentic.com/apis/openworklabs.com/openworklabs/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **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 handling:** 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.
- **Discovery method:** 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.

## Related APIs

- **Okta** — Identity provider that can push users and groups over SCIM
- **Langfuse** — LLM tracing and analytics that Den can export task analytics to
- **LiteLLM** — Self-hostable model gateway with keys, budgets, and provider routing
- **Portkey** — AI gateway with provider configs, budgets, and observability

## FAQ

### 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.`