This guide has two tracks. Track 1 calls a published custom agent. Track 2
starts a durable run through the production Execution Fabric partner preview.
Track 1: Call a published agent today
Status: Available today.
If you have published an agent on Praxa’s custom-agent platform, you already have a deployment-scoped custom-agent key. Use it to run that agent from your own backend.
Request
Notes
externalSessionId is yours to assign. Pass the same value for the same end user on every call and Praxa keeps that conversation isolated and continuous across calls. Use a distinct value per end user.
- The key authenticates one specific agent deployment. Keep it on your backend. Never ship it to a browser or a mobile client.
- If the agent tries to take an action that sends, schedules, changes, or purchases something through a connector, that action still requires approval under the same server-side rules as the in-app experience. A read-only question-and-answer agent will not hit this path.
- These fields cover text execution. If your agent also uses knowledge ingestion, memory, or automations, those are separate endpoints in the custom-agent API.
Track 2: Your first execute() run
Status: Production partner preview. Admitted accounts can create a
personal key in the current signed-in console. The portal’s email-link/OTP
fragment callback, persisted browser session, durable legal gate, and canonical
routing are deployed. The deep link remains pending its authenticated
production-host canary.
The live preview accepts the minimal durable-task envelope. It returns
400 invalid_request for mode: "turn" and request-level agent, tool, policy,
context, and delivery overrides. /v1/chat is not routed.
Start a run
Follow the durable task
The public request uses mode: "task". The call returns a run id immediately,
and you follow progress with:
GET /v1/runs/:id: current state.
GET /v1/runs/:id/events: the same event stream, resumable with a Last-Event-ID header.
- a signed-in portal or bearer webhook configuration when you want Praxa to
push signed events instead of polling.
mode: "turn" is not part of this route’s public schema and returns
400 invalid_request. /v1/chat is not routed.
Resolving an approval
If a step needs sign-off, the event feed emits approval.required with a summary and an action_digest. Post the digest back with your decision:
The public contract uses approve or deny. Exact browser-action approval
refinements are source-ready and pending activation. Once active, Praxa accepts
the decision only when the
digest still matches the exact pending instruction or steps and target host.
Missing, stale, mismatched, cross-tenant, or unsupported approval shapes remain
fail-closed. See Concepts.
After the run
Read tenant-scoped metering with GET /v1/usage. The public run projection is
deliberately narrower than Praxa’s internal receipt: it exposes verified text
only when the stored result, action digest, and verification verdict agree.
What’s next
- Read Concepts for the full vocabulary.
- Read Overview for the product framing.
- Want into the preview cohort? Contact us.
Last modified on August 14, 2026