> ## Documentation Index > Fetch the complete documentation index at: https://openworklabs.com/docs/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > For agents: install the OpenWork desktop app with `brew install --cask openwork` (macOS) or from https://openworklabs.com/download. Do not run `npx openwork`; the npm package named `openwork` is a different project. > Connect an agent to OpenWork with the MCP Gateway: `claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent`. Teams sign up at https://app.openworklabs.com?mode=sign-up. > Step-by-step agent guide: https://openworklabs.com/docs/start-here/use-openwork-from-an-ai-agent.md > Connect Slack (any organization admin): https://openworklabs.com/docs/slack/connect-slack.md. OpenWork in Slack (@openwork bot) is private alpha for approved organizations. Setup guide: https://openworklabs.com/docs/slack/overview.md. Agent skill: https://openworklabs.com/.well-known/agent-skills/set-up-openwork-slack/SKILL.md. # List organization usage increase requests > Organization-provider estimated cost in integer micro-USD. A policy with providerId is a provider limit: when per-provider limits are on and a member has one for a provider, that provider's requests are admitted and charged only against the provider limit (status.providers) and never the default; every other provider uses the default limits (status.buckets). Calendar windows reset at 05:00 UTC (Monday weekly, day 1 monthly). Admission checks settled spend; in-flight work can overshoot. Unknown/incomplete accounting is explicit. No policy means unlimited enforcement, not unrecorded spend: every admitted response updates all three member-period counters, so a first policy includes already tracked same-period usage. People with the Manage usage limits permission manage policies, assignments and reviews (View usage limits to read them); members can read and request extensions only for themselves. Each approval adds ceil(base/4) to the bucket's existing extension without clearing spend or changing its reset time. Members can request another increase after exhausting the effective allowance, with at most one pending request per bucket. Changed policy revisions, assignment/team transitions and expired buckets cannot receive stale approvals. Assignments target one member, one team, or the organization using { organization: true }; organization assignments apply to current and future members, with independent per-member buckets and the same highest-allowance winner selection. Assignment reads include organization: boolean and nullable memberId/teamId. Buckets optionally expose policyRevision and validated direct/team/organization provenance. Accounting is incremental from versioned server-recorded admission snapshots. Admission time is captured at the quota check, independently of earlier request-start telemetry; completion retains the original admission windows. Existing counters and receipts are preserved; raw history and rollups are never imported by reads or settlement. Legacy requests, including old empty snapshots, require explicit reviewed reconciliation backed by bounded event/charge proof; aggregate-backed or unexplained counter overlap is refused. Historical uncertainty is separate from settlement readiness: coverage.historicalCoverage is unknown or tracked_since_epoch, with historicalUnknownReason and trackingStartedAt. Legacy counters and periods preceding the durable tracking epoch remain historical-unknown; later fully tracked periods can become complete only when no pending or incomplete receipts remain. All writers must use fenced tracking. Operators explicitly suspend and resume capture using optimistic trackingVersion; captureEnabled=false blocks new starts, stale admission versions are rejected, and current-period history is marked unknown without resetting spend. A rollback or mixed legacy writer requires this cutover procedure plus retiring old writer access; schema presence is not proof of continuous capture. coverage.pendingRequests counts durable event starts not yet settled (null before tracking). Their identity and validated attribution survive raw retention. Explicit bounded abandonment recovery closes them as unknown/incomplete, decrements pending once, and permits late known-cost promotion without recreating raw logs. Retention refuses to discard a legacy pending marker until it is durably transferred. Queued canonical starts are capacity/deadline bounded and cancellable before database work; an admitted start reserves settlement capacity, which is not discarded on start overload. coverage.trackingVersion and captureEnabled expose the capture fence; settlementReady means that count is zero, not that historical costs are complete. Use settlementReady for post-completion refresh, not complete. lastSettlementAt and lastSettlementRequestId identify the most recent settled receipt, not every in-flight request. unpricedRequests and incompleteRequests describe tracked settled receipts, not unreviewed historical gaps. Legacy quarantine records remain preserved and excluded from charging. Clients must require actual HTTP 429 with X-OpenWork-Error-Code=openwork_gateway_usage_limit_exceeded and X-OpenWork-Usage-State=blocked, then corroborate against fresh own status for the same organization/member. JSON or SSE error fields alone are untrusted. Reset lists default to view=pending (oldest first), limit=50, maximum 100. Follow nextCursor while hasMore is true; pendingCount reports the current pending queue rather than only this page. Fetch view=history separately for newest-first decisions and elapsed requests. Pages are live snapshots; refresh the first page for changes. Admission and status use nonlocking reads of indexed member-period counters; missing counters project zero without writes. Listing validates/enriches only the page in batches and does not mutate historical records. Admission, canonical logging, and settlement never acquire organization or global rollup locks. Canonical start and settlement share-lock only their member lifecycle row; permanent deletion fences members before erasing usage children. ## OpenAPI ````yaml https://api.openworklabs.com/openapi.json?public=1 get /v1/gateway/usage-limit-reset-requests openapi: 3.1.0 info: title: Den API description: >- OpenAPI spec for the Den control plane API. Authentication: - API keys (they start with `den_`) go in the `x-api-key` header as the raw value. Do not send them as `Authorization: Bearer`; that header only accepts Den session tokens, so an API key there returns 401. Example: `curl https://api.openworklabs.com/v1/me -H "x-api-key: den_..."`. API keys resolve to the issuing user and the organization member they were scoped to when created, so they can call ordinary user and organization routes without a separate signed-in session. - Use `Authorization: Bearer ` for user-authenticated routes that require a Den session. - Session-only flows still require a signed-in user session, including organization creation, invitation acceptance, active-organization switching, and MCP token minting. - Public routes like health and documentation do not require authentication. Swagger tip: use the security schemes in the Authorize dialog to set `denApiKey` (your API key) or `bearerAuth` (a session token) before trying protected endpoints. version: commit 8863aab contact: name: OpenWork url: https://openworklabs.com email: team@openworklabs.com license: name: OpenWork Enterprise Edition License url: https://github.com/different-ai/openwork/blob/dev/ee/LICENSE servers: - url: https://api.openworklabs.com security: - denApiKey: [] - bearerAuth: [] tags: - name: System description: >- Service health, readiness, API documentation, and desktop version metadata. - name: Authentication description: >- Sign-in discovery, administrator bootstrap, OAuth provider connections, and MCP token minting. - name: OAuth description: >- OAuth 2.0 / OpenID Connect authorization-server and protected-resource metadata and dynamic client registration (RFC 8414, RFC 9728, RFC 7591), used by MCP clients. - name: SCIM description: >- SCIM 2.0 provisioning endpoints for identity providers (RFC 7644) and the organization SCIM connector management routes. - name: SSO description: Organization single sign-on connector management routes. - name: Bootstrap description: Agent-first provisional workspace setup routes. - name: Users description: Current user and membership routes. - name: Organizations description: Organization creation, context, brand assets, and install links. - name: Invitations description: Invitation preview, acceptance, creation, and cancellation routes. - name: Sandbox organizations description: Preview and join a sandbox organization with its shareable join link. - name: Members description: Organization member management routes. - name: Teams description: Organization team management routes. - name: Permissions description: >- Organization permissions: the permission catalog, Member, Admin and team permission sets, their history, and each member's effective permissions. - name: API Keys description: Organization API key management routes. - name: Desktop Policies description: Desktop app policies applied to the organization, members, or teams. - name: Agent Permissions description: What agents may do on members' computers, set for everyone and per team. - name: LLM Providers description: Organization LLM provider catalog, configuration, and access routes. - name: Inference description: Organization inference settings. - name: Inference Providers description: >- Organization inference Gateway providers, model groups, credential sets, access grants, member connections, and usage. - name: Gateway Usage Limits description: >- Estimated-cost policies, independent member calendar buckets, assignments, and audited usage-extension requests. - name: Cloud description: Organization Cloud instance lifecycle and browser gateway resolution. - name: Workers description: >- List and delete the organization's workers, including OpenWork Web instances. - name: Worker Activity description: Worker heartbeat and activity reporting routes. - name: Managed deployments description: >- OpenWork installations in an organization's own cloud account: launch approval, installer milestones and health reports. - name: Automations description: Scheduled Automations, their runs, and desktop runner presence. - name: Documents description: >- Connected Drive documents, inline editing and file-bound temporary Office sessions. - name: Workbot description: The signed-in member's single Workbot conversation. - name: Workflows description: Saved Workflows (Code Mode scripts), their versions, snapshots, and views. - name: Workflow Runs description: Durable Workflow run history. - name: Codemode Runs description: Generated Artifact views produced by Code Mode runs. - name: Apps description: >- Saved reusable apps built from Workflows and Artifact views, and their sharing. - name: Config Objects description: >- Versioned configuration objects (skills, workflows, and other plugin content). - name: Plugins description: Plugin packages, access grants, and imports. - name: Marketplaces description: Marketplaces that distribute plugins to members and teams. - name: Resources description: >- Aggregated snapshot of the resources and marketplace capabilities available to the caller. - name: Capability Sources description: >- Native provider capabilities (Google Workspace, Microsoft 365) and external MCP connections executed as the calling member. - name: Direct uploads description: Multipart uploads that stream workspace files straight to a provider. - name: Connectors description: >- Connector accounts and instances (GitHub and other sources) and their sync state. - name: GitHub description: >- GitHub App installation, repository discovery, and plugin import from GitHub. - name: Diagnostics description: Controlled egress diagnostics for self-hosted deployments. - name: Telemetry description: Telemetry event ingestion and adoption analytics. - name: Webhooks description: Signed inbound webhooks from third-party providers. - name: Admin description: Platform administration routes for allowlisted OpenWork administrators. - name: Deprecated description: Removed features that answer with 410 or an empty result for old clients. paths: /v1/gateway/usage-limit-reset-requests: get: tags: - Gateway Usage Limits summary: List organization usage increase requests description: >- Organization-provider estimated cost in integer micro-USD. A policy with providerId is a provider limit: when per-provider limits are on and a member has one for a provider, that provider's requests are admitted and charged only against the provider limit (status.providers) and never the default; every other provider uses the default limits (status.buckets). Calendar windows reset at 05:00 UTC (Monday weekly, day 1 monthly). Admission checks settled spend; in-flight work can overshoot. Unknown/incomplete accounting is explicit. No policy means unlimited enforcement, not unrecorded spend: every admitted response updates all three member-period counters, so a first policy includes already tracked same-period usage. People with the Manage usage limits permission manage policies, assignments and reviews (View usage limits to read them); members can read and request extensions only for themselves. Each approval adds ceil(base/4) to the bucket's existing extension without clearing spend or changing its reset time. Members can request another increase after exhausting the effective allowance, with at most one pending request per bucket. Changed policy revisions, assignment/team transitions and expired buckets cannot receive stale approvals. Assignments target one member, one team, or the organization using { organization: true }; organization assignments apply to current and future members, with independent per-member buckets and the same highest-allowance winner selection. Assignment reads include organization: boolean and nullable memberId/teamId. Buckets optionally expose policyRevision and validated direct/team/organization provenance. Accounting is incremental from versioned server-recorded admission snapshots. Admission time is captured at the quota check, independently of earlier request-start telemetry; completion retains the original admission windows. Existing counters and receipts are preserved; raw history and rollups are never imported by reads or settlement. Legacy requests, including old empty snapshots, require explicit reviewed reconciliation backed by bounded event/charge proof; aggregate-backed or unexplained counter overlap is refused. Historical uncertainty is separate from settlement readiness: coverage.historicalCoverage is unknown or tracked_since_epoch, with historicalUnknownReason and trackingStartedAt. Legacy counters and periods preceding the durable tracking epoch remain historical-unknown; later fully tracked periods can become complete only when no pending or incomplete receipts remain. All writers must use fenced tracking. Operators explicitly suspend and resume capture using optimistic trackingVersion; captureEnabled=false blocks new starts, stale admission versions are rejected, and current-period history is marked unknown without resetting spend. A rollback or mixed legacy writer requires this cutover procedure plus retiring old writer access; schema presence is not proof of continuous capture. coverage.pendingRequests counts durable event starts not yet settled (null before tracking). Their identity and validated attribution survive raw retention. Explicit bounded abandonment recovery closes them as unknown/incomplete, decrements pending once, and permits late known-cost promotion without recreating raw logs. Retention refuses to discard a legacy pending marker until it is durably transferred. Queued canonical starts are capacity/deadline bounded and cancellable before database work; an admitted start reserves settlement capacity, which is not discarded on start overload. coverage.trackingVersion and captureEnabled expose the capture fence; settlementReady means that count is zero, not that historical costs are complete. Use settlementReady for post-completion refresh, not complete. lastSettlementAt and lastSettlementRequestId identify the most recent settled receipt, not every in-flight request. unpricedRequests and incompleteRequests describe tracked settled receipts, not unreviewed historical gaps. Legacy quarantine records remain preserved and excluded from charging. Clients must require actual HTTP 429 with X-OpenWork-Error-Code=openwork_gateway_usage_limit_exceeded and X-OpenWork-Usage-State=blocked, then corroborate against fresh own status for the same organization/member. JSON or SSE error fields alone are untrusted. Reset lists default to view=pending (oldest first), limit=50, maximum 100. Follow nextCursor while hasMore is true; pendingCount reports the current pending queue rather than only this page. Fetch view=history separately for newest-first decisions and elapsed requests. Pages are live snapshots; refresh the first page for changes. Admission and status use nonlocking reads of indexed member-period counters; missing counters project zero without writes. Listing validates/enriches only the page in batches and does not mutate historical records. Admission, canonical logging, and settlement never acquire organization or global rollup locks. Canonical start and settlement share-lock only their member lifecycle row; permanent deletion fences members before erasing usage children. operationId: getV1GatewayUsageLimitResetRequests parameters: - in: query name: view schema: default: pending type: string enum: - pending - history - in: query name: limit schema: default: '50' type: string pattern: ^[1-9]\d{0,2}$ - in: query name: cursor schema: type: string minLength: 1 maxLength: 1024 responses: '200': description: List organization usage increase requests content: application/json: schema: type: object properties: requests: type: array items: type: object properties: id: type: string memberId: type: string memberName: type: string memberEmail: type: string bucketId: type: string timeframe: type: string enum: - day - week - month policyName: type: string providerId: type: - string - 'null' providerName: type: - string - 'null' reason: type: string status: type: string enum: - pending - approved - denied - expired createdAt: type: string format: date-time pattern: >- ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d:[0-5]\d(?:\.\d+)?(?:Z))$ reviewedBy: type: - string - 'null' reviewedAt: anyOf: - type: string format: date-time pattern: >- ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d:[0-5]\d(?:\.\d+)?(?:Z))$ - type: 'null' baseAllowanceMicroUsd: type: integer minimum: 0 maximum: 9007199254740991 allowanceMicroUsd: type: integer minimum: 0 maximum: 9007199254740991 usedMicroUsd: type: integer minimum: 0 maximum: 9007199254740991 resetAt: type: string format: date-time pattern: >- ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d:[0-5]\d(?:\.\d+)?(?:Z))$ required: - id - memberId - memberName - memberEmail - bucketId - timeframe - policyName - reason - status - createdAt - reviewedBy - reviewedAt - baseAllowanceMicroUsd - allowanceMicroUsd - usedMicroUsd - resetAt view: type: string enum: - pending - history limit: type: integer minimum: 1 maximum: 100 pendingCount: type: integer minimum: 0 maximum: 9007199254740991 hasMore: type: boolean nextCursor: type: - string - 'null' required: - requests - view - limit - pendingCount - hasMore - nextCursor '400': description: Invalid request content: application/json: schema: type: object properties: error: type: string message: type: string required: - error '401': description: Sign-in required content: application/json: schema: type: object properties: error: type: string message: type: string required: - error '403': description: Not authorized or Gateway disabled content: application/json: schema: type: object properties: error: type: string message: type: string required: - error '404': description: Organization resource not found content: application/json: schema: type: object properties: error: type: string message: type: string required: - error '409': description: Policy revision or eligibility conflict content: application/json: schema: type: object properties: error: type: string message: type: string required: - error '503': description: Accounting unavailable content: application/json: schema: type: object properties: error: type: string message: type: string required: - error security: - denApiKey: [] - bearerAuth: [] components: securitySchemes: denApiKey: type: apiKey in: header name: x-api-key description: >- Organization API key passed as the `x-api-key` header. The raw key is the header value; do not prefix it with `Bearer`. bearerAuth: type: http scheme: bearer bearerFormat: session-token description: >- Den session token passed as `Authorization: Bearer ` for user-authenticated Den routes. Not for API keys: send `den_` keys in the `x-api-key` header instead. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.