Webhook registration for push delivery - Academy

Coding agents already push progress into Dailybot through the agent reporting surface. Webhooks extend that model in the opposite direction: Dailybot notifies your systems when something meaningful happens, so integrations react in near real time without polling.

Push delivery versus polling

Polling means your service repeatedly asks “anything new?” on a timer. It is easy to reason about, but it adds latency (you only learn after the next poll), burns quota on empty responses, and still risks missing fast sequences if the interval is too long.

Push delivery flips the flow: Dailybot calls a URL you own when an event fires. Your code runs because something changed, not because a cron tick fired. For agent workflows—reports landed, inbox updated, health thresholds crossed—push is usually the better default when you operate a reachable HTTPS endpoint.

Registering a webhook endpoint

Registration is typically done in workspace settings where Dailybot exposes outbound integrations. You provide:

A HTTPS URL that your team controls (no self-signed certificates in production).
Optional metadata such as a label, environment tag, or which event families to subscribe to, depending on what the product UI offers.

After save, Dailybot associates that URL with your workspace and starts attempting delivery for subscribed event types. Treat the registration as configuration as code where possible: document the URL, owning service, and rotation procedure for secrets in the same place you store API keys.

Payload shape and what agents care about

Exact field names evolve with the product, but webhook bodies are usually JSON and include:

An event type or category so you can branch logic without inferring from partial payloads.
A timestamp or event identifier for ordering and deduplication.
Context tying the event to workspace, project, or agent identity—aligned with what you already send in agent reports and metadata.

Think of the webhook as a structured mirror of activity your agents already generated: a report submitted, a digest ready, or a downstream automation hook. Parsing should be defensive: unknown fields may appear as Dailybot adds capabilities; ignore what you do not need.

Authenticating and verifying webhook calls

Because your URL is on the public internet, any HTTP client could POST to it. Verification closes that gap.

Dailybot-style integrations commonly ship a shared secret or HMAC signature over the raw request body. Your handler should:

Read the raw body before JSON parsing for signature verification.
Compute the expected signature with the documented algorithm and secret.
Compare using a constant-time comparison to resist timing attacks.
Optionally enforce a timestamp skew window if signatures include time-bound claims.

Never log full secrets or unredacted signing material. Rotate secrets when team members leave or if you suspect exposure.

Retries, errors, and handler design

Webhook senders almost always retry on failure: network blips, deploys, and overload are normal. Expect at-least-once delivery: the same logical event may arrive more than once.

Respond with 2xx as soon as you have validated and persisted enough to finish processing later. Long database transactions or calls to third parties should run asynchronously after you acknowledge the HTTP request—otherwise Dailybot may time out and retry while your work is still running.

If you return 4xx for malformed payloads, the sender may not retry (your bug). If you return 5xx or time out, expect backoff retries. Implement idempotency keys from event IDs so duplicate deliveries do not create duplicate tickets, charges, or deployments.

Security and operational best practices

Use HTTPS only and keep TLS on your ingress current.
Authenticate every request cryptographically; do not rely on obscurity of the URL alone.
Scope the webhook secret per environment (staging versus production).
Rate-limit and monitor your endpoint for abuse unrelated to Dailybot.
Alert on elevated error rates so silent drift does not break agent-driven automation.

How this fits the broader agent reporting system

Agent reporting is the source of truth for what coding agents did: standup-style messages, structured JSON for milestones, health signals, and inbox pulls. Webhooks are the fan-out layer: they let CI systems, internal dashboards, or orchestrators react when that truth changes.

Together, the model is: agents push into Dailybot; Dailybot stores and surfaces visibility to humans; webhooks optionally notify other systems the moment new information exists—without replacing authenticated API calls for actions that must originate from your agent or service.

For field-level schemas and the latest event list, follow Dailybot’s official developer documentation alongside your workspace settings.

FAQ

Why use webhooks instead of polling for agent events?

Webhooks push events to your server as they happen, so you avoid constant GET loops, reduce latency, and only run logic when something changed. Polling is simpler to prototype but wastes requests and can miss tight windows between polls.

How should a webhook receiver verify Dailybot payloads?

Use the signing secret or HMAC mechanism the product documents: compute the expected signature from the raw body and compare it in constant time. Reject requests with bad signatures, stale timestamps if provided, and unexpected source IPs only as a secondary check—cryptographic verification is primary.

What HTTP response and idempotency practices matter for webhooks?

Return 2xx quickly after validating the request; do heavy work asynchronously. Treat duplicate delivery IDs or event IDs idempotently so retries do not double-apply side effects. On transient failures return 5xx sparingly and expect exponential backoff retries from the sender.