Sume output_schema name: slashes allowed, rewritten upstream

Names like sume/action-image-v1 are accepted (A-Z a-z 0-9 . _ / -, up to 64 chars) and echoed back unchanged. Only the structuring call sees a rewritten name.

4 min readSume
All posts

A Sume output_schema.name may contain A-Z a-z 0-9 . _ / - and be up to 64 characters, so sume/action-image-v1 is a valid name. The name you send is the name you get back: the run receipt reports output_schema.name exactly as typed. Sume only rewrites it internally, replacing anything outside A-Z a-z 0-9 _ -, because the provider that does the structuring call accepts a narrower character set. That rewrite is never visible through the API.

This matters if you diff receipts against your own schema registry, or if a team convention puts a namespace and version in the name. You do not need to strip slashes or dots before sending.

Name rules at a glance

The rules come from the Create a schedule page and the Agent Completions page, which say output_schema follows the same contract as Action runs.

output_schema name handling, per Sume docs (read 2026-10-03)
QuestionAnswer
Allowed charactersA-Z a-z 0-9 . _ / -
Maximum length64 characters
Characters rewritten for the structuring modelAnything outside A-Z a-z 0-9 _ -
Name on the receiptThe one you typed
Is the rewrite visible?No

The schema still has to satisfy the strict subset

A valid name does not make a schema valid. Custom schemas must follow the strict subset the docs describe, the same one OpenAI Structured Outputs enforces: the root is an object, every object sets additionalProperties to false, every property is listed in required with optionality expressed as a nullable union such as ["string", "null"], nesting stops at 10 levels, and $ref may point only at #/$defs/<name> or the registered SumeMediaFile#.

Setting strict: false is accepted and echoed on the receipt, but it does not relax any of this. Sume only fills schemas it can mechanically satisfy, so a schema outside the subset is rejected with output_schema_invalid and a list of violations before any run starts.

Choosing a name that stays readable

Because the receipt echoes your name, treat it as an identifier you control. A pattern such as team/purpose-v1 sorts well in logs, and bumping the suffix when the schema changes lets you tell old receipts from new ones. Remember the 64-character ceiling counts the slashes.

The name is also the thing you will search for when an output fails to project. A run can complete and bill you while output is null and output_error explains why, so a descriptive name saves time when you scan failed receipts by hand.

A per-run override

On Action runs you can override the schedule's bound schema for one run. The receipt then reports output_schema.source as request_override, while a schedule's own binding shows up as action_default.

``json { "input": { "product_name": "Aurora Headphones" }, "output_schema": { "name": "sume/action-image-v1", "strict": true, "schema": { "type": "object", "additionalProperties": false, "required": ["caption", "image"], "properties": { "caption": { "type": ["string", "null"] }, "image": { "$ref": "SumeMediaFile#" } } } }, "primary_output_key": "image" } ``

Send either output_schema or the OpenAI-shaped response_format alias, never both; both together is a 400 invalid_request. Because the schema is part of the idempotency payload, replaying a key with a different schema returns 409 idempotency_conflict. If a schema fails, the violations guide shows how to read the paths.

Sources

Related posts

More in Agents

All Agents posts

Written by Sume