Skip to main content
POST
Send a message to ClaudIA and read its answer

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Body

application/json

One customer turn to send to ClaudIA. Everything else about the run — which knowledge base, which prompts, which tools, which model — comes from the project's own configuration, so a reply here is the reply a real customer would have received.

project
string
required

Project to talk to, e.g. acme_support, as listed by listMyClaudiaProjects. Project names are unique across all customers, so this alone identifies the environment — you never supply an account, an instance or a tenant. A project these credentials cannot reach answers 404, indistinguishable from one that does not exist.

Example:

"acme_support"

message
string
required

What the customer says this turn, verbatim and in the customer's own language. Write it the way a real person would open a ticket — the reply is only as representative as the message that provoked it. One turn per call: to continue a conversation, send the next message with the conversationId you got back.

Example:

"meu pedido 12345 ainda não chegou, o que houve?"

abKey
string | null

Run this turn through an A/B variant of the project's configuration instead of the live one, by its key. The variant replaces the settings it declares for this run only, and the key travels to the trace so the run is comparable afterwards. Get the keys from listProjectAbKeys; a key the project does not declare is refused. Omit to run the live configuration.

Example:

"classification"

conversationId
string | null

Continue an existing playground conversation instead of starting a new one. Pass the conversationId from a previous response and ClaudIA sees everything already said in it. Omit it to start fresh. A conversation that belongs to another project, or that is a real customer conversation rather than a playground one, answers 404.

Example:

"6c7b1f2e-3a4d-4f5b-8c9d-0e1f2a3b4c5d"

helpdeskId
string | null

Ticket ClaudIA should behave as if it were answering, by its id in the helpdesk. Use it to reproduce what happened on a specific real ticket: the run reads that conversation's context, so tools and prompts that depend on it behave as they did there. Omit it — the normal case — and the run carries no ticket context at all.

Example:

"84213"

Response

The turn finished and this is what ClaudIA answered.

The finished turn: what the customer would have received, and where the ticket would have gone. Returned only once ClaudIA is done — a run takes as long as the pipeline takes to classify, search, answer and decide.

conversationId
string
required

The playground conversation this turn belongs to. Send it back as conversationId on the next call to keep talking with the same history. The same conversation is mirrored into your CloudChat playground inbox under this id.

Example:

"6c7b1f2e-3a4d-4f5b-8c9d-0e1f2a3b4c5d"

reply
string
required

The reply the customer would have received, whole. A project that splits long answers sends it as several messages, and they are joined here with a line break — read messages to see how it was actually delivered. Empty only when the turn produced no public message, which is what happens on a silent hand-off.

Example:

"Seu pedido 12345 saiu para entrega ontem e chega até amanhã."

outcome
enum<string>
required

What ClaudIA decided to do with the ticket. answered kept it; forwarded_to_human handed it to a human queue, and internalNote then carries the note the human reads; resolved closed it.

Available options:
answered,
forwarded_to_human,
resolved
Example:

"answered"

usedSources
string[]
required

Names of the knowledge base entries the answer was built from, in the order they were used. Empty when the reply came from a prompt rather than from content — which is itself the finding when you expected content to be used.

messages
object[]
required

Every message this turn produced, in order, including the internal notes. A turn can produce more than one message when the project splits long replies or writes a note before handing off.

abKeyUsed
string | null

The A/B variant this run actually used, or null for the live configuration.

Example:

"classification"

tag
string | null

Tag applied to the ticket this turn, if any. This is what a routing rule in CloudChat would key on, so it says more about where the ticket ends up than the reply does.

Example:

"n2_unansweredbyclaudia"

internalNote
string | null

The internal note written for the human taking over, when this turn handed the ticket off. Null otherwise. Customers never see it.

Example:

"Cliente pergunta sobre atraso do pedido 12345; base não cobre prazo para a região."