Skip to main content
This guide has two tracks. Track 1 calls a real endpoint you can use today if you have published a custom agent. Track 2 previews the shape of the fabric’s execute() API, which is contract-stable but not yet serving traffic.

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 an aura_agent_* deployment 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: Developer preview — the Fabric v1 API described here is contract-stable but not yet serving traffic. Contact us to join the first partner cohort.
This is what calling the fabric directly will look like once the preview opens. The request and event shapes below come from the published design. There is no SDK yet, so the examples use plain HTTP and SSE.

Start a run

mode: "turn" vs. mode: "task"

The example above uses delivery: { mode: "turn" }: a synchronous call that streams events back on the same connection and ends when the run does. For longer or open-ended work, use delivery: { mode: "task" } instead. The call returns a run id right away, 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.
  • POST /v1/webhooks: register an endpoint so Praxa pushes events to you instead of you polling.

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:
decision’s values mirror Praxa’s internal approval-status enum (approved/denied); the public contract will confirm them at launch. The run resumes from exactly the step it paused on. See Concepts for the fail-closed rules that govern this.

After the run

Every finished run has a receipt: what ran, which policy version applied, who approved what, and how the result checked against your acceptance criteria. Usage and spend for your tenant are available at GET /v1/usage.

What’s next

  • Read Concepts for the full vocabulary.
  • Read Overview for the product framing.
  • Want into the preview cohort? Contact us.