Skip to main content
Prompt Templates let you define a system prompt, base conversation turns, and default inference parameters once — then reference them by name from any chat completion request. Instead of hardcoding the same prompt logic in every client, you manage it centrally and inject runtime values using {{variable}} slots.

Authentication

Template management (create, read, update, delete) accepts either authentication method: Using a template at inference time always uses your rsk_... key, the same as any other chat completion. See the Authentication guide for details on key types.

Creating a Template

Send a POST /v1/templates request with a name, an optional system prompt, and any variables you want to parameterize.
Response:
Template ids are UUIDs. Creating a template saves and publishes version 1.

Using Variables

Variables use double-brace syntax: {{ variable_name }}. Whitespace inside the braces is trimmed, so {{company}} and {{ company }} are equivalent. Variable names may contain letters, digits, and underscores. You can place variables in system and in any message content field:
The variables field (list of strings) is informational — it documents which slots the template expects. It doesn’t enforce anything server-side, but it helps callers know what to pass.
Missing variables at inference time cause a 422 error. Extra variables in the request are silently ignored. Variable values must be strings.

Using a Template in Chat Completions

Pass template (name or UUID) and variables alongside your messages in a POST /v1/chat/completions request. The template’s system prompt and base messages are prepended to your messages before the request is forwarded to the model.
The final messages sent to the model look like this:
You can reference a template by name or UUID. Name lookups are scoped to your key’s owner first, then fall back to global (admin-seeded) templates. UUID lookups work across any owner. Any value that isn’t a UUID is treated as a name.
By default a request uses the template’s published version. To freeze on a specific release, add template_version (a published version number) next to template; a version that doesn’t exist or was never published returns 404.

Parameter Priority

When a template and a request body both specify inference settings, Mesh resolves them in this order (highest wins): This means you can define sensible defaults in the template and still override them per-request without changing the template. The model resolves the same way: the request body’s model, then your key’s default model, then the template’s.

Managing Templates

List all templates

Returns your owned templates plus any global templates, ordered newest first. Add ?scope=custom for the non-global templates you can see, or ?scope=global for only the global templates your organization has enabled (the default is all).

Get a single template

Update a template

PATCH changes metadata: name and description. Only the fields you include are changed.
The content fields (system, messages, model, params, variables) are still accepted on PATCH, but deprecated: sending them saves and publishes a new version in one step. Use the version endpoints below to change content.

Versions

Content is versioned. Every save creates a new, immutable version; only the published version serves inference.
Saving never changes what’s live until you publish. A key with read-only template access sees only published versions.

Delete a template

Returns 204 No Content on success.

Global vs. Owned Templates

Global templates are useful for standard system roles (e.g., a generic coding assistant or translation prompt) that Mesh pre-seeds for all users. If you create a template with the same name as a global one, your owned template takes precedence in name lookups.
UUID-based lookups are intentionally cross-owner — this lets you share a template with another team by passing them the template ID. Name-based lookups are always scoped to your own account, so there’s no risk of accidentally using someone else’s template by name.