trezalabs

Starts a run of the deployed pipeline snapshot with the given inputs. Returns a runId immediately; poll the GET variant of this path for status and outputs.

Drop-in replacement for the OpenAI chat completions API. Point any OpenAI SDK at this base URL with a Treza API key. The latest user message is fed into the pipeline and the pipeline output is returned as the assistant message. Supports streaming via server-sent events.

Adds a fixed amount of Treza credit per call, paid via the x402 protocol (HTTP 402): call without payment to receive a 402 challenge carrying the price and networks, sign the payment with an x402-capable wallet, and retry with the payment-signature header. The challenge lists two ways to pay the same amount: USDC on Base (eip155:8453) first, then USDC on Solana mainnet (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp); a client pays the first one it has a wallet for, and neither needs gas money in the paying wallet. Grants are idempotent per settled transaction. A bearer (API key, OAuth token, or session) is optional and only chooses which account is credited; without one the credits are keyed to the paying wallet, so an agent holding nothing but a wallet can still fund itself. A Base wallet and a Solana wallet are separate accounts, and their balances are not shared. Only available when the deployment has x402 enabled; the balance endpoint's x402 field says so.

Generates a video from a text prompt, or animates an image_url from its first frame. The paid response waits about as long as the chosen model usually takes to render and returns the video URL when it is ready, otherwise a statusUrl to poll. Pay via the x402 protocol (HTTP 402): call without payment to receive a 402 challenge carrying the price and networks, sign the payment with an x402-capable wallet, and retry with the payment-signature header. The challenge lists two ways to pay the same amount: USDC on Base (eip155:8453) first, then USDC on Solana mainnet (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp); a client pays the first one it has a wallet for, and neither needs gas money in the paying wallet. No account, API key, or signup is involved, so the payment is the only credential. A payment presented again after it was redeemed is refused with a 409 (code PAYMENT_ALREADY_REDEEMED) rather than rendered twice. Price is quoted per request and depends on the model and clip length you pick, so send the model and seconds you want and read the amount off the challenge rather than assuming a fixed figure; GET this path with no parameters for every model and price. Only the documented fields are read; a request carrying any other field is refused with a 400 before any payment moves, so nothing you send can be silently ignored and paid for. An image_url with no model renders on the cheapest model that takes an image at the length you ask for (wan-2.7 for 5 or 10 seconds, kling-3.0 for 15, veo-3.1-lite for 4, 6 or 8 or when you name no length), and the 402 quotes that model's price. The image is fetched and checked before the payment settles, so an image that cannot be used is refused (400, or 413 when it is too large, with a code) with nothing charged. The paid call answers 200 at once, with the statusUrl in the X-Status-Url header, then sends a whitespace byte every 2 seconds while it waits (JSON parsers ignore it), and ends with one complete JSON object. By default it waits about as long as that model and length usually take to render (at least 45 seconds, about two and a half minutes for 5 seconds on minimax-h3, up to about ten for 15 seconds on seedance-2.5), so a caller that does not poll still gets its video; a client with a fixed timeout, such as the 60 seconds MCP tool calls allow, should send Prefer: wait=N or respond-async, and has the statusUrl in the X-Status-Url header either way. Read status in that body: success carries the video URL; error or partial means the render failed, nothing was charged for it, and retryUrl renders again on the wallet balance the payment left, without paying twice; running means the render is still going, so poll statusUrl. Send Prefer: wait=N to wait up to N seconds instead (at most 720). To get the statusUrl at once, send "async": true in the body or the header Prefer: respond-async, and the call answers at once, still 200, with status running, a runId and a statusUrl to poll. Preference-Applied echoes the preference that was honoured. Lost the statusUrl? GET /api/x402/purchases and sign its challenge with the paying wallet (Sign-In-With-X, free) to list every purchase with its file and a fresh statusUrl. And the same request sent again from the same wallet, once the first render has finished and its file never reached you, is answered with that file (alreadyPaid, paidUsd 0) and the new payment is not taken.

A render that failed after the payment settled (the model refused the prompt, or the render did not finish) charged nothing, so the payment is still on the wallet's balance. POST here with the failed run's claim ticket to render again on that balance. Send {"prompt": "..."} to reword the prompt, which is the fix for prompt_refused; send no body to render the original prompt again. The retry renders the same model, length, aspect ratio, and first frame the failed run was sold. Each failed run can be retried once. Like the paid POST, it waits by default about as long as that model usually takes to render (Prefer: wait=N, at most 720) and ends with the result, or with status running and a statusUrl, in the same streamed 200 response; send "async": true, or the header Prefer: respond-async, for an immediate answer (200, status running) with a new runId and statusUrl. A run whose render outlasted its deadline is refused (409) while its clip is being collected.

Speaks up to 3000 characters of text in one of over 30 ElevenLabs voices and returns an MP3, usually within seconds. Priced per character ($0.42 per 1,000, rounded up to the cent, minimum $0.02); the 402 quotes the exact figure for your text. Pay via the x402 protocol (HTTP 402): call without payment to receive a 402 challenge carrying the price and networks, sign the payment with an x402-capable wallet, and retry with the payment-signature header. The challenge lists two ways to pay the same amount: USDC on Base (eip155:8453) first, then USDC on Solana mainnet (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp); a client pays the first one it has a wallet for, and neither needs gas money in the paying wallet. No account, API key, or signup is involved, so the payment is the only credential. A payment presented again after it was redeemed is refused with a 409 (code PAYMENT_ALREADY_REDEEMED). Only the documented fields are read; a request carrying any other field is refused with a 400 before any payment moves. The paid call answers 200 at once, with the statusUrl in the X-Status-Url header, then sends a whitespace byte every 2 seconds while it waits (JSON parsers ignore it), and ends with one complete JSON object. Read status in that body: success carries audio, the URL of the speech; error means it failed, nothing was charged for it, and retryUrl tries again on the wallet balance the payment left, without paying twice; running means it outlasted the wait (45 seconds by default, Prefer: wait=N for up to 720), so poll statusUrl. Send "async": true or Prefer: respond-async for an immediate answer (200, status running) with a statusUrl. Lost the statusUrl? GET /api/x402/purchases and sign its challenge with the paying wallet (Sign-In-With-X, free) to list every purchase with its file and a fresh statusUrl. And the same request sent again from the same wallet, once the first render has finished and its file never reached you, is answered with that file (alreadyPaid, paidUsd 0) and the new payment is not taken.

A speech that failed after the payment settled charged nothing, so the payment is still on the wallet's balance. POST here with the failed run's claim ticket to try again on that balance, with the same settings it was sold with. Send {"text": "..."} to reword it (the fix for prompt_refused), or no body to use the original. Each failed run can be retried once. Waits and streams like the paid POST; "async": true or Prefer: respond-async answers at once (200, status running).

Composes an original track from a description of genre, mood, instruments and tempo. lyria-3-clip: A 30-second piece: a bed for a short video, a sting, a loop. $0.06. lyria-3-pro: A full-length song with structure (intro, development, ending). $0.12. Pay via the x402 protocol (HTTP 402): call without payment to receive a 402 challenge carrying the price and networks, sign the payment with an x402-capable wallet, and retry with the payment-signature header. The challenge lists two ways to pay the same amount: USDC on Base (eip155:8453) first, then USDC on Solana mainnet (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp); a client pays the first one it has a wallet for, and neither needs gas money in the paying wallet. No account, API key, or signup is involved, so the payment is the only credential. A payment presented again after it was redeemed is refused with a 409 (code PAYMENT_ALREADY_REDEEMED). Only the documented fields are read; a request carrying any other field is refused with a 400 before any payment moves. The paid call answers 200 at once, with the statusUrl in the X-Status-Url header, then sends a whitespace byte every 2 seconds while it waits (JSON parsers ignore it), and ends with one complete JSON object. Read status in that body: success carries audio, the URL of the track; error means it failed, nothing was charged for it, and retryUrl tries again on the wallet balance the payment left, without paying twice; running means it outlasted the wait (45 seconds by default, Prefer: wait=N for up to 720), so poll statusUrl. Send "async": true or Prefer: respond-async for an immediate answer (200, status running) with a statusUrl. Lost the statusUrl? GET /api/x402/purchases and sign its challenge with the paying wallet (Sign-In-With-X, free) to list every purchase with its file and a fresh statusUrl. And the same request sent again from the same wallet, once the first render has finished and its file never reached you, is answered with that file (alreadyPaid, paidUsd 0) and the new payment is not taken.

A track that failed after the payment settled charged nothing, so the payment is still on the wallet's balance. POST here with the failed run's claim ticket to try again on that balance, with the same settings it was sold with. Send {"prompt": "..."} to reword it (the fix for prompt_refused), or no body to use the original. Each failed run can be retried once. Waits and streams like the paid POST; "async": true or Prefer: respond-async answers at once (200, status running).

Generates one image from a prompt on the model you pick, square to 21:9 and up to 4K where the model offers it. Each model sells its own aspect ratios and its own price setting (resolution or quality); GET this path with no parameters for every option and price, and read the amount off the 402 challenge. A setting the model does not honour is refused with a 400 rather than silently dropped. Pay via the x402 protocol (HTTP 402): call without payment to receive a 402 challenge carrying the price and networks, sign the payment with an x402-capable wallet, and retry with the payment-signature header. The challenge lists two ways to pay the same amount: USDC on Base (eip155:8453) first, then USDC on Solana mainnet (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp); a client pays the first one it has a wallet for, and neither needs gas money in the paying wallet. No account, API key, or signup is involved, so the payment is the only credential. A payment presented again after it was redeemed is refused with a 409 (code PAYMENT_ALREADY_REDEEMED). Only the documented fields are read; a request carrying any other field is refused with a 400 before any payment moves. The paid call answers 200 at once, with the statusUrl in the X-Status-Url header, then sends a whitespace byte every 2 seconds while it waits (JSON parsers ignore it), and ends with one complete JSON object. Read status in that body: success carries image, the URL of the image; error means it failed, nothing was charged for it, and retryUrl tries again on the wallet balance the payment left, without paying twice; running means it outlasted the wait (45 seconds by default, Prefer: wait=N for up to 720), so poll statusUrl. Send "async": true or Prefer: respond-async for an immediate answer (200, status running) with a statusUrl. Lost the statusUrl? GET /api/x402/purchases and sign its challenge with the paying wallet (Sign-In-With-X, free) to list every purchase with its file and a fresh statusUrl. And the same request sent again from the same wallet, once the first render has finished and its file never reached you, is answered with that file (alreadyPaid, paidUsd 0) and the new payment is not taken.

A image that failed after the payment settled charged nothing, so the payment is still on the wallet's balance. POST here with the failed run's claim ticket to try again on that balance, with the same settings it was sold with. Send {"prompt": "..."} to reword it (the fix for prompt_refused), or no body to use the original. Each failed run can be retried once. Waits and streams like the paid POST; "async": true or Prefer: respond-async answers at once (200, status running).

Send a YouTube link; get its most shareable 30 to 60 second moment back as a captioned clip reframed on the speaker (9:16 by default, or 4:5, 1:1, 16:9), with a title and caption to post it with. Priced by the source's length: the video is looked up before payment, the 402 quotes the exact price for it ($0.04 for a minute or less, $0.45 for an hour, up to 2 hours), and a video that cannot be clipped (private, age-restricted, live, missing, too long) is refused with a 400 and a code before any payment moves. Only YouTube video links are accepted. Pay via the x402 protocol (HTTP 402), in USDC on Base (eip155:8453) or Solana mainnet; no account, API key, or signup. A clip takes a few minutes: the paid call answers 200 at once with the statusUrl in X-Status-Url, waits about as long as a clip from that length of source usually takes (Prefer: wait=N for up to 720), then ends with status success and video, or status running and the statusUrl to poll. Clip only videos you have the rights to use. Lost the statusUrl? GET /api/x402/purchases and sign its challenge with the paying wallet (Sign-In-With-X, free) to list every purchase with its file and a fresh statusUrl. And the same request sent again from the same wallet, once the first render has finished and its file never reached you, is answered with that file (alreadyPaid, paidUsd 0) and the new payment is not taken.

A clip that failed after the payment settled charged nothing for the failed steps, so the payment is on the wallet balance. POST here with the failed run's claim ticket to try again, from the same link or, with {"url": "..."}, another YouTube video no longer than the one paid for. Each failed run can be retried once.

Send a topic; get a finished 30-second vertical short: a written script, four scenes, an ElevenLabs narrator, a music bed, word-by-word captions and callout cards, plus a title and description to post it with. style motion ($3.22) animates each scene with Google Veo 3.1 Lite; stills ($0.87) edits the scenes' stills with a slow push-in. Pay via the x402 protocol (HTTP 402), in USDC on Base (eip155:8453) or Solana mainnet; no account, API key, or signup. A short takes three to five minutes: the paid call answers 200 at once with the statusUrl in X-Status-Url, waits about as long as that style usually takes (Prefer: wait=N for up to 720), then ends with status success and video, or status running and the statusUrl to poll. If a step fails part way (a scene the video model refuses), the steps that ran are charged, the rest of the payment stays on the wallet balance, and the free retry resumes the run, re-rendering only what failed. Lost the statusUrl? GET /api/x402/purchases and sign its challenge with the paying wallet (Sign-In-With-X, free) to list every purchase with its file and a fresh statusUrl. And the same request sent again from the same wallet, once the first render has finished and its file never reached you, is answered with that file (alreadyPaid, paidUsd 0) and the new payment is not taken.

POST with the failed run's claim ticket. With no body the run resumes: steps that succeeded are reused and only what failed re-renders (a writer whose script a later step could not use is re-run, with everything after it), and the wallet balance must cover what will re-run, never more than the full price. With {"topic": "..."} it starts over, at the full price, from the wallet balance. Each failed run can be retried once.

Free. Everything the signing wallet bought from the pay-per-call endpoints in the last 30 days, newest first, for a buyer that lost its statusUrl. Called without a SIGN-IN-WITH-X header it answers 402 with a sign-in challenge and nothing to pay (accepts is empty; the challenge is the x402 sign-in-with-x extension, in the PAYMENT-REQUIRED header and the body). Sign it with the wallet that paid, a SIWE (EIP-4361) message on Base (eip155:8453, smart-contract wallets included) or a SIWS message on Solana, and send it back base64-encoded in the SIGN-IN-WITH-X header within five minutes; each challenge works once. agentcash signs it on its own; with @x402/fetch, register createSIWxClientExtension from @x402/extensions/sign-in-with-x. Each purchase comes with its file once finished, a fresh statusUrl, and a retryUrl when a render failed.

List the video pipelines on your Treza account, with status and a summary of recent runs.

Get one pipeline: metadata plus a summary of its node graph (node ids, types, labels). Pass includeGraph to get the complete graph — every node with position and config, and every edge — which is what update_pipeline needs as a starting point. Never write a graph reconstructed from the summary: it drops configs.

List recent runs for a pipeline, newest first.

Get one run: overall status plus per-node results and output URLs. Poll this after run_pipeline, assemble_video or edit_asset until the status is no longer "running". A finished run carries `outputs`, what its Output nodes returned (for assemble_video and edit_asset, the finished file). While a run is still "running", `nodes` lists the steps that have completed so far (with their outputs) and `finishedAt`/`durationMs` are omitted.

Start a pipeline run in the background and return its runId immediately. Video pipelines take minutes; poll get_run for progress. Runs consume account credits. `inputs` is keyed by entry node id (get_pipeline lists them as entryNodes): a Text Input node takes text, an HTTP Payload node takes a JSON value, and a File node takes a URL that overrides the file placed on the canvas, so a clipping pipeline can be pointed at a new source video per run without editing the graph. An entry node left out runs with the value saved on the canvas; one with nothing saved is refused, so pass it (or "" to leave it blank on purpose), and ask the user what it should say when the request does not tell you. A key that names no entry node is refused before anything runs or is charged. Before running a pipeline you built or changed in this conversation, call estimate_run_cost and wait for the person to accept the price. Every run renders every node again, so to add music, narration or captions to a video an earlier run made, pass its url from get_run outputs to assemble_video (musicPrompt composes a bed) or edit_asset rather than editing the pipeline and running it again.

Browse the account's media library: every image, video, and audio file its pipeline runs and chat generations produced, newest first. The urls it returns are the ones assemble_video and edit_asset accept, so start here when asked to cut, caption, score, or otherwise finish media the account already has. A file the user attached in the conversation is not here until import_media adds it. Clients that show panels let the person pick files from this list: the picks reach you as context naming each file by its #position in the list with its exact url, and the person then says in the chat what to do with them. Apply that to exactly those files, and do not assume picks mean joining them.

Add an image, video or audio file to the account's media library, so assemble_video and edit_asset can use it: a file the user attached in this conversation (file, where the client passes attachments), a public https link to the file itself (url), or a local file uploaded through create_upload_url (url set to its mediaUrl). Returns the library url. Putting an attached logo in the corner of a video or a picture is this, then edit_asset on the video or picture with an overlay operation whose inputs.image is the returned url and whose config.position names the corner (a picture comes back a PNG). Images up to 25 MB, audio 100 MB, video 200 MB; the type is read from the file, and anything else (SVG, PDF, a web page) is refused. When the user attached a file you cannot pass on (you see it but have no file or link to give), ask them to drop it into their Treza library at https://www.trezalabs.com/chat/assets and find it with list_assets. Needs the pipelines:write scope. Spends no credits.

A one-time link to upload a local file into the media library, for a client that can run a command (Claude Code, Codex, Cursor): PUT the file to uploadUrl with the returned Content-Type (the result includes the curl command), then call import_media with url set to the returned mediaUrl. The link expires in 15 minutes and signs one content type. If you cannot run a command, do not call this: ask the person to drop the file into their Treza library in the web app and find it with list_assets. Needs the pipelines:write scope. Spends no credits.

Join clips the account already has into ONE finished video, in the order given, optionally over a voiceover (narrationUrl) and a music bed, which become separate tracks with the clips ducked under the voice, and with burned-in captions. The bed is a track from the library (musicUrl) or one composed for this cut from a description (musicPrompt), never both. One clip plus a track is how to put music or narration under a single video: "add music to my video" is clipUrls [that video] with a musicPrompt, and no pipeline to build. Every url must come from list_assets or a run's outputs in get_run. Stills hold 3 seconds each, or stretch so a longer voiceover plays in full; lengthSec in the result is how long the cut will run, and any warning in it should be passed on. Renders in the background: poll get_run with the returned pipelineId and runId. Free once the account has bought credits (the result carries charged: false), so never ask a paying account to top up before assembling; charged on a trial. Needs the pipelines:run and pipelines:write scopes.

Run pipeline nodes over ONE video, image, or audio file the account already has and get the edited file back: captions, an upscale, background removal, lipsync, a crop, an overlay, a cutaway, a thumbnail, a trim, or any other transform in list_node_types. To put music under a video, use assemble_video with musicPrompt instead. Operations run in order, each fed the output of the one before, so "caption it and upscale it" is one call with two operations; a Transcribe stage is added wherever an operation needs a transcript. Check a node's config and ports with get_node_type first. A setting the node does not define, or a value outside what it offers, is refused with the valid ones listed. The source, and any url given as an input, must come from list_assets or a run's outputs in get_run. Renders in the background and spends credits: poll get_run with the returned pipelineId and runId. Needs the pipelines:run and pipelines:write scopes.

List the node types available for building pipeline graphs, grouped by category. Use get_node_type for a full port/config schema before wiring a node.

Full definition of one node type: input/output ports and the config field schema needed to author a node of this type. For a model-bearing node the live model catalog comes with it, and for video-gen each model carries what a second of video costs (usdPerSecond), so compare prices before choosing one.

Ready-made pipelines that create_pipeline can copy with templateId, so you do not have to draw a graph node by node. Each entry lists its entry nodes, the ids to key run_pipeline `inputs` by, and estimatedChargeUsd, what one run charges the balance as the template stands, to compare against get_credit_balance before you pick one. Clipping a long recording, file, or direct video URL into a captioned vertical clip is "video-clip-factory" (entry node "source", a File node that takes a URL); "podcast-clip-factory" pulls the newest episode from a podcast RSS feed; "campaign-clip" is for Vyro / Whop clipping briefs.

Create a new pipeline (as a draft) on your Treza account, from a template (templateId, see list_pipeline_templates) or with an initial node graph. Use list_node_types / get_node_type to learn the graph vocabulary: every edge names the two nodes it joins and a port on each, e.g. {"source":"music","sourceHandle":"audio","target":"sequence","targetHandle":"shots"}. A graph with error-level issues is refused with every issue listed, and nothing is saved. That includes a config key the node does not define, a value outside a field's options or range, and a model id, duration, aspect ratio or voice the chosen model does not offer: pick them from get_node_type. Drafts can be run with run_pipeline; publish_pipeline makes them invokable over the public API. To put music under a video the account already has, call assemble_video with musicPrompt instead of building a graph.

Update a pipeline: rename it, change its description, or replace its node graph. For a graph change, read the current one with get_pipeline includeGraph and send the whole graph back, nodes and edges together, every edge naming the two nodes it joins and a port on each, e.g. {"source":"music","sourceHandle":"audio","target":"sequence","targetHandle":"shots"}. A graph with error-level issues is refused with every issue listed, and nothing is saved; settings you change are checked against get_node_type and the live model catalog the same way create_pipeline checks them. To add music, narration or captions to a video a run already made, pass its url from get_run outputs to assemble_video or edit_asset instead: a changed pipeline renders every node again when it runs, the video included, and charges for it.

Publish a pipeline's current draft graph as an immutable deployed version. Publishing requires a fully valid graph (no errors or warnings) and makes the pipeline invokable via the public /invoke and /chat/completions APIs.

Pause or resume a published pipeline's schedule. Pausing flips the flag the cron runner checks without touching the published graph, so the deployed snapshot stays an honest record of what was published. Resuming re-anchors the schedule to now, so it waits for the next real slot instead of replaying slots missed while paused. Requires the pipelines:write scope. Schedules themselves are authored as a schedule-trigger node (see get_node_type) and armed by publish_pipeline.

The YouTube channels and TikTok accounts connected to this Treza account, with the ids a publishing node needs. A youtube-upload node needs a channelId and a tiktok-upload node needs an openId; both come from here. To connect one, call connect_channel and give the person its link.

Prepare a post of one finished video to a connected YouTube channel or TikTok account, for the person to review and confirm. It posts nothing itself: clients that show panels put the video, the account and the post's settings in front of the person, and it goes out only when they press Post there (TikTok requires them to choose who can view it and to confirm its disclosures themselves). Call it only when the person asked to publish. The video must come from list_assets or a finished run's outputs in get_run, copied exactly; write a real title (on TikTok it is the caption, hashtags allowed). channelId picks the channel or TikTok account from list_connected_channels when more than one is connected; with none connected, call connect_channel first. A client without panels cannot post from here: build a pipeline that ends in a youtube-upload or tiktok-upload node instead. Needs the pipelines:write scope.

A link the person opens to connect a YouTube channel or a TikTok account to their Treza account, so a pipeline can post there. Returns what is already connected on that platform and connectUrl. Only the person can finish it, in their own browser: give them the link, tell them the platform will ask their permission to post and that the page says when it is connected, and after they say so check list_connected_channels. The link asks them to sign in to Treza first with the Google account this connection uses, and it does not expire. When something is already connected, the link adds another, so only offer it when that is what they want.

Current prepaid credit balance, plan usage, and purchasable credit packs for this account. Use it to budget before starting runs. When the balance is low, hand the returned topUpUrl to a signed-in human; if the response carries an x402 block, a wallet-holding agent can pay that endpoint to top itself up with no human involved. That block also carries x402.video when this deployment sells single clips: one payment renders and returns one video without touching the balance, which is the cheaper path for a one-off.

Estimate what one run of a pipeline will charge the credit balance, which steps the money goes to (`lines`), and whether the current balance covers it. Estimates use the draft graph, the same one run_pipeline executes. When a video step would render the same clip for far less on Veo 3.1 Lite, `cheaper` names it with the run's price on it. When the balance covers neither, `preview` prices a first look it does cover: the first video step alone as a short Veo 3.1 Lite clip, which run_pipeline with preview: true renders. Call this before running a pipeline you built or changed in this conversation, tell the person the price (and the preview's, when there is one), and wait for their go-ahead before run_pipeline. Clients that show panels put the estimate in front of them with a Start render button, which sends that go-ahead as their message.