Skip to main content

SDK & API Keys

Xagent now exposes a separate /v1/* API surface for SDK and SaaS-style integrations.

/api/* vs /v1/*

Use /api/* when:
  • You are acting as an authenticated owner in the web app model
  • You manage agents, workforces, or knowledge with JWT-based auth
Use /v1/* when:
  • You want a stable programmatic integration surface
  • You are calling Xagent from your own backend or application
  • You want API-key-based access instead of browser session auth

Two key types

Personal keys

Personal keys identify a user. They are suitable for:
  • Developer tooling
  • Personal automation
  • Service-to-service access tied to a user identity

Agent runtime keys

Agent runtime keys are scoped to a specific agent and are designed for the /v1/* agent execution flow. They are managed by the agent owner and can be rotated independently of user JWT sessions.

Common SDK flow

The typical sequence is:
  1. Create or choose an agent
  2. Generate the agent runtime key
  3. Call POST /v1/chat/tasks
  4. Poll GET /v1/chat/tasks/{task_id}
  5. Fetch steps or append messages as needed

Dispatch class and priority

POST /v1/chat/tasks accepts two optional fields that tell the server how to schedule the task’s execution commands.
  • dispatch_class: interactive or batch. Omit it or send null to let the server decide.
  • priority: an integer from -10 to 10. Omit it or send null for 0. A value out of range, a boolean, a float, or a number sent as a string is rejected with 422.
Both fields apply only when the task is created. The append and reply requests do not have them, and any value sent there is ignored. With the default classification, every later execution command of the task inherits its priority, including appended messages, answers, and manual and automatic resumes. When the requested class is adopted, those commands take it too, except answers to a waiting task.

When the server uses them

  • The task must run through the dispatch queue (shared task execution, XAGENT_SHARED_TASK_EXECUTION_ENABLED). Otherwise the fields are stored but have no scheduling effect.
  • With the default classification, a requested class is adopted only when both XAGENT_DISPATCHER_FAIR_SHARE and XAGENT_DISPATCH_ACCEPT_REQUESTED_CLASS are on. Both are off by default. Otherwise the class follows the task source, which is batch for SDK tasks.
  • With the default classification, an answer to a waiting task is always interactive.
  • The class is decided when each command is enqueued, so changing these settings affects only commands enqueued afterwards.
  • Priority is applied when commands are dispatched. It has an effect only when fair share is on. It orders commands of the same account and the same class, also when that account is the only one with queued commands, and never lets one account jump ahead of another. Some dispatch rounds still pick the oldest command first.
  • A deployment can install its own classification rule, which may also set its own priority. In that case, trust the dispatch_class in the response.

Checking the result

The response includes dispatch_class, the class given to the task’s start command. It is null when the task does not run through the dispatch queue. Servers that predate the field omit it, which the Python SDK reports as None. The response does not report the priority.

When to document more

If your team is integrating Xagent into another product, you will usually want an internal guide that adds:
  • Request examples
  • Retry strategy
  • Error handling conventions
  • Key rotation policy
This page is the conceptual starting point; the exact schema lives in the API reference.