Webhook and event reference

Webhooks let you push Dailybot events to your own systems in real time. Instead of polling the API, register a URL and Dailybot sends an HTTP POST with a structured payload every time a relevant event fires. This reference covers every event type, the payload format, authentication, retry behavior, and practical integration examples.

Registering a webhook endpoint

From the Dailybot dashboard, go to Settings and then Webhooks. Click “Add endpoint” and provide:

• URL — The HTTPS endpoint that will receive POST requests. HTTP is not accepted in production.
• Events — Select which event types this endpoint should receive. You can subscribe to all events or pick specific ones.
• Secret — Dailybot generates a signing secret for the endpoint. Store it securely — you will use it to verify incoming deliveries.

Once saved, the endpoint is active immediately. You can test it by triggering a sample event from the webhook settings page.

Event types

check_in.completed

Fires when a team member finishes answering a check-in.

Key payload fields: check_in_id, user_id, user_name, team_id, responses (array of question/answer pairs), completed_at (ISO 8601 timestamp).

agent_report.received

Fires when a coding agent submits a progress report.

Key payload fields: agent_id, agent_type (e.g., “cursor”, “claude-code”), workspace_id, report_body, metadata (model, branch, repo), received_at.

blocker.detected

Fires when a check-in response matches blocker detection rules.

Key payload fields: check_in_id, user_id, user_name, matched_keywords (array), original_response, follow_up_responses (if conditional follow-ups are configured), detected_at.

mood.threshold_crossed

Fires when a team or individual mood score crosses a configured threshold.

Key payload fields: team_id, user_id (null for team-level), current_score, threshold, direction (“above” or “below”), period, crossed_at.

workflow.triggered

Fires when a custom workflow rule is activated.

Key payload fields: workflow_id, workflow_name, trigger_type, trigger_data, actions_executed (array), triggered_at.

kudos.sent

Fires when a team member sends kudos to a colleague.

Key payload fields: sender_id, sender_name, recipient_id, recipient_name, message, value (if team values are configured), sent_at.

form.submitted

Fires when a form submission is completed.

Key payload fields: form_id, form_name, submitter_id, submitter_name, responses (array of field/value pairs), submitted_at.

Payload structure

Every webhook delivery follows a consistent envelope:

{
  "event": "check_in.completed",
  "version": "1",
  "timestamp": "2026-03-20T14:30:00Z",
  "delivery_id": "d_abc123",
  "data": {
    // Event-specific fields
  }
}

The version field indicates the payload schema version. When breaking changes are introduced, the version increments and you can migrate at your own pace.

The delivery_id is unique per delivery attempt, including retries. Use it for idempotency — if your endpoint receives the same delivery_id twice, skip the duplicate.

Authentication and verification

Every delivery includes two headers for verification:

• X-Dailybot-Signature — HMAC-SHA256 hex digest of the raw request body, computed using your endpoint’s signing secret.
• X-Dailybot-Timestamp — Unix timestamp of when the delivery was sent. Use this to reject stale deliveries (e.g., older than 5 minutes) and prevent replay attacks.

To verify a delivery:

1. Read the raw request body (do not parse JSON first).
2. Compute HMAC-SHA256 of {timestamp}.{body} using your signing secret.
3. Compare the computed signature against the X-Dailybot-Signature header using a constant-time comparison.
4. Reject if the timestamp is older than your tolerance window.

Retry policy

If your endpoint returns a non-2xx status code or times out (30 second limit), Dailybot retries with exponential backoff:

Attempt	Delay
1st retry	30 seconds
2nd retry	2 minutes
3rd retry	10 minutes
4th retry	1 hour
5th retry	6 hours

After 5 failed retries, the delivery is marked as failed. You can view delivery history and replay failed deliveries from the webhook settings page.

If an endpoint accumulates too many consecutive failures, Dailybot automatically disables it and sends a notification to the workspace admin. Re-enable it from the dashboard after fixing the issue.

Example integrations

Posting blocker alerts to Slack

Subscribe to blocker.detected events. When the webhook fires, extract user_name, original_response, and matched_keywords from the payload. Format a Slack message and POST it to your #blockers channel using the Slack Incoming Webhooks API.

Triggering CI/CD pipelines

Subscribe to agent_report.received events. When an agent reports that a feature branch is ready for review, parse the metadata.branch field and trigger your CI pipeline via the GitHub Actions or GitLab API.

Updating project management tools

Subscribe to check_in.completed events. Parse responses for task mentions or status keywords, and update corresponding cards in Jira, Linear, or Asana using their APIs. This keeps project boards in sync with what people actually report in their standups.

Mood-triggered manager alerts

Subscribe to mood.threshold_crossed events. When a team’s mood drops below a configured score, send an email or Slack DM to the team manager with the trend data so they can check in with the team proactively.

Best practices

Start narrow. Subscribe to one or two event types and build from there. Subscribing to everything creates noise before you have handlers for it.

Use idempotency. Your endpoint may receive the same delivery more than once due to retries or network issues. Check the delivery_id before processing.

Respond quickly. Return a 200 status code as soon as you receive the payload. Do heavy processing asynchronously. If your endpoint takes too long, Dailybot will retry and you may process duplicates.

Monitor delivery health. Check the webhook logs in Dailybot periodically. A spike in failures usually means your endpoint is down or returning errors — catch it before escalation disables the endpoint.