Tessryx

Check whether a resource and everything it depends on is sound — the deployability question. Pass 'hypothetical' to preview a change instead: hypothetical='delete' or 'unpublish' reports what would break WITHOUT changing anything (run it before deleting something other resources may use), and hypothetical='publish' checks whether the draft you are about to publish actually resolves. An APP is the usual subject: it walks every root the app contains (endpoints, schedules, domains) to the end of each chain and reports what would break. Returns findings {resource, path, severity, check, message}: errors are broken now (a reference that does not resolve, a dependency never published, a declared domain that routes elsewhere), warnings are risks (a published resource following @latest, a sub-work

Api template authoring — create a BRAND-NEW api template (mints the template + its version 1). Fetch the definition's JSON Schema with get_api_template_definition_schema and author against it. Iterate with execute_api_template before wiring the template into a workflow; pass publish=true to publish in the same step once you're happy. (To add a version to an api template that already exists, use create_api_template_version.)

Api template versioning — add a new version to an EXISTING api template (by template_id) to evolve an api template you already created. Author the new version's definition against the schema from get_api_template_definition_schema. Pass publish=true to publish this api template version immediately. (For a brand-new api template, use create_api_template.)

App authoring — create a BRAND-NEW app (mints the app + its version 1). Start here when building a page or an API bundle: choose the app's slug (its folder prefix, e.g. 'storefront'), then author each member resource under that prefix (storefront/page, storefront/products, storefront/checkout, …) so the app's prefix rule captures them automatically — you never hand-add members. The definition holds the membership selector (prefix rules + includes/excludes) and display; fetch its JSON Schema with get_app_definition_schema and author against it. An empty definition is a valid draft, but publishing requires a membership that selects something. Pass publish=true to publish v1 immediately. (To add a version to an existing app, use create_app_version.)

App versioning — add a new version to an EXISTING app (by app_id) to change its membership selector (prefix rules, includes/excludes) or display. Author the new version's definition against the schema from get_app_definition_schema. Pass publish=true to make it the live manifest immediately. (For a brand-new app, use create_app.)

Claim a custom hostname for this tenant and generate its DNS challenge. The claim alone grants NOTHING until ownership is proven — it returns TWO DNS records (an ownership TXT and a permanent routing CNAME) in dns_records that the customer must add at their DNS provider. Present those records to the human, wait for them to add them, then call verify_custom_domain. slug_prefix/root_endpoint are optional here and are usually set later with update_custom_domain (after the domain verifies).

Create a new datafile holding a JSON object. A datafile MUST be bound to a schema (schema_id) — the schema validates the JSON and generates the human editor; author or pick one with the schema tools first. Property order in json is preserved verbatim. Publish it with publish_datafile to serve it from the CDN.

Dynamic endpoint authoring — create a BRAND-NEW dynamic endpoint (mints the endpoint + its version 1). The definition binds the endpoint to a workflow (by versioned-slug reference) plus a cache setting; fetch its JSON Schema with get_dynamic_endpoint_definition_schema and author against it. Pass publish=true to take the endpoint live in one step, or publish later with publish_dynamic_endpoint. (To add a version to a dynamic endpoint that already exists, use create_dynamic_endpoint_version.)

Dynamic endpoint versioning — add a new version to an EXISTING dynamic endpoint (by endpoint_id) to evolve a dynamic endpoint you already created. Author the new version's definition against the schema from get_dynamic_endpoint_definition_schema. Pass publish=true to take this dynamic endpoint version live immediately. (For a brand-new dynamic endpoint, use create_dynamic_endpoint.)

Schedule authoring — create a BRAND-NEW schedule (mints the schedule + its version 1). The definition names a workflow (versioned-slug ref, published/latest), a recurrence (EITHER a 5-field cron + IANA timezone, OR an 'every N minutes/hours' interval), and an optional static input bound as the workflow's $input on every fire; fetch its JSON Schema with get_schedule_definition_schema and author against it. Pass publish=true to activate it (start firing) in one step, or publish later with publish_schedule. (To add a version to a schedule that already exists, use create_schedule_version.)

Schedule versioning — add a new version to an EXISTING schedule (by schedule_id) to change its cron, timezone, workflow, or input. Author the new version's definition against the schema from get_schedule_definition_schema. Pass publish=true to activate this version immediately. (For a brand-new schedule, use create_schedule.)

Schema authoring — create a BRAND-NEW schema (mints the schema + its version 1). json_schema is the JSON Schema body datafiles bound to this schema (by schema_id) are validated against; property order is preserved exactly — it sets the field order of the generated editor, so author it in the order you want humans to see. Media uploads, entity references, cron and colors need an x-tessryx-ui hint or they render as bare text — get_guide("schemas"). Pass publish=true to publish schema version 1 immediately (the version datafiles resolve by default), or later with publish_schema. (To add a version to a schema that already exists, use create_schema_version.)