Topolo Docs Topolo Platform
Open workspace

Get template

Get one signature template with its document, field schema, signer roles and defaults.

Outcome

Get one signature template with its document, field schema, signer roles and defaults.

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

Request

GET /api/templates/{templateId}

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

Input fields

FieldRequiredMeaningConstraints
templateIdRequiredExact template.id from templates.list/get; creating from a template requires active status.{"minLength":1}

Read the complete input schema.

Effects

  • Get one signature template with its document, field schema, signer roles and defaults.

Interpret the response

Read $.template.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 · Read the retained template

Input · payload.json:

{
  "templateId": "8a821f8b-b0d1-4808-a92e-8d3f16e4228f"
}

CLI:

topolo actions validate app_topolo_sign.templates.get --data @payload.json --json
topolo actions plan app_topolo_sign.templates.get --resource-type workspace --resource-id "$SIGN_WORKSPACE_ID" --data @payload.json --json
topolo actions call app_topolo_sign.templates.get --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.get",
    "input": {
      "templateId": "8a821f8b-b0d1-4808-a92e-8d3f16e4228f"
    },
    "resourceType": "workspace",
    "resourceId": "<exact granted id from discovery>",
    "detail": true
  }
}

Captured exported Worker response · HTTP 200:

{
  "template": {
    "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:

{
  "templateId": "aee5622d-8cf4-41bc-873a-e2b0fe0f454f"
}

CLI:

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