Destinations
A destination is a configured target that can receive a submitted session. Xenocept stores destinations in /config/destinations.json and exposes them through the HTTP API.
Shape
Each destination is a JSON record with the following shape:
{
"id": "01HF...", // identifier, generated on create
"name": "Send to Claude", // human-readable label
"pluginID": "org.aeor.xenocept.claude",
"pluginConfig": { /* arbitrary JSON the plugin understands */ },
"enabled": true
}
Notes on the shape:
- The JSON keys are
pluginIDandpluginConfig— camelCase, capitalID(those are serde rename targets, see ). - There is no
typefield and no top-leveltargetswrapper. The file holds a JSON array of destination records. pluginConfigis whatever the named plugin understands. Xenocept itself doesn’t parse it; it hands the value through to the plugin at dispatch time.
HTTP Endpoints
| Method + Path | Purpose |
|---|---|
GET /api/v1/destinations | List destinations |
POST /api/v1/destinations | Create a destination |
PUT /api/v1/destinations/{id} | Update a destination |
DELETE /api/v1/destinations/{id} | Delete a destination |
POST /api/v1/destinations/{id}/send | Dispatch a specific session to this destination |
Auto-Send
A second config file, /config/auto-send-destinations.json, holds the user’s auto-send preference — which destinations a freshly-submitted session should automatically be sent to.
Shape:
{
"destinationIDs": ["01HF...", "01HG..."],
"enabled": true
}
The enabled flag is a master switch. When false, auto-dispatch is paused even if destinationIDs is non-empty — useful when the user wants to keep their destination selection but stop firing it for a while.
The dispatch logic itself lives in the frontend’s plugin loader and post-Submit dispatch call (/api/v1/sessions/{id}/dispatch, ). The frontend invokes each enabled destination’s plugin via the relevant /api/v1/deliver/* proxy.
Per-Destination Status
session.jsoncarries adispatched_attimestamp once at least one destination has been dispatched to.- Plugin-emitted toasts in the overlay UI surface per-destination success/failure during dispatch.
There is no persisted per-destination/per-session result table today.
Editing By Hand
# List
curl http://127.0.0.1:9500/api/v1/destinations
# Create
curl -X POST http://127.0.0.1:9500/api/v1/destinations \
-H 'Content-Type: application/json' \
-d '{
"name": "My destination",
"pluginID": "com.example.my-plugin",
"pluginConfig": { "endpoint": "https://example.com/intake" },
"enabled": true
}'
POST /api/v1/destinations returns the assigned id. Use it for subsequent PUT/DELETE/send calls.