Everything Xperimeter does in the app it does over HTTP. Send it a sentence; get back what it understood, what it did, and what it will keep watching.
Create a key in account settings. It's scoped to one household and revocable at any time.
POST a sentence. No schema to learn, no endpoint per capability.
Responses carry the agent's reply plus a structured log of every action it took.
Register a webhook and it reaches you the moment something on watch changes.
curl https://api.xperimeter.com/v1/conversations \
-H "Authorization: Bearer $XPERIMETER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"message": "Tell me if the back gate is left open after dark."
}'{
"id": "conv_7fa21c",
"reply": "I'll watch the back gate from sunset to
sunrise and message you if it's open
more than two minutes.",
"actions": [
{
"type": "watch.created",
"id": "wat_39b0",
"subject": "back gate",
"window": "sunset-sunrise"
}
]
}/v1/conversationsOpen a conversation with the agent, or continue one by passing its id.
/v1/conversations/:idFetch a conversation with its full message and action history.
/v1/watchesList everything the agent is currently keeping an eye on.
/v1/watches/:idStand down a watch. It stops immediately and says so in the log.
/v1/eventsPage through observations and alerts, newest first.
/v1/webhooksRegister a URL to receive events as they happen, signed with your key.
No. Every capability is reachable through one conversational endpoint — the agent decides which tools to use. The structured endpoints exist for listing and teardown, not for driving it.
A key belongs to one household and inherits the boundaries you've already set in plain language. A key can't reach a sensor you've muted, or a room you've told the agent to leave alone.
Yes. Pass Accept: text/event-stream and the reply arrives token by token, with actions emitted as they're taken rather than at the end.
60 requests per minute per key, and 10 concurrent streams. Webhook deliveries retry with backoff for 24 hours before they're dropped.