Use case
Send no-code workflow results to a dedicated inbox
Many visual automation tools can make an authenticated HTTP request. That common capability is enough to send a structured result while keeping the credential in the workflow platform's secret store.
Updated 5 min read
Map the same small HTTP contract
Choose POST and the notification endpoint
Use the HTTPS base URL for your account followed by /api/v1/notifications.
Add authentication as a secret header
Set Authorization to Bearer plus the source key using the platform's credential feature.
Map the result to JSON
Start with title and add source, severity, tags, metadata and deduplication only when the workflow has those values.
{
"title": "Research run completed",
"body": "The agent finished with 18 verified records and 2 rejected rows.",
"severity": "success",
"source": "research-agent",
"tags": [
"agent",
"daily-run"
],
"deduplicationKey": "research-run:2026-07-31",
"metadata": {
"accepted": "18",
"rejected": "2",
"runId": "run_2026_07_31"
},
"actions": [
{
"id": "open-run",
"type": "link",
"label": "Open run",
"href": "https://example.com/runs/run_2026_07_31",
"style": "primary"
}
]
}Make rejection and retry visible
- Treat a successful created or deduplicated response as delivered.
- Correct validation and authentication failures before retrying.
- Retry temporary failures with the same logical deduplication key.
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.