Build every delivery concern
Persist events, schedule retries, handle duplicate sends, secure each request, and troubleshoot errors across services.
A PLAIN-ENGLISH INTRODUCTIONWhat is Hookstride?
What is Hookstride?
Why use it? How does it work?
Hookstride is the delivery layer between an event in your backend and the service that needs to know about it. Learn the moving parts before writing code.
Webhooks connect applications. Hookstride makes delivery reliable.
A webhook is an HTTP request one system sends to another when something happens. For example, a collaboration app can notify an automation service after a task changes, while a messaging app can notify a separate push-notification service after saving a message.
Without a delivery layer, the app must manage failures, timeouts, retry schedules, signatures, and delivery logs. Hookstride accepts your event, stores it, and delivers a signed HTTP POST to your chosen receiving URL. It tracks attempts and retries transient failures.
EVENT SOURCEYour backendTask updated
→DELIVERY INFRASTRUCTUREHookstrideQueue · Sign · Retry · Track
→DESTINATIONReceiver URLProcess the event
Hookstride is not a payment processor, event scheduler, email provider, or replacement for your application's business logic.
What if the destination is down?
Imagine a task-management application updates an assigned task. Its backend sends task.updated through Hookstride to an automation service, but the receiver returns 503 Service Unavailable. Without a delivery layer, the notification could be lost unless you build your own queue, retries, and monitoring.
Focus on the business event
Send one authenticated API request. Inspect delivery history; Hookstride retries supported transient failures and signs each delivery.
Delivery is at least once, not exactly once. Your receiver must safely handle the same event more than once, and an accepted event does not guarantee immediate downstream processing.
Hookstride works wherever applications need to react to events.
Chat notification triggers
After a messaging app saves a message, message.created can trigger a separate email or push notification backend. Hookstride does not send the message or push itself.
Confirmed bookings
booking.confirmed can notify scheduling, CRM or operations services when a reservation changes state.
Workflow updates
task.updated can inform another application's audit trail, integration or automation worker.
Business and device events
order.paid, verification.completed, and device.alert can reach their intended services using the same delivery API.
These are examples of custom event types your application defines and submits. Hookstride does not automatically detect payments, save chat messages, monitor devices, or execute business workflows for you.
A task update, step by step
- The collaboration app updates a task. Its backend commits task
T-104with its new status. - The app sends an event. It submits
task.updatedtoPOST /api/v1/events/, using its Hookstride project API key and the destination UUID of an automation service. - Hookstride accepts the event. It persists the event, checks the project's quota, and queues a delivery.
- Hookstride calls the destination. It sends signed JSON to the HTTPS URL the developer registered.
- The receiver checks and processes it. It verifies the signature and timestamp, prevents duplicate processing, safely records work, and returns HTTP 2xx.
- Hookstride records the result. Failed transient attempts are retried according to policy. The developer can inspect status and attempts, or replay a terminal event.
Choose Hookstride when your services need dependable event delivery.
Use Hookstride after a business action has been confirmed and another backend needs to respond. It makes delivery observable and recoverable even when the destination temporarily fails.
Keep dependent services informed
Forward booking.confirmed, task.updated or verification.completed to the service responsible for the next action.
Retry without rebuilding infrastructure
Hookstride queues events, signs requests, retries supported failures, and records delivery attempts for troubleshooting.
What you still own: your application decides when an event happens, and the receiving service verifies and processes it. Delivery is asynchronous and at least once; receivers must support duplicates.
You define the event and receiver. We handle transport.
| Task | Your application | Hookstride |
|---|---|---|
| Decide when a booking, message, or workflow event happened | Yes | No |
| Send the event using a project API key | Yes | Accept it |
| Provide an HTTPS receiving endpoint | Yes, or use an existing receiver | Store the destination URL |
| Sign, queue, and retry webhook delivery | No | Yes |
| Verify signatures and deduplicate at the receiver | Yes | Provide signed headers |
| Run application-specific business logic | Yes | No |
| Track delivery attempts and manual replay | Use dashboard/API | Yes |
A destination is not your homepage. A task application might implement https://api.tasks.example/webhooks/hookstride/. That illustrative receiving endpoint must be created by the application owner; Hookstride does not create it automatically.
Integrating payments or identity providers? Keep the keys separate.
Provider integrations are optional; you can send booking, messaging, logistics, or SaaS events without connecting Stripe, Paystack, PayPal, or Didit. API credentials let your application call a provider. Webhook signing credentials let a receiver verify an incoming notification. Hookstride project keys let your backend send events to Hookstride. These are different credentials and are not interchangeable.
| Credential | Where to store or configure it |
|---|---|
Stripe publishable key pk_... | Your checkout frontend, if using Stripe client-side SDKs |
Stripe secret API key sk_... | Your application's server environment or secret manager, never Hookstride's outgoing API |
Stripe webhook signing secret whsec_... | Hookstride Connections → Incoming sources → Stripe → Signing secret, only when the inbound gateway is enabled; otherwise your own Stripe webhook receiver |
Paystack public key pk_... | Your application's checkout frontend |
Paystack secret key sk_... | Your application's server. Paystack also uses this full-access API key to sign webhooks, so Hookstride's optional Paystack source would need it to verify events. Treat that as a high-trust integration. |
| PayPal client ID and client secret | Your application's PayPal integration; Hookstride does not currently implement native PayPal webhook verification |
| Didit API key and webhook signing secret | Keep the API key in your own backend; use the separate signing secret in a compatible verified receiver. Hookstride does not currently implement native Didit webhook verification |
| Hookstride project API key | Your sending backend environment; create in Dashboard → API keys |
| Hookstride destination signing secret | Your receiving backend environment; supplied once when creating a destination in Hookstride |
Two different paths: For the standard outgoing API, your provider keys remain in your application. If the optional inbound gateway is enabled, create an incoming source in Hookstride, copy its generated URL into the provider's webhook settings, and enter the provider's correct webhook verification credential in Hookstride. The gateway currently supports Stripe, Paystack, GitHub and custom HMAC sources—not PayPal or Didit. Do not enable it in production without completing its security and network-egress review.
See the credential table, source setup and environment-variable examples →
From dashboard to your first delivery
- Build or choose a receiver. Create an HTTP POST route in Django, FastAPI, Express, Laravel, or use a supported external webhook listener. Respond with 2xx only when the event is safely accepted.
- Register its public URL. Open the Hookstride dashboard, add a destination, and save its one-time signing secret for signature verification.
- Generate a project API key. Store it in your backend's environment, not browser JavaScript, mobile apps, or source control.
- Send an event from your backend. Call
POST /api/v1/events/with the destination UUID, event type, payload, and a stableIdempotency-Key. - Test a failure. Inspect the delivery status and attempts, then confirm retries and deduplication at your receiver.
Questions developers ask first
Can Hookstride deliver notification events from a chat app?
Yes. After the chat server stores a message, it can send message.created to Hookstride to notify a separate notifications backend. The receiving notification backend decides how to contact the user. Hookstride delivers the event; it does not send SMS, email, or push notifications directly.
Do I need to build an entire webhook system?
No. You implement your business event and a receiver (or use a receiver that already exists). Hookstride provides the queueing, signed delivery, retries, logging, and replay infrastructure.
Can I put my website's homepage as the destination?
Usually not. The destination needs to accept POST requests, verify Hookstride's signature, record and process events, and respond with 2xx. A normal homepage typically does none of those.
Do recipients need a Hookstride account?
No. Only the sending project needs Hookstride credentials. A receiving service only needs the signed request format and the destination's signing secret.
Can I start without creating a receiver?
Yes. Register a temporary webhook testing service URL and send a sample event. Replace it with your production HTTPS endpoint before handling real events; never send sensitive user data to public testing URLs.
Can I send one event to multiple destinations?
The standard outgoing API targets one destination UUID per event. Create an event for each destination you want to notify. An optional inbound gateway supports routing a verified upstream webhook to one or more destinations, but that gateway is disabled by default.
Should I paste my Stripe or Paystack secret API key into Hookstride?
Not to send your own events. Your checkout API credentials belong on your backend. The optional Stripe incoming connection needs its endpoint signing secret—not its API key. Paystack is different: its webhook HMAC uses the full-access Paystack secret API key, so only configure that connection after reviewing the security implications.
Does Hookstride receive external provider webhooks too?
Yes, where the optional inbound gateway is enabled. Configure an incoming source, the provider's signing secret, and a route to an active destination. The core events API remains available without incoming connections. The gateway supports Stripe, Paystack, GitHub, and custom HMAC senders; other providers need their own verified receiver or adapter.
READY TO BUILD
Read the integration guide →