DEV Community: Yuriy

Webhooks don’t care that your laptop is offline

Yuriy — Mon, 20 Jul 2026 07:00:00 +0000

Local development environments and webhook senders operate on completely different schedules.

Your application runs when you need it. It may stop when you close your laptop, restart Docker, lose your internet connection, or finish work for the day.

A webhook provider does not know any of that. When an event occurs, it sends the request.

So what happens when your local application is unavailable?

A tunnel only works while the tunnel is running

Tunneling tools provide a convenient route from the public internet to a local application:

Webhook provider → tunnel → local application

This works well while the tunnel, internet connection, and application are all running.

If any part of that path becomes unavailable, the request cannot reach your handler. Some providers retry failed webhooks, but they control the retry schedule. You do not decide how many attempts they make, how long they wait, or when they give up.

A tunnel provides connectivity. It does not necessarily provide durable request storage or deferred delivery.

You could build the infrastructure yourself

One solution is to rent a VPS and build an intermediate webhook receiver.

That usually involves:

configuring DNS and HTTPS;
running a reverse proxy;
storing incoming requests;
implementing retries and deferred delivery;
setting up logs and monitoring;
installing security updates;
keeping the entire system available.

You could deploy those components to Kubernetes as well.

That may be appropriate for a production platform, but it is a lot of infrastructure when the original requirement was simply:

Receive a webhook now and deliver it to my local application later.

Separating receipt from delivery

This is the problem we designed Adal to solve.

Instead of making the local machine permanently accessible, Adal separates webhook receipt from local delivery:

Webhook provider → Adal Server → Adal CLI → local application

An Adal Server provides a permanent public HTTPS endpoint. When it accepts a webhook, it stores the request in the selected region, including its method, path, query parameters, headers, and body.

When Adal CLI connects, it forwards requests to a configured local Destination such as:

http://127.0.0.1:3000

If Deliver pending requests on connect is enabled, requests received while the CLI was offline can be delivered after it reconnects, as long as they are still within the plan’s retention period.

A simple example

Imagine testing a payment.completed webhook while traveling.

The payment provider sends the event while your laptop has no connection. With a standard tunnel, delivery depends on whether the provider retries after you are back online.

With Adal:

The provider sends the webhook to the Adal Server.
Adal accepts and stores the request.
Your laptop reconnects and Adal CLI starts or reconnects.
The CLI forwards the pending request to your local handler.
You inspect the delivery result in the Adal dashboard.

There is no need to repeat the test payment just to generate the same event again.

The same workflow can help when developing bots, testing GitHub events, debugging CRM integrations, or connecting services available only inside a private network.

Use infrastructure that matches the problem

Tunnels, VPS instances, and Kubernetes all have valid use cases.

Use a tunnel when you need temporary public access to a running local port. Use a VPS or Kubernetes when you need to host and operate persistent applications.

But if the problem is receiving webhooks while a local environment is unavailable, you may not need to build an entire delivery system yourself.

Sometimes you need webhooks—but not Kubernetes.

You can try the workflow using the Adal quickstart guide.

Read the complete article: When You Need Webhooks but Not Kubernetes

Your Webhook Receiver Is Offline. Now What?

Yuriy — Mon, 13 Jul 2026 07:00:00 +0000

Webhooks look simple when everything works.

A service sends an HTTP request, your application receives it, and the event is processed within milliseconds.

But production networks are rarely that predictable.

The receiving service may be restarting. A route may disappear for several minutes. An ISP may filter certain traffic. A corporate firewall may prevent inbound connections altogether. And sometimes the service that needs the webhook is running on a developer’s laptop or inside a private network with no public IP address.

So what happens to the webhook while the receiver is offline?

If the sender retries long enough, you may be fine. If it does not—or if its retry window ends before your service recovers—the event may never reach your application.

Let’s look at how to make this delivery path more resilient.

The hidden coupling in a typical webhook integration

A direct webhook integration usually looks like this:

Webhook provider ──────HTTP request──────> Your application

This design couples two separate events:

the provider sending the webhook;
your application being ready to process it.

For the delivery to succeed, both systems—and the network between them—must be available at the same moment.

That creates several possible failure points:

the receiving application is deploying or restarting;
DNS resolution fails temporarily;
the route between networks is unstable;
the request times out;
a firewall rejects the connection;
the receiver is available only from a private network;
the sender stops retrying before the receiver recovers.

The webhook provider may have its own retry policy, but those policies vary. Some services retry for hours, others make only a few attempts, and some treat certain HTTP responses as permanent failures.

Your application has no control over that behavior.

Separate receiving from processing

A more resilient design introduces a persistent delivery layer between the webhook provider and the final destination:

Webhook provider
        │
        │ HTTPS
        ▼
   Adal Server
   ┌───────────────┐
   │ Receive       │
   │ Store         │
   │ Inspect       │
   │ Retry         │
   │ Redeliver     │
   └───────────────┘
        │
        ├── Direct HTTP ──> Public service
        │
        └── Adal CLI ─────> Private or local service

Instead of sending the webhook directly to your application, the provider sends it to a permanent HTTPS endpoint created in Adal.

Adal receives and stores the request first. Delivery to your application becomes a separate operation that can be retried if the destination is unavailable.

This changes the failure model.

Your application no longer needs to be online at the exact moment the webhook is created. It only needs to become available before the webhook’s retention period expires.

Setting up the receiving endpoint

After creating an account in Adal, create a Server in the Servers section.

The Server receives a permanent HTTPS URL. Use that URL as the webhook endpoint in the sending service.

The flow then becomes:

The provider sends a webhook to the Adal Server.
Adal receives and stores the request.
The webhook becomes available for inspection and auditing.
Adal forwards it to one or more configured destinations.
If delivery fails, Adal performs the configured retry attempts.

Destinations are configured separately, so the same incoming webhook can be routed according to the needs of each receiving system.

There are two delivery options: Direct HTTP and Adal CLI.

Option 1: Direct HTTP

Direct HTTP is the simplest option when the receiving service already has a public endpoint.

Provider ──> Adal ──> https://api.example.com/webhooks

Adal forwards the webhook directly to the configured HTTPS address.

The request is delivered as received, with one intentional change: Adal identifies itself in the User-Agent header. This makes the delivery path transparent and helps investigate reports of unwanted or malicious requests.

Direct HTTP is useful when:

the receiver has a public IP address or hostname;
the service is reachable from the internet;
the endpoint occasionally goes offline;
network routing between the original sender and receiver is unreliable;
you want stored requests, delivery history, and controlled retries.

Each destination has its own retry configuration. If the receiving service does not respond, Adal makes the configured number of automatic delivery attempts.

Example: a temporarily unavailable payment handler

Imagine that a payment provider sends this event:

{
  "event": "payment.completed",
  "payment_id": "pay_84b7d1",
  "amount": 4900,
  "currency": "USD"
}

At that moment, your payment handler is being deployed and cannot accept requests.

With direct delivery, the result depends entirely on the payment provider’s retry policy.

With Adal in the middle, the event is accepted and stored first. Adal then attempts to deliver it to your handler. If the handler recovers during the automatic retry window, delivery continues without requiring the original provider to send the event again.

Option 2: Adal CLI

Not every webhook receiver should be publicly accessible.

You may need to deliver events to:

an application running on a developer’s computer;
a test environment inside a private network;
an internal business service;
a machine behind NAT;
a service protected by a corporate router;
a system without a public IP address.

Opening inbound ports for these systems may be inconvenient, unsafe, or prohibited by network policy.

Adal CLI handles this by establishing a persistent, encrypted outbound WebSocket connection to Adal:

Provider ──> Adal <════ outbound WebSocket ════ Adal CLI ──> Local app

Because the connection is initiated by Adal CLI, you do not need to:

expose the local application to the internet;
configure port forwarding;
open an inbound firewall port;
assign a public IP address to the machine.

When the Adal Server receives a webhook, it sends the request through the established connection. Adal CLI then forwards it to the local endpoint configured by the user.

This is especially useful during development, but it can also work for internal services that are intentionally unavailable from the public internet.

What happens when automatic retries run out?

Automatic retries solve temporary failures, but no retry schedule can continue forever.

A destination might remain offline longer than expected. A hardware failure may take several hours to repair. A deployment may need to be rolled back manually. An office network may stay disconnected until the next morning.

If all automatic delivery attempts are exhausted before the receiver returns, Adal keeps the stored webhook available until the end of its retention period.

Once the destination is working again, you can restart the delivery manually.

Automatic retries exhausted
            │
            ▼
Webhook remains stored in Adal
            │
     Receiver recovers
            │
            ▼
User starts redelivery manually

The number of previous automatic attempts does not prevent manual redelivery. The only requirement is that the original webhook must still be stored in Adal.

After the retention period expires, the webhook is permanently deleted. At that point, it can no longer be inspected, recovered, or delivered again.

A practical recovery scenario

Suppose an internal order-processing service loses its network connection at 10:00.

During the outage:

An e-commerce platform sends several order events.
Adal receives and stores them.
Automatic delivery attempts fail because the internal service is offline.
The retry limit is reached at 10:30.
The network is restored at 12:00.
An operator verifies that the order service is healthy.
The failed deliveries are restarted manually.

The original events can still be delivered because they remain within their retention period.

Without an intermediate storage layer, recovery might require asking the original platform to resend the events—assuming that it supports manual redelivery and still retains them.

Design your receiver for duplicate delivery

Reliable delivery and exactly-once processing are not the same thing.

Any system that retries HTTP requests can potentially deliver the same event more than once. A receiver may successfully process a webhook but fail to return a response before the sender times out. From the sender’s perspective, the result is unknown, so it retries.

Manual redelivery creates the same possibility.

Webhook handlers should therefore be idempotent whenever possible.

A common approach is to store a unique event ID before performing business operations:

Receive webhook
      │
      ▼
Extract event ID
      │
      ▼
Was this ID already processed?
      │
   ┌──┴──┐
  Yes    No
   │      │
Return   Process event
2xx      Store event ID

A simplified handler might follow this logic:

async function handleWebhook(event) {
  if (await eventStore.wasProcessed(event.id)) {
    return { status: 200, message: "Already processed" };
  }

  await processEvent(event);
  await eventStore.markAsProcessed(event.id);

  return { status: 200, message: "Processed" };
}

The exact implementation depends on your database and consistency requirements, but the principle is important: retries should not create duplicate payments, orders, emails, or other irreversible side effects.

Security considerations

Adding a delivery layer does not remove the need to secure the receiving endpoint.

Consider the following before going to production:

Validate webhook signatures when the provider supports them.
Treat all webhook payloads as untrusted input.
Use HTTPS for public destinations.
Restrict what the webhook handler is allowed to do.
Avoid storing secrets in webhook URLs.
Monitor repeated failures and unexpected delivery patterns.
Test how signature validation behaves when a request passes through an intermediary.
Define an appropriate retention period for the sensitivity of your data.

Adal stores webhook contents in encrypted form. Stored webhooks are available only to the user who owns the corresponding Server.

Adal does not sell or use webhook contents for unrelated purposes. The data is processed to store requests and deliver them to destinations configured by the user.

Adal is a transport layer, not a policy bypass

There is an important distinction between improving delivery reliability and bypassing network restrictions.

Adal is designed to transport webhooks between systems with unstable or limited connectivity. It is not intended to circumvent security controls, regional restrictions, or organizational network policies.

Before connecting an internal system, confirm that the setup is permitted by the network owner or system administrator.

This is particularly important in corporate environments where outbound connections, third-party data processing, and webhook payload retention may be subject to security or compliance requirements.

Choosing a delivery method

The choice between Direct HTTP and Adal CLI depends primarily on whether the receiving service is publicly reachable.

Requirement	Direct HTTP	Adal CLI
Public receiving endpoint	Required	Not required
Public IP address	Usually required	Not required
Open inbound port	Required	Not required
Works with local development	Possible with extra networking	Yes
Works behind NAT	Only with forwarding or a proxy	Yes
Automatic retry support	Yes	Yes
Manual redelivery during retention	Yes	Yes

Use Direct HTTP when your service already exposes a public HTTPS endpoint.

Use Adal CLI when the destination is local, private, behind NAT, or unable to accept inbound internet connections.

Production checklist

Before relying on any webhook delivery pipeline in production, verify the complete failure path:

Send a test webhook successfully.
Confirm that the HTTP method, headers, and body arrive as expected.
Stop the receiving service.
Confirm that failed delivery attempts are recorded.
Start the service again during the retry window.
Verify that automatic delivery resumes.
Exhaust the automatic retries in a test environment.
Restart the delivery manually.
Test duplicate events and confirm idempotent processing.
Verify signature validation.
Review the webhook retention period.
Confirm the setup with the network or security administrator.
Add monitoring for repeated delivery failures.

Testing failure behavior is just as important as testing the successful path. The middle of an outage is a bad time to discover that a retry policy, signature check, or deduplication mechanism does not behave as expected.

Final thoughts

The main reliability problem with direct webhooks is timing: the sender and receiver must both be available at the same moment.

A persistent delivery layer breaks that dependency.

Adal receives and stores the webhook first, then attempts to deliver it through Direct HTTP or Adal CLI. Temporary failures are handled with automatic retries. Longer outages can be handled with manual redelivery, provided the webhook is still within its retention period.

That does not eliminate every integration failure. Your handlers still need authentication, validation, monitoring, and idempotency. But it gives you something extremely valuable during an outage: time to restore the receiving service without immediately losing the original request.

How do you currently handle webhooks when a destination remains offline longer than the sender’s retry window?

Webhook idempotency: how to handle duplicate deliveries safely

Yuriy — Mon, 06 Jul 2026 07:00:00 +0000

Webhook delivery is usually described as a simple flow:

Provider sends an event → your endpoint receives it → your application processes it

In production, it is rarely that simple.

A webhook can be delivered more than once because of timeouts, network failures, retries, process restarts, or an HTTP response that was generated successfully but never reached the sender.

That means every webhook consumer should answer one question before it becomes an incident:

What happens if the same webhook is processed twice?

If the answer is “we create the same record again,” “we send another email,” or “we charge the customer a second time,” the integration needs idempotency.

Duplicate delivery is normal

Webhook providers often use at-least-once delivery semantics.

In practical terms, this means a provider tries to ensure that an event is delivered successfully. If it cannot confirm success, it may send the event again.

Consider this sequence:

1. A provider sends a webhook.
2. Your service receives it.
3. Your service creates an order in the database.
4. Your service responds with 200 OK.
5. A network issue prevents the provider from receiving that response.
6. The provider retries the webhook.

From the provider’s perspective, the first attempt may have failed.

From your application’s perspective, the business action has already happened.

Without protection against duplicates, the retry may create a second order.

This can lead to duplicate payments, duplicate CRM entities, repeated emails, duplicated jobs, or inconsistent state in downstream systems.

What idempotency means

An operation is idempotent when performing it multiple times produces the same final state as performing it once.

For example, setting a user's status is naturally idempotent:

PUT /users/42/status
Content-Type: application/json

{
  "status": "active"
}

Sending that request twice still leaves the user active.

Creating a payment is different:

POST /payments
Content-Type: application/json

{
  "amount": 100
}

Without an additional mechanism, sending this request twice may create two payment operations.

Webhook consumers should be designed so that a retry does not repeat the business action.

Why payload comparison is not reliable

A common first attempt is to compare incoming request bodies.

For example, store the webhook payload and reject any future request with the same JSON.

This approach breaks down quickly.

Two separate events may have identical payloads:

{
  "event": "invoice.created",
  "amount": 1000,
  "currency": "USD"
}

These could represent two different invoices with the same amount and currency.

The same problem applies to payload hashes. A hash makes comparisons easier, but it does not tell you whether two equal payloads represent:

the same event delivered again; or
two different events with the same contents.

There are also implementation questions that become surprisingly difficult:

Should timestamps be included?
Should signatures be included?
Does JSON key order matter?
Should query parameters be compared?
How do you handle binary payloads?
Which fields are stable across retries?

A payload is data. It is not necessarily an event identity.

Use an explicit idempotency key

The usual solution is an idempotency key: a unique identifier associated with one logical operation.

The sender includes the key with the request. The receiver stores it and ensures that the same key cannot trigger the same business action twice.

For example:

POST /webhooks/payment
Content-Type: application/json
X-Idempotency-Key: 01989d55-20df-7a72-87f9-6e50f3d78315

{
  "event": "payment.completed",
  "amount": 100
}

The processing flow becomes:

1. Receive the webhook.
2. Read the idempotency key.
3. Atomically reserve or store the key.
4. If the key already exists, treat the request as a duplicate.
5. If the key is new, perform the business action.

The key must be handled atomically.

A simple “check whether it exists, then insert it” flow is not safe under concurrent requests:

Request A checks for key → not found
Request B checks for key → not found
Request A creates order
Request B creates order

The uniqueness check belongs in the database.

Example: PostgreSQL

A minimal schema might look like this:

CREATE TABLE processed_webhooks (
    idempotency_key TEXT PRIMARY KEY,
    processed_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Then reserve the key with a single statement:

INSERT INTO processed_webhooks (idempotency_key)
VALUES ($1)
ON CONFLICT (idempotency_key) DO NOTHING;

Your application can inspect the number of inserted rows:

1 row inserted: this is the first time the key was seen;
0 rows inserted: the key was already processed.

For example, in Go:

result, err := db.ExecContext(
    ctx,
    `
        INSERT INTO processed_webhooks (idempotency_key)
        VALUES ($1)
        ON CONFLICT (idempotency_key) DO NOTHING
    `,
    idempotencyKey,
)
if err != nil {
    return err
}

rowsAffected, err := result.RowsAffected()
if err != nil {
    return err
}

if rowsAffected == 0 {
    // This webhook was already processed.
    return nil
}

// Perform the business action here.

In a real system, you may also want to store:

the event type;
the processing status;
the response or created entity ID;
the original request ID;
failure details;
timestamps for cleanup and retention.

The exact design depends on whether repeated requests should receive the original result, a generic success response, or a specific “already processed” response.

Store keys for long enough

Idempotency keys are only useful while they are retained.

If a provider can retry a webhook several hours or days later, deleting the key after five minutes may reintroduce duplicate processing.

The retention period should be based on:

the provider’s retry policy;
your own retry policy;
the type of side effect;
how expensive or dangerous duplicate execution would be;
compliance and storage requirements.

For financial operations, order creation, provisioning, or external API calls, it is usually better to retain keys longer than the minimum expected retry window.

Idempotency is not only for payments

Idempotency keys are often associated with payment APIs, but they are useful anywhere a request can cause a side effect.

Typical examples include:

creating users or accounts;
provisioning infrastructure;
sending emails or messages;
updating CRM records;
triggering deployments;
creating support tickets;
synchronizing data to external systems;
scheduling jobs;
processing queue messages;
handling webhook events.

The more expensive or irreversible the action is, the more important duplicate protection becomes.

Adding idempotency keys with Adal

Not every webhook provider sends a suitable event ID or idempotency key.

Some providers include an event ID in the payload. Others expose it through a header. Some do not provide a stable identifier at all.

Adal can add an idempotency key when forwarding a webhook to a destination.

When enabled, Adal adds:

X-Adal-Idempotency: <unique-key>

The setting is configured separately for each destination.

This matters because some consumers may require the original request to remain unchanged, while others benefit from an explicit delivery identity.

The key belongs to one request in Adal.

That gives retries and replays intentionally different behavior:

Automatic retry of the same request
→ same X-Adal-Idempotency value

Manual retry of the same delivery
→ same X-Adal-Idempotency value

Replay of an older webhook
→ new X-Adal-Idempotency value

This distinction is important.

An automatic retry is another technical attempt to deliver the same logical request. It should carry the same idempotency key.

A replay is an explicit decision to create a new request from an older webhook. Even when the payload is identical, it represents a new action and receives a new key.

A practical scenario

Imagine a webhook that creates a customer and an order in your CRM.

Without idempotency:

1. Adal delivers the webhook.
2. Your service creates the customer and order.
3. Your service returns 200 OK.
4. The response is lost because of a network failure.
5. Adal retries.
6. Your service creates another customer and another order.

With X-Adal-Idempotency:

1. Adal delivers the webhook with X-Adal-Idempotency.
2. Your service reserves the key in the database.
3. Your service creates the customer and order.
4. The response is lost.
5. Adal retries using the same key.
6. Your service sees that the key already exists.
7. No duplicate customer or order is created.

Delivery can be retried until the sender receives confirmation, while the business action is executed once.

Final thoughts

Duplicate webhooks are not an exceptional failure mode. They are a normal part of building reliable systems over unreliable networks.

A webhook consumer should not rely on exactly-once delivery unless the provider explicitly guarantees it end to end — and even then, downstream side effects may still need protection.

Do not use payload equality as event identity. Two different events can look identical, and the same event can be delivered multiple times.

Use an explicit idempotency key, enforce uniqueness atomically, and design the consumer so repeated delivery does not repeat the side effect.

That makes retries safe, debugging easier, and webhook integrations much more predictable.

Adal is a webhook delivery and observability platform. It can optionally add X-Adal-Idempotency to forwarded requests on a per-destination basis, helping webhook consumers safely distinguish retries from new requests.

Why Webhooks get lost and why they sometimes arrive twice

Yuriy — Mon, 29 Jun 2026 07:00:00 +0000

Webhooks often look deceptively simple.

One service sends an HTTP request. Another service receives it. The receiver returns 200 OK, processes the payload, and everyone moves on.

That model works until the webhook becomes part of a real business process.

A missed event can mean a customer message that never reaches a chatbot, an order that does not appear in a CRM, a subscription that is not updated, or a payment that succeeds but does not unlock access for the customer.

But lost webhooks are only half of the problem. The other half is duplicate delivery. A reliable webhook integration must be prepared for both.

What does it mean to lose a webhook?

A webhook is lost when an event is sent but never successfully processed by the receiving system.

There are many possible causes:

the receiving server is temporarily unavailable;
a reverse proxy is misconfigured;
the application crashes after accepting the request;
the database is overloaded;
a TLS certificate expires;
a deployment introduces an unexpected error;
a DNS or network change routes traffic to infrastructure that is no longer active.

For a low-risk notification, this may be inconvenient but manageable. For a production integration, it can become a business problem.

Imagine a payment provider sends an event confirming that a customer has paid. If your application never processes that event, the customer may be charged but never receive access to the product.

That is not just a technical failure. It creates support work, refunds, manual reconciliation, and a loss of trust.

DNS migrations can create both loss and duplication

A common example is moving an application to a new server.

The usual approach looks simple:

Deploy the application to a new server.
Update the DNS record.
Wait for traffic to move.
Shut down the old server.

The problem is that DNS does not update everywhere at the same moment.

Resolvers, ISPs, corporate networks, and individual machines may cache the old address for different amounts of time. Even when the DNS TTL is low, some traffic can continue reaching the old server after the record has been changed.

During the transition, different webhook senders may reach different servers:

Webhook provider
        |
        +--> old server
        |
        +--> new server

If the old server is already offline, webhooks sent there may fail or be lost. If both servers are active, the same event can potentially be processed twice. That creates a different class of failure.

A chatbot might send two replies to the same message. A CRM integration might create duplicate records. A payment workflow might credit a balance twice or issue the same product twice.

Why retries are necessary

Webhook delivery should normally use an at-least-once model.

That means a sender retries delivery when it cannot confirm that the receiving system accepted the event. This is much safer than silently dropping an event after one failed attempt.

However, at-least-once delivery has an important consequence:

The receiving system must assume that the same event can arrive more than once.

A sender may retry because:

the destination returned a 5xx response;
the connection timed out;
the destination was temporarily unavailable;
the sender did not receive the response, even though the receiver processed the request;
the provider intentionally retries to protect against transient network failures.

This is normal behaviour. It is not necessarily a bug in the provider. The receiving side must be designed accordingly.

Idempotency is the protection against duplicates

The key concept is idempotency.

An idempotent operation produces the same final result whether it runs once or several times.

For webhook processing, this usually means storing the provider’s event identifier before running the business logic.

A simplified flow might look like this:

Receive webhook
        |
        v
Validate signature
        |
        v
Check event ID
        |
        +--> already processed --> return 200 OK
        |
        v
Store event ID
        |
        v
Run business logic
        |
        v
Return 200 OK

For example, if a payment provider sends an event with the ID evt_123, your application should record that ID after receiving it.

If the same event arrives again, the application should recognise it as a duplicate and avoid repeating the business operation.

Returning 200 OK is still important: it tells the sender that the event has been safely handled, even when no additional action was needed.

Acknowledge quickly, process safely

Another useful pattern is to separate acceptance from processing.

Instead of performing all business logic directly inside the webhook request handler, the application can:

Validate the request.
Store the event durably.
Return a successful response quickly.
Process the event asynchronously.

This reduces the risk of timeouts and makes failures easier to recover from. It also gives you a durable record of what happened, which is essential when investigating an incident.

Of course, this only works if the storage step itself is reliable. Returning 200 OK before the event has been saved somewhere durable can still cause data loss.

A practical webhook reliability checklist

A production webhook integration should answer these questions clearly:

What happens when the destination is temporarily unavailable?
Are failed deliveries retried?
How long are retries performed?
Can the same event be delivered more than once?
Does the application use event IDs or idempotency keys?
Are incoming requests stored before expensive processing starts?
Can the delivery history be inspected later?
Can a failed event be replayed safely?
During a migration, how long will the old endpoint remain available?
Can the team distinguish between an event that was never received and one that was received but failed during processing?

If these questions do not have explicit answers, reliability depends too heavily on everything going right.

And in production, everything eventually does not.

Reliability is not just an HTTP status code

Returning 200 OK is not the same as handling an event reliably.

Reliable webhook processing requires a clear delivery model, retry behaviour, idempotent business logic, durable event storage, and enough visibility to understand what happened when an incident occurs.

That is why webhook infrastructure matters.

Adal Cloud is designed to make webhook delivery predictable and observable: incoming requests are retained, delivery attempts can be inspected, failed deliveries can be retried, and stored requests can be replayed when needed.

When webhooks carry events that matter to customers, payments, or business operations, the delivery path should not be the least reliable part of the system.

Why I made Adal CLI Open Source

Yuriy — Wed, 24 Jun 2026 07:00:00 +0000

When you build an app that runs on someone else’s machine, trust becomes a very practical issue.

It is not just about branding, positioning, or saying the right things on a landing page. The user is allowing your software to run in their local environment. Depending on what the app does, that environment may include files, terminal commands, configuration, credentials, or work projects.

So the question becomes simple: how can a user know that the app is doing only what it is supposed to do?

For Adal CLI, I decided that the answer should not be “just trust me.”

It should be verifiable.

Local apps need a different level of trust

A web app usually runs on infrastructure controlled by the product team. A local app is different. It runs directly on the user’s device.

That changes the trust model.

If a CLI tool reads files, sends requests, modifies configuration, or interacts with local projects, users have every right to ask:

What exactly does it read?
What does it send over the network?
Does it collect anything unnecessary?
Can I build it myself instead of downloading a binary?
What happens if the project stops being maintained?

These are fair questions. And for developer tools, they are especially important.

Open Source makes trust verifiable

This is one of the main reasons I made Adal CLI open source.

Open source does not magically make a project secure or trustworthy. But it changes the relationship between the developer and the user.

Instead of asking people to believe a claim, it gives them a way to verify it.

Anyone can inspect the code and see what the app actually does. If someone does not want to use a prebuilt binary, they can build the project from source. If a developer wants to review how data is handled, they can do that. If someone finds a problem, they can open an issue or submit a pull request.

That possibility matters, even if most users never read the source code themselves.

It also makes development more transparent

Another benefit of open source is that people can see how the project evolves.

They can look at the changelog, commits, issues, and pull requests. They can see which bugs were fixed, which features were added, and how decisions were made over time.

For me, that transparency is important. A local tool should not feel like a black box.

This is especially true for CLI tools, because they often operate close to the developer’s actual work: repositories, config files, scripts, and terminal workflows.

Open Source is not a shortcut

There is one important caveat: publishing the code is not enough.

Open source is not a substitute for responsibility. A project can be open and still be confusing, insecure, poorly documented, or hard to build.

So if open source is meant to support trust, it should come with the basics:

clear documentation;
reproducible builds;
a changelog;
a license;
instructions for building from source;
an explanation of what data the app uses and why.

Without those things, “the code is open” can become more of a slogan than a real advantage.

Reducing dependency on one maintainer

There is another reason I care about this: sustainability.

If a tool becomes useful to people, they should not be completely dependent on one person maintaining it forever.

With an open source project, the community can fork it, fix critical issues, adapt it to specific needs, or continue development if the original maintainer slows down or moves on.

That does not guarantee anything, of course. But it gives the project a better chance to survive beyond a single author.

Final thought

Not every app has to be open source.

But if you are building something that runs locally, touches files, works with terminal commands, reads configuration, or handles sensitive data, openness can become one of the strongest arguments for trust.

Trust is hard to earn through promises.

It is much easier to build through transparency, verifiability, and respect for the user.

That is why Adal CLI is open source.

When you just need to inspect a webhook before writing code

Yuriy — Sat, 13 Jun 2026 04:16:51 +0000

Webhooks are usually discussed as something your application should process automatically.

A payment provider sends an event. A Git hosting service notifies you about a push. A SaaS product sends a status update. Your backend receives the request, verifies it, stores it, and runs the required logic.

But before all of that, there is often a much simpler step: you just need to see what the webhook actually looks like. Not the example from the documentation. Not the expected payload in your head. The real request.

What method does it use? Which headers are included? How is the body structured? Where is the event type stored? Are there signatures, timestamps, nested fields, IDs, or provider-specific details that are not obvious from the docs?

For this first step, setting up a local server can be unnecessary work.

You can use a tunneling tool, expose your local application, write a temporary handler, log the request, format the output, and then inspect the result. That works, but sometimes it is too much for a simple question: what exactly does this service send?

This is one of the scenarios where Adal can help.

Adal gives you a permanent webhook endpoint URL. You can paste that URL into the webhook settings of a service like Stripe, GitHub, Slack, Dodo Payments, or any other provider that sends webhook events.

When the webhook arrives, Adal stores the request and shows it in the interface.

You can inspect:

HTTP method
path
headers
body
payload structure
request size
delivery details

This is useful before you write the real backend handler.

You can send a test webhook, inspect the actual request, compare it with the documentation, and only then decide how your application should process it.

This is also useful when debugging. Sometimes the problem is not in your handler at all. The webhook may not be reaching the expected URL. The payload may not match the event you selected. A header may be missing. A signature may be different from what you expected.

Having the raw request visible makes this much easier to understand.

This does not replace proper webhook processing. You still need your backend, validation, signature verification, retries, idempotency, and business logic for production workflows.

But before that, there is a very practical first step: receive the webhook, look at it and understand what was actually sent.

That is the small use case Adal is designed to make simple.

No temporary server just to inspect a payload. No manual log formatting. No guessing based only on documentation. Just a real incoming webhook, shown in a way that is easy to inspect before you write the code that handles it.

Building Adal: predictable webhook delivery without black boxes

Yuriy — Thu, 11 Jun 2026 16:29:50 +0000

Hi DEV community,

I'm Yuriy, a fullstack developer and DevOps engineer with 10+ years of experience. I'm currently building Adal — a webhook delivery and observability platform for developers.

The idea came from a simple frustration: webhook delivery often feels like a black box.

A provider sends a request. Something fails. Maybe the endpoint was down, maybe the payload was different than expected, maybe the retry happened later, maybe the logs are incomplete. As developers, we often end up guessing instead of debugging from clear facts.

Adal is my attempt to make webhook delivery more predictable.

The core principles are simple:

permanent endpoint URLs;
full request visibility;
delivery logs that explain what happened;
replay without waiting for the provider;
retries that are visible and controlled;
no hidden transformations;
infrastructure that can be inspected and reasoned about.

I'm building Adal as a practical developer tool, but also as an engineering experiment: how much of webhook infrastructure can be made explicit, observable, and boring in a good way?

The stack is mostly Go, PostgreSQL, Redis, React, Docker, Cloudflare R2, and a regional architecture for receiving and delivering webhook requests. The CLI is open source and written in Go.

On this DEV organization page, I plan to write about the technical side of building Adal: webhook infrastructure, backend reliability, regional delivery, observability, product decisions, failures, trade-offs, and lessons from building a SaaS from scratch.

This is still an early-stage project, but it is already public and usable.

If you work with webhooks, build integrations, or care about predictable backend systems, I'd be happy to hear your feedback.