Read on our website
Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had a great week.
I want your thoughts on this
I plan on adding more visuals/diagrams in the future because I think visuals are very helpful.
I have 2 designs and wanted to know which one you prefer:
Option 1
Option 2
🦥 No sponsor this week, just vibes.
But if you want to reach 50,000+ developers, founders, and tech lovers who actually open their emails — this is the place.
🦥 What the Heck is a Webhook?
Webhooks are actually one of those concepts that sound way more complicated than they are. Once you "get it," you'll start seeing use cases for them everywhere.
So what is it?
A webhook is an HTTP callback: one service sends an HTTP request to an endpoint you provide when some event happens. POST with JSON is common, but the exact method, payload, headers, authentication, and retry behavior are defined by the provider.
Think of it like giving a service your mailbox address. When an event you subscribed to happens, it delivers an event payload instead of making you repeatedly ask for updates.
Easy to understand analogy
Everyone has experienced or heard of this situation.
“Are we there yet? Are we there yet? Are we there yet?”
Your parents wanted to throw you out the window. You're wasting everyone's energy asking the same question every 30 seconds when nothing has changed.
Repeatedly asking another service whether something changed is polling. Polling is not inherently bad—it can be simpler and more reliable for some APIs—but it spends requests checking even when nothing changed.
Webhooks: “Give me an endpoint and I’ll send you an event when something changes.”
That can reduce unnecessary polling and make event-driven integrations react quickly, but it introduces a different set of problems: authentication, retries, duplicate delivery, ordering, downtime, and endpoint security.
That's what webhooks do.
Instead of your app constantly asking another service "got any updates for me?" the service tells YOU when something actually happens.
Real examples
Stripe: your server can receive events about payment, invoice, subscription, dispute, and other state changes. Do not assume “instantly” or exactly once—design for retries and duplicates.
GitHub: a repository can send webhook deliveries when selected events occur, such as pushes, pull requests, or issues.
Slack: incoming webhooks are primarily a way for your app to post messages into Slack. If you want Slack events such as mentions delivered to your app, that is handled through Slack’s Events API/event subscriptions—not the incoming-webhook feature.
Discord: webhook URLs are commonly used to post messages into Discord channels. Receiving Discord activity in an application uses Discord’s event/gateway mechanisms rather than treating an incoming webhook URL as a generic “new message callback.”
How Webhooks Work
You create an HTTPS endpoint that can receive the provider’s webhook request.
You register the endpoint and choose which events you care about.
An event occurs in the provider’s system.
The provider sends a delivery containing an event ID/type, payload, and authentication/signature metadata.
Your endpoint verifies the request, records/deduplicates the event, and returns an appropriate success status quickly.
Slow or expensive work is often handed to a queue/background worker after acknowledgement rather than keeping the provider’s request open.
The HTTP request is the easy part. Production webhook handling is mostly about making that request trustworthy, retry-safe, observable, and fast to acknowledge.
Code example
I switched to images to reduce email clipping!
Security: Always Verify Signatures
Webhook endpoints are usually public URLs, so anyone who can reach the URL can attempt to POST to it. A secret-looking URL alone is not authentication.
How do you know it's actually from Stripe and not some random person messing with you?
Many providers attach a cryptographic signature/HMAC or another verifiable credential to each delivery. Your server should verify requests exactly the way that provider documents.
Important details that are easy to mess up:
Verify the signature before trusting the payload.
Verify freshness/timestamps or another anti-replay value when the provider supports it. A valid old signed request should not necessarily be reusable forever.
Preserve the raw request body when the signature algorithm requires signing the raw bytes. Parsing/re-serializing JSON first can change the bytes and break verification.
Use provider/library helpers or constant-time comparison rather than inventing signature verification yourself.
Rotate webhook secrets safely and store them in secret management/configuration—not source code.
Signature verification tells you the delivery was created by someone holding the expected secret/key. It does not by itself make your business logic safe—you still need authorization/invariant checks on whatever action the event triggers.
Building Your Own Webhook System
So you want to send webhooks to YOUR users when stuff happens in your app?
The basics you need go beyond “POST some JSON”:
1. Let Users Subscribe
2. Send Signed Webhooks
3. Trigger When Events Happen
4. Deliver asynchronously and retry carefully
Do not make your customer’s endpoint part of the critical path of your own transaction. Persist/enqueue the event, deliver it from workers, use bounded retries with backoff, and record each attempt.
Expect customer endpoints to timeout, return 500, disappear for an hour, or respond after your own timeout. A retry can create duplicate delivery, so every event needs a stable identifier.
5. Give customers observability
Useful webhook products expose recent deliveries, response codes, timestamps, retry status, and a way to replay failed events. Otherwise debugging becomes “well, we sent something at some point, probably.”
6. Protect outbound webhook senders from SSRF
If users can register arbitrary callback URLs, your delivery service is making server-side requests to user-controlled destinations. Validate schemes, resolve/re-resolve DNS carefully, block private/link-local/internal address ranges as appropriate, limit redirects, set timeouts/body limits, and isolate the delivery worker from sensitive internal networks.
Common Questions
"What if my server is down when the webhook fires?"
Many providers retry deliveries that fail or time out, but the retry schedule and retention period are provider-specific. Some systems eventually stop retrying and require manual replay/recovery.
Monitor failed deliveries and keep your own source of truth. A webhook should usually be treated as a notification that something changed, not as the only permanent copy of critical business state. For important integrations, you may reconcile against the provider’s API after gaps/outages.
"Can I test webhooks locally?"
Yes!
Lots of services have ways to test locally, but you can also use ngrok to create a public tunnel to your localhost.
"What if the same webhook gets sent twice?"
Duplicate delivery is normal in retry-based systems. A provider may not know whether your server processed the event if the response was lost or timed out, so it can safely choose to send it again.
Make handlers idempotent or deduplicate by a stable event/delivery ID.
Idempotent means processing the same logical event multiple times does not incorrectly repeat the side effect.
For example, record the provider’s event ID in a database with a uniqueness constraint before issuing a refund, crediting an account, or sending a one-time benefit. “The output text looks the same twice” is not enough if the underlying side effect happened twice.
"Will events arrive in order?"
Do not assume it unless the provider explicitly guarantees the ordering you need. Retries, parallel delivery, and network delays can make event B arrive before event A. Include/use resource versions or timestamps when available, and fetch current authoritative state when order matters more than the individual event payload.
The Bottom Line
Webhooks = “I’ll notify your endpoint when something happens” instead of making you poll constantly.
The request itself is simple HTTP. The engineering is in verification, fast acknowledgement, queues, retries, deduplication/idempotency, ordering, reconciliation, and observability.
If you want to keep learning
APIs explained — the request/response model webhooks build on.
SDKs explained — the developer tooling many APIs ship with.
GraphQL explained — another common API pattern for client-server communication.
Thanks to everyone who submitted!
grcc492, JunKaiPhang, gcavelier, AspenTheRoyal, Yeshua235, jsjasee, NeoScripter, alfalconetti, Suji-droid, and Vimalmr!
Find the Itinerary in Alphabetical Order
You are given a list of airline tickets, where each ticket is a pair [from, to] representing a flight from one airport to another.
Your task is to reconstruct the complete travel route in the correct order.
All trips start from airport "A".
If there are multiple possible routes, return the one that comes first in alphabetical order (when read as a single string).
Examples
findPath([["C", "F"], ["A", "C"], ["I", "Z"], ["F", "I"]])
output = ["A", "C", "F", "I", "Z"]
findPath([["A","C"],["A","B"],["C","B"],["B","A"],["B","C"]]
output = ["A","B","A","C","B","C"]
# Another valid route is ["A","C","B","A","B","C"],
# but it comes later alphabetically.
findPath([["Y", "L"], ["D", "A"], ["A", "D"], ["R", "Y"], ["A", "R"]])
output = ["A", "D", "A", "R", "Y", "L"]
Notes
Every ticket must be used exactly once.
There will always be at least one valid route.
When comparing routes alphabetically, for example:
["A", "B"]<["A", "C"].
How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
Weekly Update: Idea for the newsletter
Every now and then, I want to share the process behind what I’m building with this newsletter.
Right now it's just me writing everything.
But what if I brought in other engineers sometimes?
People building cool things, solving tricky problems, or just wanting to share what they've learned.
Maybe short interviews. Maybe guest written posts. Maybe just a "here's how I solved this hard problem" section.
It'd keep the same Sloth Bytes vibe: simple, honest, practical, but with more voices and perspectives.
Why?
There are only so many topics I can explain well.
I'd rather bring in people who can teach you/show you things I can't, rather than trying to explain concepts I don't fully understand yet just to keep the content flowing.
So I'm curious what you think:
Would you want to see other engineers featured here?
I’ll read every response and I plan on replying to everyone who writes back!
I want to really understand what you think and make this newsletter the highest quality it can be.
But that’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of 50k developers and programming enthusiasts, you may want to advertise with us here.
