Stage 3 — Give it AI
Fill in the summarise endpoint so an incident's free text comes back as a short factual summary, routed through the Dibbla AI gateway with your token as the model key.
Each incident carries a free-text body. This stage wires up
POST /api/incidents/:id/summarise so that body comes back as a short, factual
summary — through the Dibbla AI gateway, where your Dibbla token is the model
key. Nobody on your team ever holds a provider key, and every call is
attributed to your organisation. (The gateway tour covers
the mechanics in full.)
Wire the summarise endpoint to the Dibbla AI gateway.
In this Lumen project, implement the POST /api/incidents/:id/summarise handler.
Parse the id, load the incident with getIncident, then call the summariseBody
helper the template already ships in ai.go — pass the incident body, the
DIBBLA_API_TOKEN env var, and the request hostname — and return {"summary": ...}.
The app needs my Dibbla API token as the secret DIBBLA_API_TOKEN on the "lumen"
deployment: do not ask me to paste it to you — ask Dibbla for a link where I
enter it, and wait until I have. Then redeploy with --update, POST to
/api/incidents/1/summarise and show me the summary.What happens next
Hand that prompt to your coding assistant and it does the wiring for you. It fills in the one route that was left blank — the one that takes an incident and asks an AI model to summarise it — and points that request at Dibbla’s AI gateway. The gateway is a shared doorway to AI models: instead of every app carrying its own secret model password, the app sends your Dibbla token, and the gateway swaps in the real key on the other side. So there is nothing sensitive to copy around, and every summary your app produces is counted against your own organisation.
To make that work the app needs one piece of configuration — your token — and then a fresh version of the app so the code and the token go live together. Where the gateway lives, and which app is calling, Dibbla tells the app by itself. A token is the kind of value you never want in a chat log, so the assistant does not ask you for it: it hands you a link to a Dibbla page, you paste a token you minted in the portal under API keys, and the assistant only learns that you are done.
When it finishes, you ask the app to summarise a single incident and it hands back a few sentences of plain English: what happened, the likely cause, and how it was resolved. That is a real AI summary of that specific incident, not a canned line — so the thing worth checking is that it actually describes that incident and not some other one.
Because there is a live model behind it, the exact wording changes from run to run. That is expected. Two summaries of the same incident will read differently while still telling the same story.
Under the hood the CLI & code behind this step — optional
1. Fill in the handler
The template ships the hard part in ai.go: summariseBody does a POST to
DIBBLA_AI_GATEWAY_URL + "/anthropic/v1/messages" with your Dibbla token as the
x-api-key header. What is left is the route handler — load the incident and
call it:
func handleSummarise(c *fiber.Ctx) error {
id, err := strconv.Atoi(c.Params("id"))
if err != nil {
return c.Status(400).JSON(fiber.Map{"error": "bad id"})
}
inc, err := getIncident(c.Context(), id)
if err != nil {
return c.Status(404).JSON(fiber.Map{"error": "not found"})
}
summary, err := summariseBody(inc.Body, os.Getenv("DIBBLA_API_TOKEN"), c.Hostname())
if err != nil {
return c.Status(502).JSON(fiber.Map{"error": err.Error()})
}
return c.JSON(fiber.Map{"summary": summary})
}summariseBody reads DIBBLA_AI_GATEWAY_URL for the endpoint and takes the
token as its second argument. It sends DIBBLA_ALIAS as the X-Dibbla-App
header, so the call is attributed to this app; the hostname is only a fallback
for running it outside Dibbla.
2. Set the token
Every deployed app — a single Dockerfile like Lumen as much as a dibbla.yaml
manifest — receives DIBBLA_AI_GATEWAY_URL and DIBBLA_ALIAS from the
platform. What no deploy ever receives is a token: handing every container a
credential for the whole organisation would not be safe. So that is the one
value you set.
Set DIBBLA_API_TOKEN as a secret, never with -e. Mint it in the
portal under API keys and paste it at the CLI’s hidden prompt, or on the page
secrets request links to. Do not set DIBBLA_AI_GATEWAY_URL or
DIBBLA_ALIAS yourself — the injected values win.
# paste the token you minted in the portal when asked — the input is hidden $dibbla secrets set DIBBLA_API_TOKEN --deployment lumen # or, what an assistant runs: a link where you paste it on a Dibbla page $dibbla secrets request DIBBLA_API_TOKEN --deployment lumen --title "Dibbla API token"
Then redeploy so the handler and the token ship together:
$dibbla deploy --update -m "feat: stage 3 — AI summarise via gateway" deploy ok · https://lumen-0ee1f995.dibbla.app · 38.4s
3. Check it
Post to the endpoint for a single incident and read the summary back:
$curl -X POST https://lumen-0ee1f995.dibbla.app/api/incidents/1/summarise {"summary":"A load-balancer health check began flapping, briefly cycling healthy backends out of rotation. The likely cause was short GC pauses tripping the timeout; raising the health-check threshold mitigated it."}
The test is not that the string is non-empty — it is that the summary is about the right incident. Here it names the impact (backends cycled out of rotation), a likely cause (short GC pauses tripping the timeout) and the mitigation. A summary that reads well but describes some other incident is a failure, so read it against the incident body.
The call then appears in the console’s AI usage ledger, attributed to
lumen. The header has to be DIBBLA_ALIAS — the full deployment name in the
app’s address (lumen-0ee1f995), not the shorter name you deployed with. A call
that sends lumen still works, but is recorded as coming from outside instead of
from the app.
There is a short propagation delay before a call shows up in the AI usage ledger — expect a few seconds, not real time. If the row is not there the instant the request returns, wait and refresh before assuming it was missed.
Next: the app is real — now automate it
Lumen deploys, stores incidents, and summarises them on demand. The remaining stages turn one-off actions into standing behaviour: a workflow that runs a graph of steps, and a pipeline that runs on a schedule.