@1claw/openapi-spec 0.61.59 → 0.61.61

package/openapi.json

@@ -2,7 +2,7 @@
   "openapi": "3.1.0",
   "info": {
     "title": "1Claw API",
-    "version": "0.61.59",
+    "version": "0.61.61",
     "description": "Secure secret management for AI agents. Provides vaults, secrets,\npolicy-based access control, agent identity, Intents API,\nsharing, billing, and audit logging. Automations (workflow_spec,\nwebhook tokens, event triggers, Assist), cloud runtimes with\ninteractive shell sessions, agent memory, and discovery.\n\n## Domains\n\n`api.1claw.co` is canonical: it is the OIDC issuer, the `aud` the API\nmints, and the first entry in `servers` — a generated client takes its\nbase URL from there, and the previous ordering pointed every SDK at the\ndomain the issuer had already left. `api.1claw.xyz` still answers and is\nstill accepted on token validation, because tokens minted before the\nmove carry it; it is never minted now.\n\nOne deliberate exception: the Shroud attestation identity token is\nrequested from GCP with `audience: https://api.1claw.xyz`, so\n`/v1/shroud/attestation` reports that as its `expected_audience`. That\nis accurate rather than stale — the audience is a verification contract\nwith anyone already checking the token, and moving it is a breaking\nchange for them, not a rename.\n\nAll endpoints require JWT Bearer authentication unless marked with\n`security: []`.\n",
     "contact": {
       "email": "ops@1claw.co"
@@ -5952,7 +5952,7 @@
             "$ref": "#/components/responses/BadRequest"
           },
           "403": {
-            "description": "Guardrail violation or permission denied",
+            "description": "Guardrail violation or permission denied. From 2026-10-11 this also covers a resume_after_approval_id that does not name an approved, agent-bound, unused approval — including one that is still pending, and including a second use of one already spent. Such a request previously executed.\n",
             "content": {
               "application/json": {
                 "schema": {
@@ -15881,7 +15881,7 @@
           "Platform"
         ],
         "summary": "Add agents to a bootstrapped connection",
-        "description": "Provision additional agents on a connection that has already been\nbootstrapped, from a template belonging to the same app. `plt_` auth only.\n\nBootstrap refuses a second run (409) because it also creates the vault,\nthe policies and the plan tier, none of which should happen twice. This\nroute applies only the agent portion of a template: its `agents`, their\nper-agent `signing_keys`, `eoa` and `runtime`. `vault`, `policies`,\n`automations` and `entitlements` in the spec are ignored, and new agents\nattach to the vault the connection already has.\n\nConfiguration comes from a template rather than from fields on the\nrequest so that the agent portion of a spec has exactly one reader,\nshared with bootstrap.\n\nCapped per connection by `max_agents_per_connection` on the platform app\n(unset means a built-in default, not unlimited: an agent with signing\nkeys costs a KMS key per chain). The whole batch is checked before\nanything is created, so a template that would overshoot is refused\nrather than partly applied.\n",
+        "description": "Provision an additional agent on a connection that has already been\nbootstrapped, from a template belonging to the same app. `plt_` auth only.\n\nOne agent per call. A template declaring more than one agent is refused\nwith 400: each agent's API key is returned once and cannot be re-issued\nto a platform app, so batching them would put several unrecoverable\ncredentials in a single response.\n\nBootstrap refuses a second run (409) because it also creates the vault,\nthe policies and the plan tier, none of which should happen twice. This\nroute applies only the agent portion of a template: its `agents`, their\nper-agent `signing_keys`, `eoa` and `runtime`. `vault`, `policies`,\n`automations` and `entitlements` in the spec are ignored, and new agents\nattach to the vault the connection already has.\n\nConfiguration comes from a template rather than from fields on the\nrequest so that the agent portion of a spec has exactly one reader,\nshared with bootstrap.\n\nCapped per connection by `max_agents_per_connection` on the platform app\n(unset means a built-in default, not unlimited: an agent with signing\nkeys costs a KMS key per chain). The whole batch is checked before\nanything is created, so a template that would overshoot is refused\nrather than partly applied.\n",
         "operationId": "addConnectionAgents",
         "security": [
           {
@@ -26837,7 +26837,7 @@
           "Pending Approvals"
         ],
         "summary": "Execute an approved action",
-        "description": "Human-only. Marks the approval as executed after verifying signatures.",
+        "description": "Human-only. Marks the approval as executed after verifying signatures.\n\nExecuting mints the single-use token that satisfies the signing gate, so from 2026-10-11 it requires the same org role the consensus policy requires for approving. Where a policy sets approval.required_roles, a member whose role is not listed now gets 403 where it previously succeeded. Policies that do not set required_roles are unchanged.\n",
         "operationId": "executePendingApproval",
         "security": [
           {
@@ -37484,6 +37484,11 @@
             "format": "uuid",
             "description": "Optional pending approval ID. When consensus policies match, clients resubmit with this field set to bypass the 202 gate after the approval has been executed.\n"
           },
+          "resume_tx_id": {
+            "type": "string",
+            "format": "uuid",
+            "description": "Resume signing a transaction that is already waiting on human approval. Send the transaction_id returned with the 202 awaiting_approval response, after a human has approved it.\n\nDocumented here because it is accepted from the wire and was not in this spec before 2026-10-11. It must reference an approval that a human set to approved, raised for this agent and this transaction, and not already used. Anything else is 403, including an approval that is still pending — which previously succeeded, because the only check was that the transaction row was still awaiting_approval, a state the caller reaches by submitting in the first place.\n\nSingle-use. A second resume of the same approval is 403.\n"
+          },
           "raw_transaction": {
             "type": "string",
             "description": "Pre-built raw transaction as a base64-encoded byte string. When provided, the handler decodes and deep-inspects the transaction for policy evaluation before signing. Supported for non-EVM chains where the client constructs the transaction payload.\n"
@@ -37845,7 +37850,8 @@
           },
           "agent_api_keys": {
             "type": "array",
-            "description": "Every agent created by this call, with its one-time API key.\nReturned once and never retrievable again: a platform app\ncannot rotate a key in the end user's org, so a key missed\nhere is gone. The singular `agent_api_key` is the first of\nthese and is kept for compatibility.\n",
+            "maxItems": 1,
+            "description": "The created agent and its one-time API key. Exactly one entry:\nprovisioning is one agent per call, because a key is returned\nonce and cannot be re-issued to a platform app, so a response\ncarrying several would put several unrecoverable credentials in\none payload. A template declaring more than one agent is\nrefused with 400. The singular `agent_api_key` is the same key.\n",
             "items": {
               "type": "object",
               "properties": {
@@ -42329,7 +42335,8 @@
               },
               "agent_api_keys": {
                 "type": "array",
-                "description": "Every agent created, with its one-time API key. Returned once:\na platform app cannot rotate a key in the end user's org, so a\nmulti-agent template used to strand agents 2..N with\ncredentials nobody could recover.\n",
+                "maxItems": 1,
+                "description": "The created agent and its one-time API key. Exactly one entry:\na template declaring more than one agent is refused with 400,\nbecause a key is returned once and cannot be re-issued to a\nplatform app. Split such a template and bootstrap once per agent.\n",
                 "items": {
                   "type": "object",
                   "properties": {
@@ -46054,7 +46061,7 @@
           "resume_after_approval_id": {
             "type": "string",
             "format": "uuid",
-            "description": "Internal — resume execution after human approval (server-injected)."
+            "description": "Resume execution after a human approved it. Send the approval_id returned with the 202 approval_required response.\n\nDescribed here as \"server-injected\" until 2026-10-11, which was not enforced: the field is accepted from the wire and the gate checked only whether it was present, so any UUID skipped the approval requirement. It is now verified against an approved, agent-bound, unused approval and is single-use. Anything else, including a second use of the same approval, is 403.\n"
           }
         }
       },

package/openapi.yaml

@@ -2,7 +2,7 @@ openapi: 3.1.0
 
 info:
     title: 1Claw API
-    version: "0.61.59"
+    version: "0.61.61"
     description: |
         Secure secret management for AI agents. Provides vaults, secrets,
         policy-based access control, agent identity, Intents API,
@@ -3877,7 +3877,12 @@ paths:
                 "400":
                     $ref: "#/components/responses/BadRequest"
                 "403":
-                    description: Guardrail violation or permission denied
+                    description: >
+                        Guardrail violation or permission denied. From 2026-10-11 this
+                        also covers a resume_after_approval_id that does not name an
+                        approved, agent-bound, unused approval — including one that is
+                        still pending, and including a second use of one already spent.
+                        Such a request previously executed.
                     content:
                         application/json:
                             schema:
@@ -10098,9 +10103,14 @@ paths:
             tags: [Platform]
             summary: Add agents to a bootstrapped connection
             description: |
-                Provision additional agents on a connection that has already been
+                Provision an additional agent on a connection that has already been
                 bootstrapped, from a template belonging to the same app. `plt_` auth only.
 
+                One agent per call. A template declaring more than one agent is refused
+                with 400: each agent's API key is returned once and cannot be re-issued
+                to a platform app, so batching them would put several unrecoverable
+                credentials in a single response.
+
                 Bootstrap refuses a second run (409) because it also creates the vault,
                 the policies and the plan tier, none of which should happen twice. This
                 route applies only the agent portion of a template: its `agents`, their
@@ -17256,7 +17266,15 @@ paths:
         post:
             tags: [Pending Approvals]
             summary: Execute an approved action
-            description: Human-only. Marks the approval as executed after verifying signatures.
+            description: >
+                Human-only. Marks the approval as executed after verifying signatures.
+
+
+                Executing mints the single-use token that satisfies the signing gate,
+                so from 2026-10-11 it requires the same org role the consensus policy
+                requires for approving. Where a policy sets approval.required_roles,
+                a member whose role is not listed now gets 403 where it previously
+                succeeded. Policies that do not set required_roles are unchanged.
             operationId: executePendingApproval
             security:
                 - BearerAuth: []
@@ -24170,6 +24188,26 @@ components:
                         Optional pending approval ID. When consensus policies match,
                         clients resubmit with this field set to bypass the 202 gate
                         after the approval has been executed.
+                resume_tx_id:
+                    type: string
+                    format: uuid
+                    description: >
+                        Resume signing a transaction that is already waiting on human
+                        approval. Send the transaction_id returned with the 202
+                        awaiting_approval response, after a human has approved it.
+
+
+                        Documented here because it is accepted from the wire and was
+                        not in this spec before 2026-10-11. It must reference an
+                        approval that a human set to approved, raised for this agent
+                        and this transaction, and not already used. Anything else is
+                        403, including an approval that is still pending — which
+                        previously succeeded, because the only check was that the
+                        transaction row was still awaiting_approval, a state the
+                        caller reaches by submitting in the first place.
+
+
+                        Single-use. A second resume of the same approval is 403.
                 raw_transaction:
                     type: string
                     description: >
@@ -24443,12 +24481,14 @@ components:
                         Prefer `agent_api_keys`.
                 agent_api_keys:
                     type: array
+                    maxItems: 1
                     description: |
-                        Every agent created by this call, with its one-time API key.
-                        Returned once and never retrievable again: a platform app
-                        cannot rotate a key in the end user's org, so a key missed
-                        here is gone. The singular `agent_api_key` is the first of
-                        these and is kept for compatibility.
+                        The created agent and its one-time API key. Exactly one entry:
+                        provisioning is one agent per call, because a key is returned
+                        once and cannot be re-issued to a platform app, so a response
+                        carrying several would put several unrecoverable credentials in
+                        one payload. A template declaring more than one agent is
+                        refused with 400. The singular `agent_api_key` is the same key.
                     items:
                         type: object
                         properties:
@@ -27453,11 +27493,12 @@ components:
                                 agent the template created.
                         agent_api_keys:
                             type: array
+                            maxItems: 1
                             description: |
-                                Every agent created, with its one-time API key. Returned once:
-                                a platform app cannot rotate a key in the end user's org, so a
-                                multi-agent template used to strand agents 2..N with
-                                credentials nobody could recover.
+                                The created agent and its one-time API key. Exactly one entry:
+                                a template declaring more than one agent is refused with 400,
+                                because a key is returned once and cannot be re-issued to a
+                                platform app. Split such a template and bootstrap once per agent.
                             items:
                                 type: object
                                 properties:
@@ -29477,7 +29518,17 @@ components:
                 resume_after_approval_id:
                     type: string
                     format: uuid
-                    description: Internal — resume execution after human approval (server-injected).
+                    description: >
+                        Resume execution after a human approved it. Send the
+                        approval_id returned with the 202 approval_required response.
+
+
+                        Described here as "server-injected" until 2026-10-11, which was
+                        not enforced: the field is accepted from the wire and the gate
+                        checked only whether it was present, so any UUID skipped the
+                        approval requirement. It is now verified against an approved,
+                        agent-bound, unused approval and is single-use. Anything else,
+                        including a second use of the same approval, is 403.
 
         ExecutionApprovalRequired:
             type: object

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@1claw/openapi-spec",
-  "version": "0.61.59",
+  "version": "0.61.61",
   "description": "OpenAPI 3.1.0 specification for the 1Claw Vault API \u2014 generate clients in any language",
   "license": "MIT",
   "repository": {