Update template

Outcome

Update a signature template: its name, description, status, document, field schema, signer roles or defaults. Envelopes already created from it keep the terms they were created with.

Before you start

• Verify the environment, authenticated identity and specifically approved organization context.
• The published application permission is workspace:write. Resolve and bind the exact canonical Sign workspace. A supplied id or organization membership alone grants no workspace access.
• Session callers require read_write or admin workspace access. API-key resource binding is verified by Auth; never treat a caller-supplied header as an independent grant.
• Approve the documented mutation and actual recipient/document targets before CLI --confirm or MCP confirm:true. A synthetic fixture authorizes no live agreement, notification or data deletion.

Discover the target

topolo whoami --json
topolo actions get app_topolo_sign.templates.update --detail --json
topolo resources topolo-sign --json
topolo workspaces list topolo-sign --json

• Set SIGN_WORKSPACE_ID to the exact granted workspace returned by discovery.
• Discover templateId through templates.list/get; confirm active status before creating an envelope from it.
• Discover documentId and documentRef from upload or authorized retained metadata; they are distinct identifiers.

Request

PATCH /api/templates/{templateId}

Inspect and test this action. Save the reviewed input as payload.json. Supply resource context separately.

Input fields

Read the complete input schema.

Effects

• Replaces the template fields you supply: name, description, status, document, field schema, signer roles and defaults.
• Envelopes already created from the template keep the terms they were created with — this never rewrites an issued agreement.
• Setting a non-active status stops the template seeding new envelopes.

Interpret the response

Read $.template.id for the returned template identifier. An empty collection does not discover a target.

Call templates.get and confirm the changed fields read as sent.

Inspect the success schema. CLI/MCP add their transport envelope; --detail requests the full CLI result. HTTP 204 contains no JSON payload.

Worked examples

Captured from the exported Sign Worker with the existing SQLite-backed D1 harness applying all core, envelope and audit migrations to one local database, in-memory R2 and synthetic Auth/workspace/archive/Notify transports. These examples prove local validation, persistence and artifact production. They do not prove separate deployed D1 topology, real recipient consent, provider delivery or a live signed agreement. All identities, signing links and documents are synthetic; replace identifiers through authorized discovery and never execute a fixture against a live organization. Binary download examples use the released SDK binary projection; tests Base64-decode and compare original bytes, lengths and server SHA-256 headers.

Supported request · Update template metadata

Input · payload.json:

{
  "templateId": "8a821f8b-b0d1-4808-a92e-8d3f16e4228f",
  "description": "Reviewed local fixture"
}

CLI:

topolo actions validate app_topolo_sign.templates.update --data @payload.json --json
topolo actions plan app_topolo_sign.templates.update --resource-type workspace --resource-id "$SIGN_WORKSPACE_ID" --data @payload.json --json
topolo actions call app_topolo_sign.templates.update --resource-type workspace --resource-id "$SIGN_WORKSPACE_ID" --data @payload.json --confirm --detail --json

MCP tool and arguments:

{
  "tool": "topolo_call_action",
  "arguments": {
    "actionId": "app_topolo_sign.templates.update",
    "input": {
      "templateId": "8a821f8b-b0d1-4808-a92e-8d3f16e4228f",
      "description": "Reviewed local fixture"
    },
    "resourceType": "workspace",
    "resourceId": "<exact granted id from discovery>",
    "confirm": true,
    "detail": true
  }
}

Captured exported Worker response · HTTP 200:

{
  "template": {
    "id": "8a821f8b-b0d1-4808-a92e-8d3f16e4228f",
    "name": "Fixture agreement",
    "description": "Reviewed local fixture",
    "status": "active",
    "documentTitle": "Fixture agreement",
    "documentRef": "sign-document:92c3741e-171c-439c-9419-597ffe485224",
    "defaultSubject": "Review the fixture",
    "defaultMessage": "Synthetic local example only.",
    "signerRoles": [
      "Signer"
    ],
    "fieldSchemaVersion": 2,
    "fields": [
      {
        "id": "fixture_signature",
        "type": "signature",
        "label": "Signature",
        "required": true,
        "assignee": {
          "role": "Signer",
          "capacity": "personal"
        },
        "placement": {
          "page": 1,
          "x": 0.1,
          "y": 0.7,
          "width": 0.3,
          "height": 0.08
        }
      }
    ],
    "fieldSchema": [
      "fixture_signature"
    ],
    "createdByEmail": "operator@example.test",
    "createdAt": "2026-10-05T18:07:40.450Z",
    "updatedAt": "2026-10-05T18:07:40.458Z"
  }
}

HTTP 200. Call templates.get and confirm the changed fields read as sent.

Refused request · HTTP 401

Input · payload.json:

{
  "templateId": "aee5622d-8cf4-41bc-873a-e2b0fe0f454f",
  "description": "Reviewed local fixture"
}

CLI:

topolo actions validate app_topolo_sign.templates.update --data @payload.json --json
topolo actions plan app_topolo_sign.templates.update --resource-type workspace --resource-id "$SIGN_WORKSPACE_ID" --data @payload.json --json

Captured exported Worker response · HTTP 401:

{
  "error": "Token validation failed"
}

HTTP 401. Resolve the exact refusal before retrying. This request is not a successful workflow.

Refused request · HTTP 403

Input · payload.json:

{
  "templateId": "aee5622d-8cf4-41bc-873a-e2b0fe0f454f",
  "description": "Reviewed local fixture"
}

CLI:

topolo actions validate app_topolo_sign.templates.update --data @payload.json --json
topolo actions plan app_topolo_sign.templates.update --resource-type workspace --resource-id "$SIGN_WORKSPACE_ID" --data @payload.json --json

Captured exported Worker response · HTTP 403:

{
  "error": "This workspace requires read_write access",
  "code": "workspace_access_insufficient"
}

HTTP 403. Resolve the exact refusal before retrying. This request is not a successful workflow.

Verify the result

• Call templates.get and confirm the changed fields read as sent.

Errors and recovery

• organization_required (HTTP 403): The token carries no organization scope. Re-authenticate against the organization that owns the workspace and retry.
• template_not_found (HTTP 404): No template in this workspace carries that id. Call templates.list and use an id from the response.
• invalid_template (HTTP 400): The template failed validation. name must stay non-empty; fields follow the same structured field rules as envelopes.create (the error code names the rule, detail the field).
• auth_error (HTTP 401): Reauthenticate in the same approved context before retrying.
• workspace_access_insufficient (HTTP 403): Discover the actual workspace grant and obtain the documented required access; do not retry with a guessed workspace or broader organization.

Some existing refusals return a human message as error rather than a stable code; preserve the actual response, status and request id. Platform validation, authentication and resource checks can refuse before the handler.

Recovery boundary

Call this action again with the previous values; read templates.get first and keep the response if you need an exact restore.

Related actions

• Get template: Get one signature template with its document, field schema, signer roles and defaults.
• Create envelope: Create a signature envelope as a DRAFT. Nothing is sent and no signer is contacted; the envelope stays editable until envelopes.send. Seed it from an active template, or supply the document, fields and recipients directly.

Evidence

Captured from the exported Sign Worker with the existing SQLite-backed D1 harness applying all core, envelope and audit migrations to one local database, in-memory R2 and synthetic Auth/workspace/archive/Notify transports. These examples prove local validation, persistence and artifact production. They do not prove separate deployed D1 topology, real recipient consent, provider delivery or a live signed agreement. All identities, signing links and documents are synthetic; replace identifiers through authorized discovery and never execute a fixture against a live organization. Binary download examples use the released SDK binary projection; tests Base64-decode and compare original bytes, lengths and server SHA-256 headers.