Real-time webhooks for PDF activity

What events can a webhook send?

A shared PDF generates moments you want to act on while they are still happening - a prospect opening the proposal, a lead completing the gate form, a one-time link burning itself. Each endpoint subscribes to exactly the events it cares about:

• Viewed. A reader opened the document. Fired per visit, carrying the file, the visit source, and the reader identity your plan reports - enough for a CRM to log who came back.
• Downloaded. A copy left the building. The event says which document, and which reader took it.
• Form completed. A reader passed the email gate or lead capture form. The payload carries the captured fields, ready to post straight into your CRM while the lead is still reading.
• Comment added. A reader left feedback on the document - private or public - so the right person can respond while the reader is still on the page.
• Receipt confirmed. A reader marked the document as received. Proof of delivery, pushed to wherever your audit trail lives.
• Link burned. A self-destructing link spent its view budget and deleted itself - the last event a link ever sends. Your readership record survives; the webhook tells you the moment the document went.

Verifying the signature

Every delivery includes a signature header in the same t/v1 style Stripe uses: a Unix timestamp and a hex digest, comma-separated. The digest is an HMAC-SHA256 of the timestamp, a dot, and the raw request body, keyed with the signing secret of the endpoint that received it.

To verify: read the timestamp and signature from the header, recompute HMAC-SHA256 over timestamp-dot-body with your secret, and compare your digest to v1 with a constant-time comparison. Reject anything whose timestamp is older than your tolerance - five minutes is typical - and forged or replayed deliveries never make it past the front door.

The signing secret is generated per endpoint and shown exactly once, at creation. Store it like a password; if it leaks or goes missing, rotate the endpoint and a new secret is minted.

Delivery, retries & housekeeping

A delivery is a POST to your HTTPS endpoint with a JSON body; any 2xx response counts as received. Anything else - a timeout, a 500, a dropped connection - is retried automatically with increasing backoff, so a deploy or a blip on your side costs you nothing. The event arrives when you are back.

An endpoint that fails every retry over a sustained run is disabled automatically, so it does not sit there absorbing events into the void - its status shows in Account settings and you can re-enable it once your side is fixed. Each account can register up to 10 endpoints, each with its own secret, its own event selection, and its own payload format.

Slack notifications in three steps

Slack support ships as a webhook format, not a Slack app - there is nothing from the app directory to install and nothing for a workspace admin to approve.

1. Create a Slack incoming webhook. In Slack, add an Incoming Webhook to the channel where you want notifications. Slack hands you a unique URL for that channel.
2. Paste the URL into FileDroppr. Add it as a webhook endpoint in Account settings, exactly as you would any other endpoint URL.
3. Pick the Slack format. Choose Slack as the payload format and select your events. From then on, a view on your proposal becomes a formatted Block Kit message in the channel, seconds later.

Prefer no code? Use Zapier

If you would rather not run a receiving endpoint at all, the Zapier integration connects FileDroppr to 7,000+ apps with no code. It polls on a schedule rather than pushing in real time, which is fine for most notification and logging flows.

Webhooks are the real-time, developer-grade end of the same spectrum: push delivery, signed payloads, and your own code deciding what happens next. Browse all FileDroppr integrations for everything in between.