Requests in Adal

Overview

A Request is a single HTTP request received at a public Adal Server URL. Every accepted webhook becomes its own Request, which you can inspect in the dashboard and trace through its configured Destinations.

Adal preserves the HTTP method, URI, headers, and body it receives without silently transforming the content. You can see what the sender actually sent and deliver that same request to a local or remote application.

Requests and Deliveries are separate records. A Request describes what the Server received; a Delivery tracks sending that stored Request to one Destination. A single Request can have several independent Deliveries with different outcomes.

Request lifecycle

1. An external service sends an HTTP request to an Adal Server URL.
2. The Server checks the method, total size, available credits, and other acceptance rules.
3. An accepted Request is stored in the selected region and uses 1 credit.
4. Adal creates an independent Delivery for every configured Destination.
5. Adal records each attempt and schedules an automatic retry when required.
6. The Request and its history remain available until the Request's deletion date.

A Server with no Destinations can still accept and store Requests, but no automatic Delivery is created.

A rejected request does not enter the normal lifecycle: Adal retains only limited diagnostic metadata and creates no Deliveries.

Request data

For every accepted Request, Adal stores the data required for inspection, delivery, and troubleshooting:

• the HTTP method;
• the full URI, path, and query parameters;
• request headers and body;
• individual URI, header, and body sizes, plus the total size;
• the sender's remote IP address;
• the date and time received;
• the scheduled deletion date;
• the Server that received the Request;
• the Request status and any rejection reasons;
• a summary of related Deliveries;
• Request and Server IDs, the region key, and the region's geographic location.

The total Request size is calculated as follows:

The HTTP version is not stored as a separate field. If supplied, User-Agent remains available as a request header.

The Request overview also surfaces Content-Type, so you can see the sender-declared body format without searching the header table.

Body content and format

The body may contain JSON, form data, XML, plain text, binary content, or another format. Content-Type reports the format declared by the sender; it does not prove that the body is valid for that format. Validate input in the destination application.

Adal does not enrich the Request with business data or repair malformed content. The stored method, URI, headers, and body remain the source of truth for the HTTP request Adal received.

Accepted and rejected requests

Accepted Requests

An accepted Request passes the Server and account checks. Adal stores the full Request, uses 1 credit, and creates Deliveries for the Server's configured Destinations.

Acceptance and delivery are separate stages, but the overall Request status is derived from the combined state of all related Deliveries.

Request statuses

Rejected requests

A request can be rejected before its full content is stored. Reject reasons may contain any of the following:

• Method not allowed — the HTTP method is not enabled for the Server;
• Payload too large — the Request exceeds the applicable size limit;
• Bad request — the incoming HTTP request is malformed;
• Max requests reached — the Request count limit has been reached;
• Out of credits — the account does not have enough credits.

Adal retains a limited rejection record for troubleshooting. The page shows the method, time received, related Server, rejected status, rejection reason, calculated sizes, deletion date, Request and Server IDs, and region metadata.

The full URI, query parameters, headers, body, Content-Type, and remote IP address are not retained. Their fields and panels appear empty. Size counters calculated during validation do not make the discarded content recoverable.

Rejected requests are not delivered, cannot be replayed, and do not use credits. Their Delivery summary contains no Deliveries, and the discarded content cannot be recovered later.

Inspect a Request

Open Requests in the Adal dashboard and select a record. The page separates the incoming HTTP data, Request state, and technical identifiers so each can be inspected independently.

Request overview

Full URI contains the path and query string, while Path shows the path on its own. Values after ? are also parsed into the separate Query parameters panel.

Status summarizes the Request and all of its Deliveries. For example, success means every Destination succeeded, while partial means the Request has both successful and permanently failed Deliveries. Reject reasons explains a rejection; a dash is shown when no rejection reason applies.

URI, header, and body sizes are shown separately. Total size is their sum and is the value checked against the Request size limit.

Query parameters, headers, and body

The query parameter and header tables preserve the received names and values. Each panel shows an item count and a clear empty state when there is nothing to display.

The Body panel shows the stored content and its declared Content-Type. JSON may be rendered immediately with formatting and syntax highlighting, or after you select Preview. Use the download action to retrieve the body as a separate file, which is particularly useful for large or non-text payloads.

Deliveries and attempt history

Delivery summary lists the Deliveries related to the Request and shows their combined result, such as 1 of 1 succeeded. If none were created, the page shows No deliveries yet. This is expected when, for example, the Server has no Destinations.

Each summary card links to the Delivery details and shows its timestamp, status, HTTP response code, delivery type, attempt number, duration, elapsed time since receipt, and any error.

Deliveries are tracked independently, while Status in Request overview combines their states. The Request remains delivering while at least one Delivery is still in progress. Once all routes finish, it becomes success , partial , or failed .

Any 2xx response is a successful Delivery. 4xx and 5xx responses, timeouts, and network errors are failures and may trigger an automatic retry.

Delivery details

Select a Delivery in the summary to open its details page. Delivery overview shows:

• the status and creation time;
• the current or final attempt number;
• the error message, if any;
• the delivery duration and time elapsed since the Request was received;
• a link to the original Request and its received time;
• a link to the Destination, the delivery URL, and delivery type.

Delivery history lists the time, attempt number, URL used, and result. Use it to match an outcome to the exact attempt and target URL.

Adal does not store Destination response headers or bodies. The result, timing, and diagnostic details remain available.

Manual delivery retry

A manual retry sends the existing Request to one selected Destination again. It does not create a new Request or affect other routes, and it uses 1 credit. Automatic retries use no additional credits.

Replay a Request

Replay creates a new Request from a stored one and sends it through the normal Server flow again. Use it after changing application code, updating routes, or resolving a Destination outage.

• the original Request is not modified;
• the new Request is stored separately and references the original;
• Adal uses the Destinations configured for the Server at replay time;
• the new Request receives its own Deliveries and history;
• the operation uses 1 credit;
• Replay is available only while the required source data is still retained.

Replay can repeat an irreversible side effect. Before using it, assess the impact and make sure every Destination can recognize duplicate events.

Duplicates and idempotency

Automatic and manual retries can deliver the same Request more than once. Replay creates a new Adal Request, but it may still represent the same external event. Adal does not provide exactly-once delivery.

A Destination can be configured to receive this header:

Every Delivery and retry for the same Request uses the same key. Replay creates a new Request with a new key. If the webhook provider supplies a stable event ID, use that ID to detect the same event across replays.

• verify the sender signature and validate all input;
• make the webhook handler idempotent;
• store the event ID atomically with the business operation;
• return 2xx only after accepting responsibility for processing.

Retention and deletion

Accepted Requests are retained for a limited period determined by the plan and Server configuration. Retention starts when the Request is accepted, and the Request details show its scheduled deletion date.

When retention expires, Adal permanently deletes the URI, headers, body, sender IP address, Delivery history, and attempt records. The Request can no longer be restored, retried, or replayed.

Deleting a Server immediately stops intake, removes its Destinations, cancels pending Deliveries, and removes related Delivery data. Previously accepted Requests may remain until their scheduled deletion dates, but the deleted Server cannot create new Deliveries.

Request security

Anyone who knows a public Server URL can send requests to it. A Request record—and even a successful Delivery—does not prove that the sender is authentic or the content is safe.

• verify webhook signatures according to the provider's documentation;
• enable only the HTTP methods you expect;
• validate input structure, types, sizes, and allowed values;
• do not treat headers or the sender IP address as sufficient proof of authenticity;
• protect the Server URL and dashboard access;
• choose an appropriate region and retention period;
• do not put secrets or webhook content in ordinary logs or analytics.

Some signature schemes use the exact raw body. Do not parse or reserialize JSON before verification when the provider requires the original bytes.

Adal encrypts sensitive Request data at rest and uses secure connections in transit, but it does not replace sender authentication, authorization, or input validation in your application.

Troubleshooting

The Request does not appear in the dashboard

Check the complete Server URL, including its region and subdomain, and review the sender's delivery log. Confirm that the Server exists, the method is allowed, the Request is within the size limit, the account has credits, and the region is available.

The request was rejected

Open the record and review Reject reasons. Compare the method with the Server configuration, and remember that total size includes the URI and headers as well as the body. The discarded content is unavailable; fix the cause and send the event again.

The Request was accepted but has no Delivery

Check the Server's Destinations and the relevant delivery route. A Direct HTTP target may be unavailable or return an error, while an Adal CLI Delivery may be waiting for a connection. The outcome of another Destination does not determine this route.

The body is not what you expected

Compare Content-Type , the stored body, and the sender's documentation. Account for character encoding, form data, binary content, and empty bodies. Adal preserves what it receives; it does not guarantee that the sender produced valid content for the declared format.

Adal shows success, but the operation did not happen

A 2xx result means that Adal received the expected HTTP response. Check the destination application's logs and state: its internal processing, queue, or transaction may have failed later.

The event was processed twice

Review automatic and manual retries and check whether the Request was created by Replay. Deduplicate on a stable provider event ID; for retries of the same Request, you can also use X-Adal-Idempotency .

Related pages

• Servers — ingest URLs, allowed methods, regions, limits, and credits.
• Destinations — Direct HTTP, Adal CLI, Delivery history, and manual actions.
• Delivery retries — scheduling, outcomes, duplicates, and idempotency.
• Data storage and retention — regions, retention, rejected requests, and deletion.
• Adal CLI — delivery to local and private applications.