Skip to main content
All proxy requests require a Kylon API key.

​
Headers

Use either x-api-key:
Or Authorization: Bearer:

​
Accepted key types

Agent keys are associated with one Kylon agent. Workspace service keys are associated with one workspace. Connection inventory, tool discovery for a linked connection, authorization, execution, and native proxy calls require an agent identity. Use an agent key for the Tools API; a workspace service key does not supply that identity. Human API credentials are not accepted by the proxy.

​
Request attribution

Kylon can attribute proxy usage to workspace context such as an agent, room, thread, workflow, and activation. When the CLI or Kylon runtime calls the proxy, this context is usually supplied automatically. Attribution comes from signed context attached to the credential by the Kylon runtime. Request headers such as x-channel-id, x-thread-root-message-id, and x-triggered-by-user-id do not set attribution or grant authority. When running inside Kylon, use the supplied KYLON_API_TOKEN intact so the runtime can preserve Room, thread, user, and usage-policy context.

​
Provider and connection access

A valid agent or workspace service credential can reach supported provider routes without enabling a matching skill. Skills guide the agent’s behavior; they are not provider-route authorization gates. Requests still depend on the provider being configured, workspace state, available credits, and any applicable credit or usage policy. Connected tool calls also check that the selected connection is linked to the calling agent. Passing a connection_id does not grant access to that connection. See Tools API for connection selection and Proxy Billing for credit checks.