Topolo Docs Topolo Platform
Open workspace

List templates

List signature templates in this workspace with their status, signer roles and default subject and message.

Outcome

List signature templates in this workspace with their status, signer roles and default subject and message.

Before you start

  • Verify the environment, authenticated identity and specifically approved organization context.
  • The published application permission is workspace:read. Resolve and bind the exact canonical Sign workspace. A supplied id or organization membership alone grants no workspace access.
  • Session callers require read workspace access. API-key resource binding is verified by Auth; never treat a caller-supplied header as an independent grant.

Discover the target

topolo whoami --json
topolo actions get app_topolo_sign.templates.list --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.

Request

GET /api/templates

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

Input fields

Use an empty input object; credential and resource context are separate.

Read the complete input schema.

Effects

  • List signature templates in this workspace with their status, signer roles and default subject and message.

Interpret the response

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

Read the exact response and retain discovered identifiers for the documented follow-up action.

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 · List the persisted template

Input · payload.json:

{}

CLI:

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

MCP tool and arguments:

{
  "tool": "topolo_read_action",
  "arguments": {
    "actionId": "app_topolo_sign.templates.list",
    "input": {},
    "resourceType": "workspace",
    "resourceId": "<exact granted id from discovery>",
    "detail": true
  }
}

Captured exported Worker response · HTTP 200:

{
  "templates": [
    {
      "id": "8a821f8b-b0d1-4808-a92e-8d3f16e4228f",
      "name": "Fixture agreement",
      "description": "",
      "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.450Z"
    }
  ]
}

HTTP 200. Read the exact response and retain discovered identifiers for the documented follow-up action.

Refused request · HTTP 401

Input · payload.json:

{}

CLI:

topolo actions validate app_topolo_sign.templates.list --data @payload.json --json
topolo actions plan app_topolo_sign.templates.list --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.

Verify the result

  • Read the exact response and retain discovered identifiers for the documented follow-up action.

Errors and recovery

  • auth_error (HTTP 401): Reauthenticate in the same approved context before retrying.

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

This read changes no organizer data. Resolve identity, permission, resource binding or target state and repeat the same reviewed read. Do not turn a refused read into a mutation.

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.