Production-grade orchestration is a moving target. Releases, fixes, and policy changes ship from the docs and surface here automatically.
Use any OpenRouter chat model with the LLM Router
LLM Router
Use any OpenRouter chat model with the LLM Router
POST /v1/chat/completions accepts any chat model ID from OpenRouter's model list. Send the ID exactly as listed.
Available Models now lists our featured models and every other available model, and shows the matching OpenRouter ID when a featured model's ID differs.
Pricing is the model's list price plus the same standard platform fee OpenRouter charges, nothing more.
The model catalog API reference moved to each::router.
Open a webhook on the Webhooks page and choose Redeliver to send the same payload to your endpoint again, without re-running the execution.
The button is offered only when a redelivery would be accepted, and names the reason when it would not: a delivery still in flight, a short cooldown after a previous redelivery, or a payload that is no longer stored.
A redelivery carries X-Webhook-Redelivery: true, which an ordinary delivery never sends, so your endpoint can tell the two apart.
Signed webhooks are signed again when the redelivery is sent, so it passes your timestamp tolerance rather than looking like a replayed request. See Redeliveries are signed again.
The body is unchanged, so handle deliveries idempotently and key on execution_id.
POST /v1/decisions answers typed questions over one shared context and returns structured results instead of prose: a noul question gives you a probability, a choice question a named option, and a score question a rating on an ordered scale.
Send model: "typesafe/jev-1.13" with state and questions, authenticated with the same Bearer API key as the rest of each::api. The response carries answers keyed by your question names plus billable usage.
The model is routed through OpenRouter to TypeSafe Jev. This API is in alpha and its contract may change — see the Decisions API page.
Webhook deliveries are now signed with HMAC-SHA256
API
Webhook deliveries are now signed with HMAC-SHA256
Set a webhook_secret when creating a prediction or triggering a workflow, and every delivery for that execution now carries X-Webhook-Signature and X-Webhook-Timestamp.
The signature is an HMAC-SHA256 over <X-Webhook-Timestamp>.<raw request body>, hex-encoded and prefixed with sha256=.
The plain-text X-Webhook-Secret header is still sent, so receivers comparing it keep working. Verify the signature instead — it also proves the body was not modified.
Deliveries triggered without a webhook_secret are unchanged and remain unsigned.
GET /v1/models/{slug} is now the single route for retrieving model details. It returns the same payload as before, including the nullable cost guidance.
The deprecated GET /v1/model?slug= query route has been removed. Update any integration that used it to GET /v1/models/{slug}.
Control execution and storage retention for your organization
Organization Settings
Control execution and storage retention for your organization
Organization Settings now puts execution data and stored file retention in your hands. Choose how long each type of data is kept to match your team's needs.
Manage execution retention and storage retention separately, with automatic cleanup based on your organization's settings.
Review and update your retention preferences in one place as your team's data policies evolve.
An easier LLM Router interface and errors by model
LLM Router
An easier LLM Router interface and errors by model
LLM Router now uses the same model-aware form on model pages and in both workflow editors. Edit prompts, upload images, and adjust supported options through familiar controls that adapt to your selected model.
In Canvas Workflows, add and connect LLM Router like any other model card. The shared interface makes it easier to move from trying a model to using it in a workflow.
Error Analytics now breaks down LLM Router errors by the requested model, so you can see which models are failing and focus your investigation.
GET /v2/executions lists organization-wide execution history in descending creation order with the same filters as V1, a default limit of 20, and a maximum limit of 100. Authenticate with your API key as a Bearer token.
Follow the opaque next_cursor only while has_more is true. Keep the same filters and limit for each page; restart without a cursor to change them.
GET /v1/executions is deprecated but remains available for shallow compatibility. Requests beyond the 1,000-row prefix (offset <= 1000 - appliedLimit) return {"error":"V1 execution pagination is limited to 1000 rows; use GET /v2/executions with cursor pagination"}.
The dashboard now has Activity → Alerts for organization-wide spending alerts.
Create threshold rules for rolling charged spend, enable or disable them, and review the 20 most recent triggers from the same page.
Alert emails are sent to the organization owner and billing managers, with the charged spend, threshold, rolling window, and evaluation time included for reconciliation.
Replay re-runs a sample of successful past executions on a compatible test model, so you can compare outputs and cost on your real inputs before switching.
Pick a time window and sample size, then confirm the suggested field mapping. The preview shows which runs are eligible, explains any skips, and gives you the original sample's baseline cost before you start.
Set a soft cost cap, pause or resume an active test, and inspect the original and replayed inputs and outputs side by side. The final totals show how the test model's actual cost compares with the original runs.
You can also keep the same model and change its mapped inputs to test a parameter variant without changing live traffic.
Direct-model fallback lets an async prediction recover when its primary model fails. Compatible fallback models are tried in the order you choose, and the first success completes the original request; when the primary succeeds, the backups do not run.
Open a model from AI Models and choose Fallbacks to create one or more named chains. Start from a curated recommendation when one is available, or pick compatible models yourself, reorder them, and confirm how the primary model's inputs map to each fallback.
Every chain has a stable request selector. Add "fallback_selector": "your-chain" to an async prediction request to use it. Only enabled, saved chains run, and changes apply to new requests.
GET /v1/models/{slug} and GET /v1/model?slug={slug} include a nullable cost field with a fixed estimate or concise usage-based guidance when a reliable public estimate is available.
Estimates may change with provider rates, promotions, or model configuration. Use metrics.cost on the completed prediction or workflow execution for the settled value.
GET /v1/billing/balance returns your authenticated organization's USD balance as a number, using the same Bearer API key as the rest of each::api.
The route has no organization selector and returns no wallet, credit, organization, or credential details.
Balance reads are eventually consistent after a top-up. Retry with bounded backoff under the process-local 3 requests-per-second, burst-3 limit; a limited request returns 429 with Retry-After: 1, and an unavailable balance returns 503 instead of a fabricated zero.
Build an HTTP step from a cURL command, and decide when it fails
each::workflows
Build an HTTP step from a cURL command, and decide when it fails
Paste a cURL command from a provider's docs into an HTTP request step and it fills itself in — method, URL, headers, query parameters, and body. An import now replaces the form rather than merging into it, so fields the command does not mention stop carrying values from the import before it.
Pick a field out of the response instead of guessing at it. An HTTP step offers its response body and its status_code wherever you choose a reference, so you can feed one field into the next step or branch on a 200 against a 429. The picker learns the shape of a response from the last run, from Send test request, or from a sample response you paste into the step's settings, and pins any media it finds to the top.
A Fail when rule decides what counts as a failure: connection errors only, any non-2xx response, or a list of status codes you name. A 503 from your endpoint no longer reads as a successful step.
An HTTP step can name a second request as its fallback, not just a model. When a response matches the failure rule, the backup request runs instead of the workflow carrying a bad response forward.
A failure raised by the rule names the status it saw and the rule that rejected it, instead of a generic service error.
The step timeout has a five-second floor, so a mistyped value cannot fail every request.
Both editors get all of it: the HTTP card on the canvas and the HTTP step in the step editor.
⌘C on the canvas now copies to your system clipboard, so a copy outlives the tab that made it. Paste those cards into a second tab, or into an entirely different workflow.
Cards pasted into a different workflow arrive with credential parameters stripped. Paste back into the workflow you copied from and they come through untouched.