Quickstart
Set up outcome-based billing for your AI agent and send your first event in under 2 minutes.
Prerequisites
- An API token (get one here)
- A task (
task_key) created in the dashboard - A customer (
customer_key) created in the dashboard with a rate card that includes the task
Set your token as an environment variable so the examples below work as-is:
export WITN_API_KEY=your_token_hereThe scenario
A customer support outcome: a ticket is billable after the agent replies, as long as the ticket is not escalated, reopened, or followed by a low CSAT score. If the customer abandons the conversation after the agent reply, no bad signal has arrived, so the outcome can confirm after the settlement period.
Step 1. Open the outcome
Create the outcome. This binds it to a task (which contract to snapshot) and a customer (who to bill).
curl -X POST https://api.thewitn.com/v1/outcomes \
-H "Authorization: Bearer $WITN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"key": "support:ticket:1001",
"task_key": "support",
"customer_key": "acme"
}'Returns 202 Accepted. key is your own identifier for this outcome. It must be globally unique and 8 to 255 characters. A repeated create for the same key is ignored.
Step 2. Send signals
Send events against the outcome by outcome_key. Events for an outcome that does not exist are discarded, so open it first.
# Agent replies: the condition becomes provisionally satisfied
curl -X POST https://api.thewitn.com/v1/events \
-H "Authorization: Bearer $WITN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"outcome_key": "support:ticket:1001",
"action": "agent_replied"
}'
# Optional bad signal: same outcome, can flip it to FAILED
curl -X POST https://api.thewitn.com/v1/events \
-H "Authorization: Bearer $WITN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"outcome_key": "support:ticket:1001",
"action": "reopened"
}'Both calls return 202 Accepted. Events are processed asynchronously. After agent_replied, the outcome stays OPEN with its condition provisionally satisfied. If a later reopened, escalated, or low csat event arrives before settlement, it moves to FAILED; otherwise it moves to CONFIRMED when the settlement timer expires.