Adal Endpoints

What is an Endpoint?

An Endpoint is a public URL in Adal that receives webhook requests from external services.

For example, when GitHub, Stripe, Slack, Telegram, Make, Zapier, or another service needs to send an event to your application, you can use an Adal Endpoint URL as the webhook destination. Adal will receive the incoming request, store its details, and make it available in the dashboard.

An Endpoint is the entry point for your webhooks. It does not hide requests, transform them in the background, or make decisions for your application. Its job is to receive the HTTP request, record what was received, and make the next steps observable.

Every webhook received by an Endpoint is stored as a separate Request. You can open the Request and inspect its method, path, headers, body, size, received time, and other technical details. If the Endpoint has Destinations configured, Adal will also try to deliver the Request to those Destinations.

In simple terms:

An Endpoint gives you a stable and observable place to receive webhooks: a permanent URL, a history of incoming requests, delivery status, and the ability to replay requests when needed.

When to use Endpoints

Use an Endpoint when you need a stable place to receive, inspect, and deliver webhook requests.

Endpoints are useful when you want to check whether an external service is actually sending webhooks, inspect the full HTTP request, debug webhook delivery, or replay an event without waiting for the external service to send it again.

Common use cases include:

• Testing webhooks during development
• Receiving webhooks without exposing your local machine to the internet
• Using a permanent webhook URL instead of temporary tunnel URLs
• Inspecting request headers, body, method, path, query parameters, and size
• Debugging failed or delayed webhook deliveries
• Replaying a webhook request after changing your application code
• Delivering the same webhook to one or more configured Destinations
• Keeping a short-term history of incoming webhook requests for troubleshooting

For example, you can use an Adal Endpoint as the webhook URL in GitHub, Stripe, Slack, Telegram, Make, Zapier, or another service. When that service sends a webhook, Adal records the request and shows exactly what was received.

This is useful both during local development and in production-like workflows where webhook delivery needs to be visible, repeatable, and easier to debug.

Create an Endpoint

To create a new Endpoint, open the Adal dashboard and go to the Endpoints section. Click Create endpoint and configure how the Endpoint should receive incoming webhook requests.

Region

Choose the region where the Endpoint will receive requests.

The selected region becomes part of the Endpoint URL. For example, an Endpoint created in the se1 region will use a URL like this:

Choose the region that best matches your use case, your infrastructure, or the services that will send webhooks to this Endpoint.

Name

Enter a name for the Endpoint.

The name is only used inside the Adal dashboard. It does not affect the Endpoint URL, request processing, delivery behavior, or any external integration.

Use a name that helps you understand what the Endpoint is used for, such as:

• GitHub development
• Stripe production
• Telegram bot

Allowed methods

Select the HTTP methods this Endpoint should accept.

Adal can accept the following methods:

• DELETE
• GET
• HEAD
• OPTIONS
• PATCH
• POST
• PUT

Requests that use a method not selected for the Endpoint are rejected immediately when they arrive.

For most webhook integrations, POST is the expected method. Some services may use other methods for verification, testing, or custom workflows. Select only the methods you expect to receive.

Deliver pending requests on connect

Choose whether Adal should deliver pending stored requests when an Adal CLI client connects.

Available options:

• Enabled
• Disabled

When this option is Enabled, Adal will deliver pending stored requests to the CLI client after it connects. This is useful when your local application was offline, the CLI was disconnected, or you want stored requests to be forwarded once the connection is available again.

When this option is Disabled, Adal will only forward new incoming requests after the CLI client connects. Previously stored pending requests will remain stored and will not be automatically delivered on connect.

Notes

Use the Notes field to add any internal notes about this Endpoint.

Notes are only for your own reference. They do not affect request handling, delivery behavior, or external integrations.

You can use notes to describe where the Endpoint is configured, what service sends requests to it, or any details your team may need later.

Endpoint URL

Each Endpoint has a public URL that external services can use to send webhook requests to Adal.

You can copy the Endpoint URL from the Adal dashboard and use it as the webhook destination in services such as GitHub, Stripe, Slack, Telegram, Make, Zapier, or any other service that can send HTTP webhooks.

For example:

The Endpoint URL is permanent for as long as the Endpoint exists. This means you can configure it once in an external service and keep using the same URL without relying on temporary tunnel links or changing local development URLs.

The region is part of the Endpoint URL. In this example, se1 identifies the region that receives incoming requests:

If you create an Endpoint in another region, the regional part of the URL will be different.

You can also send requests to a custom path under the same Endpoint URL:

Query parameters are supported as well:

Adal stores the received path and query parameters together with the Request, so you can inspect them later in the dashboard.

Do not delete an Endpoint while its URL is still configured in external services. Once an Endpoint is deleted, it stops receiving requests, and external services using that URL will no longer be able to deliver webhooks to Adal.

For security reasons, deleted Endpoint subdomains are not released or reused. This prevents a previously used webhook URL from being accidentally assigned to another user in the future.

Regions

Each Endpoint belongs to a specific region.

A region defines where incoming webhook requests are received and processed by Adal. When you create an Endpoint, you choose the region that should handle requests for that Endpoint.

The selected region becomes part of the Endpoint URL. For example, an Endpoint created in the se1 region will have a URL like this:

If the Endpoint is created in another region, the regional part of the URL will be different:

Choose the region that best matches your use case. In most cases, this means choosing a region close to your infrastructure, your users, or the external services that will send webhooks to the Endpoint.

The region is selected when the Endpoint is created and cannot be changed later. If you need to use a different region, create a new Endpoint in that region and update the webhook URL in the external service.

Requests, deliveries, and Endpoint URLs are region-specific. This makes webhook routing explicit and predictable: a request sent to an Endpoint URL in one region is received by that region.

Incoming requests

When an external service sends a webhook to an Endpoint URL, Adal receives it as an incoming HTTP request.

Each incoming request that reaches an Endpoint is recorded as a separate Request in the dashboard. Accepted requests store full request details, while rejected requests store only minimal metadata and the rejection reason.

For accepted requests, Adal records the technical details of the request, including:

• HTTP method
• Path
• Query parameters
• Headers
• Body
• Request size
• Source IP address
• Received time
• Delivery status

For example, if an external service sends a request to:

Adal stores the request path, query parameters, headers, and body together with the Request. This makes it possible to debug what the external service actually sent, instead of guessing based on application logs or provider-side status messages.

An incoming request does not have to be delivered immediately to be visible in Adal. Even if your local application is offline, the CLI client is disconnected, or a Destination is temporarily unavailable, the Request can still be stored and inspected in the dashboard, as long as it is accepted by the Endpoint and does not exceed the configured limits.

Requests that do not match the Endpoint configuration, such as requests using a method that is not enabled in Allowed methods, are rejected when they arrive.

Paths and query parameters

An Endpoint can receive requests not only on its root URL, but also on custom paths under the same Endpoint URL.

For example, all of the following requests can be sent to the same Endpoint:

• https://a1b2.se1.adal.cloud
• https://a1b2.se1.adal.cloud/github/push
• https://a1b2.se1.adal.cloud/stripe/events
• https://a1b2.se1.adal.cloud/telegram/bot

Query parameters are supported as well:

Adal stores the path and query parameters together with the Request, so you can inspect them later in the dashboard.

This is useful when an external service sends webhooks to a specific path, or when you want to use the same Endpoint for several related webhook sources.

For example, you may use one Endpoint with different paths:

• https://a1b2.se1.adal.cloud/github/push
• https://a1b2.se1.adal.cloud/github/issues
• https://a1b2.se1.adal.cloud/github/releases

Adal does not hide or normalize these paths. The path received by the Endpoint is the path stored with the Request and used during delivery.

Path and query parameters do not create separate Endpoints. They are part of the incoming Request received by the same Endpoint.

Request limits

Endpoints accept incoming requests according to the limits of your current plan and the Endpoint configuration.

The most important limit is the maximum request size. In Adal, request size is calculated as the combined size of the URI, headers, and body:

If an incoming request is larger than the limit allowed by your plan, Adal rejects the request when it arrives.

Rejected requests are still shown in the Request list with the rejected status, but they are not treated as accepted webhook requests and do not enter the normal processing flow.

For rejected requests, Adal stores only minimal metadata: the request method, the received time, and the rejection reason. Headers, body, URI, and query parameters are not stored.

A request may also be rejected if it does not match the Endpoint configuration. For example, if the Endpoint is configured to accept only POST requests, an incoming GET request will be rejected immediately.

Common reasons for rejected requests include:

• The total request size is larger than the plan limit
• The HTTP method is not enabled in Allowed methods
• The Endpoint no longer exists
• The request cannot be accepted by the receiving region

When a request is accepted, Adal stores it as a Request and makes it available in the dashboard. From there, you can inspect its URI, headers, body, size, received time, delivery status, and other details.

Request size limits help keep webhook handling predictable, protect the receiving infrastructure, and make rejected requests easier to understand.

Credits

Adal uses credits to count accepted incoming requests and manual processing actions such as replay and manual retry.

One accepted incoming request uses 1 credit.

This single credit covers the full normal processing flow for that request:

For example, if an external service sends a webhook to your Endpoint and the request is accepted, Adal uses 1 credit. That credit covers receiving the request, storing it in the dashboard, and automatically delivering it to the Destinations configured for the Endpoint.

Automatic retries are included in the same credit. If a Destination is temporarily unavailable and Adal retries delivery automatically, those automatic retry attempts do not use additional credits.

Rejected requests do not use credits. If a request is rejected at the entry point, for example because it exceeds the plan size limit or uses an HTTP method that is not enabled in Allowed methods, it is not treated as an accepted request and is not billed.

Some actions use additional credits because they create a new processing action:

• Replaying a Request uses 1 credit
• Manually retrying a delivery uses 1 credit

If your account does not have enough credits, new incoming requests cannot be accepted as regular Requests until more credits are available.

Requests in an Endpoint

An Endpoint can receive many incoming requests.

Each accepted incoming HTTP request is stored as a separate Request in the Endpoint. This makes the Endpoint a stable entry point, while each Request represents one specific webhook event received by Adal.

For example, if GitHub sends three webhook events to the same Endpoint, Adal stores them as three separate Requests:

You can open each Request in the dashboard to inspect what was received and what happened after it arrived.

A Request may include details such as:

• HTTP method
• URI
• Path
• Query parameters
• Headers
• Body
• Request size
• Source IP address
• Received time
• Delivery status
• Related delivery attempts

Requests are useful for debugging because they show the exact webhook payload and metadata received by Adal. Instead of relying only on logs from the external service or your application, you can inspect the incoming request directly.

If the Endpoint has Destinations configured, each Request can also have delivery attempts. These attempts show whether Adal successfully delivered the Request to your application, CLI client, or configured HTTP destination.

Rejected requests may also appear in the Endpoint request list with the rejected status. Unlike accepted requests, they store only minimal metadata: the request method, the received time, and the rejection reason. Headers, body, URI, and query parameters are not stored for rejected requests.

You can see the rejection reason on the Request page.

Destinations

A Destination defines where Adal should deliver requests received by an Endpoint.

An Endpoint receives incoming webhook requests from external services. A Destination tells Adal where those requests should be forwarded after they are accepted and stored.

For example:

An Endpoint can have one or more Destinations, depending on your current plan limits.

Destinations can be used for different workflows, such as delivering webhooks to a local application through Adal CLI, forwarding requests to a public HTTP URL, or sending the same incoming webhook to multiple targets.

If an Endpoint has no Destinations configured, Adal can still receive and store incoming requests. You will be able to inspect those Requests in the dashboard, but Adal will not automatically deliver them anywhere.

When a Request is delivered to a Destination, Adal records the delivery result. This includes whether the delivery succeeded, failed, or is waiting for another attempt.

Destinations are configured separately from the Endpoint itself. This makes the flow explicit: the Endpoint controls what can be received, while Destinations control where accepted requests are delivered.

Delivery behavior

When an Endpoint accepts an incoming request, Adal stores it as a Request and then tries to deliver it to the configured Destinations.

The basic delivery flow looks like this:

Each configured Destination receives its own delivery attempt. This means that if an Endpoint has multiple Destinations, Adal tracks delivery to each Destination separately.

For example:

A delivery attempt records what happened when Adal tried to forward the Request. It can show whether the delivery succeeded, failed, is pending, or is waiting for another automatic retry.

If a Destination is unavailable, returns an error, or cannot receive the request at that moment, Adal can retry delivery automatically according to its retry schedule. Automatic retries are part of the normal processing flow for the original Request and do not use additional credits.

Delivery is tracked per Destination. A Request may be delivered successfully to one Destination and fail for another. This makes it possible to debug each delivery path independently instead of treating the Request as a single global success or failure.

You can inspect delivery results in the dashboard. Delivery details help you understand where the Request was sent, whether it was accepted by the target, and what happened during each delivery attempt.

If a Request needs to be sent again manually, you can use manual retry for a specific delivery. Manual retries are separate processing actions and use additional credits.

Replay

Replay lets you send a previously received Request through the Endpoint flow again.

This is useful when you want to test your application after changing code, debug webhook handling, or repeat an event without waiting for the external service to send the webhook again.

When you replay a Request, Adal creates a new Request based on the original one. The replayed Request goes through the normal processing flow:

The original Request is not modified. It remains available in the dashboard, and the replayed Request is stored separately.

Replay is available only while the original Request data required for replay is still retained.

A replayed Request keeps a reference to the original Request, so you can see where it came from. This makes it easier to distinguish original webhook events from requests created manually through Replay.

Replay uses 1 credit because it creates a new processing action. Just like a regular accepted incoming request, this credit covers storing the replayed Request and automatically delivering it to the configured Destinations.

Replay is different from manual retry. Replay creates a new Request from a previously received Request. Manual retry repeats delivery for a specific existing delivery attempt.

Security notes

Endpoint URLs are public URLs.

Anyone who knows an Endpoint URL can send HTTP requests to it, as long as the request matches the Endpoint configuration and stays within the plan limits.

Do not publish Endpoint URLs in places where they are not supposed to be used. Treat them as integration URLs that should only be shared with services, tools, and team members that need to send webhooks to that Endpoint.

Adal records incoming requests and makes webhook delivery observable, but it does not replace application-level security checks.

If an external service supports webhook signatures, you should verify those signatures in your application. This helps confirm that the request was actually sent by the expected service and was not modified before reaching your application.

You can also reduce unwanted traffic by enabling only the HTTP methods you expect in Allowed methods. Requests using disabled methods are rejected at the entry point.

For security reasons, deleted Endpoint subdomains are not released or reused. This prevents a webhook URL that was previously used by one account from being assigned to another account in the future.

When working with sensitive data, review what information external services include in webhook payloads and headers. Adal stores accepted requests so they can be inspected, replayed, and delivered according to your configuration.

Delete an Endpoint

You can delete an Endpoint from the Adal dashboard when you no longer need it.

Before deleting an Endpoint, make sure its URL is no longer used by any external service. Once the Endpoint is deleted, it stops receiving webhook requests immediately.

Any external service still configured to send webhooks to that Endpoint URL will no longer be able to deliver requests to Adal.

Deleting an Endpoint affects the whole flow connected to it:

After deletion, the Endpoint URL becomes inactive. New requests sent to that URL will not be accepted as regular Requests.

For security reasons, deleted Endpoint subdomains are not released or reused. This prevents a webhook URL that was previously used by one account from being assigned to another account in the future.

Because of this, deleting an Endpoint is not the same as temporarily disabling it. If you need to stop delivery without losing the Endpoint URL, consider removing or disabling Destinations instead of deleting the Endpoint.

Delete an Endpoint only after you have updated or removed the webhook URL in all external services that used it.

Troubleshooting

This section covers common issues you may encounter when working with Endpoints.

I sent a webhook, but I do not see it in Adal

Check that the external service is using the correct Endpoint URL.

Make sure the URL includes the correct region and Endpoint subdomain:

Also check the following:

• The Endpoint still exists
• The external service is sending the request to the correct URL
• The request method is enabled in Allowed methods
• The request size does not exceed your plan limit
• Your account has enough credits
• The receiving region is available

If the request is rejected at the entry point, it will appear with the rejected status and only minimal metadata will be stored.

The request is rejected

A request can be rejected before it enters the normal processing flow.

Common reasons include:

• The HTTP method is not enabled in Allowed methods
• The total request size exceeds your plan limit
• The Endpoint has been deleted
• Your account does not have enough credits
• The receiving region cannot accept the request

In Adal, request size is calculated as:

This means that large headers or a long URI can also cause a request to exceed the limit, even if the body itself is not large.

The Request exists, but it was not delivered

If the Request is visible in the dashboard but was not delivered, check the configured Destinations.

Possible reasons include:

• No Destinations are configured for the Endpoint
• The Destination is disabled or misconfigured
• The target application is offline
• The Adal CLI client is not connected
• The target HTTP URL is unavailable
• The target returned an error response
• The delivery is pending or waiting for an automatic retry

Open the Request in the dashboard and review its delivery details. Delivery is tracked per Destination, so one Destination may succeed while another fails.

Pending requests are not delivered when the CLI connects

Check the Endpoint setting Deliver pending requests on connect.

If this option is Enabled, Adal will deliver pending stored requests when the CLI client connects.

If this option is Disabled, Adal will only forward new incoming requests after the CLI client connects. Previously stored pending requests will remain stored and will not be delivered automatically on connect.

The external service reports a webhook delivery error

Open the corresponding Request in Adal and review the delivery status.

If the Request is not visible in Adal, the problem may be related to the Endpoint URL, allowed methods, request size, credits, or region availability.

If the Request is visible but delivery failed, the problem is likely related to the configured Destination or the target application.

I want to stop delivery but keep the Endpoint URL

Do not delete the Endpoint.

Deleting an Endpoint makes its URL inactive, and deleted Endpoint subdomains are not released or reused.

If you want to keep the Endpoint URL but stop forwarding requests, remove or disable the configured Destinations instead.

Related pages

The documentation is still growing. As you continue working with Endpoints, the following pages will be useful:

• Requests
• Destinations
• Adal CLI