Guide
Send your first notification with curl
The shortest working path is an API key and a POST request. This guide starts with a complete event so the same example also demonstrates tags, metadata, deduplication and an explicit link action.
Updated 5 min read
Keep the source key outside the command
Create a source
Open the inbox onboarding flow, name the producer and create a revocable key for that source.
Store the key
Put the once-visible value in your shell or deployment secret store as NOTIFICATIONS_API_KEY.
POST the event
curl --fail-with-body \
--request POST \
--url "$NOTIFICATIONS_URL/api/v1/notifications" \
--header "Authorization: Bearer $NOTIFICATIONS_API_KEY" \
--header "Content-Type: application/json" \
--data '{"title":"Backup completed","body":"Nightly PostgreSQL backup finished and passed restore verification.","severity":"success","source":"backup-worker","tags":["backup","production"],"deduplicationKey":"backup:2026-07-31","metadata":{"duration":"42s","size":"1.8 GB"},"actions":[{"id":"open-backup","type":"link","label":"Open backup","href":"https://example.com/backups/2026-07-31","style":"primary"}]}'A successful request returns the notification identifier and whether a new record was created. Reusing the same deduplication key returns the existing record instead of creating another inbox item.
Frequently asked questions
- Does the producer need a special integration?
- No. The examples use an authenticated HTTPS request, so any script, service or visual workflow that can send HTTP can use the same contract.
- Should credentials be included in notification data?
- No. Keep credentials in the producer's secret store and send only the context needed to understand or locate the event.
Keep exploring
Put the pattern to work
Existing accounts can open the inbox and send their next event.