## Overview {#overview}

A **Request** is one HTTP request received by an Adal Server. Every accepted webhook becomes a separate Request that you can inspect in the [Requests dashboard](https://dashboard.adal.cloud/requests) and trace through its configured Destinations.

```text
External service → Adal Server → Request → Deliveries → Destinations
```

Adal preserves the received HTTP method, URI, path, query string, headers, and body without silently transforming the content. A Request describes what the Server received; a **Delivery** tracks sending that Request to one Destination. One Request can have several independent Deliveries with different outcomes.

> **Important:** A Request confirms that Adal accepted the webhook. A successful Delivery confirms that Adal received the expected HTTP response from the Destination. Neither proves that the Destination completed its downstream business operation.

## Request lifecycle {#lifecycle}

1. An external service sends an HTTP request to a Server URL.
2. The Server checks the method, total size, available credits, and other acceptance rules.
3. Every accepted webhook becomes a Request in the Server's region and uses one credit under the current billing model.
4. Adal creates an independent Delivery for every configured Destination.
5. Adal records each attempt and may schedule an automatic retry according to the Destination configuration.
6. Retained Request data and history remain available until the scheduled deletion date.

```text
Server
└── Request #1
    ├── Delivery → Destination A → 2xx
    ├── Delivery → Destination B → Waiting for CLI
    └── Delivery → Destination C → Retry scheduled
```

A Server with no Destinations can still accept Requests for inspection when its storage configuration retains them, but no automatic Deliveries are created. A rejected request does not enter this lifecycle: it has no Deliveries and only minimal troubleshooting data is retained.

## Request data {#request-data}

For an accepted Request retained by the selected configuration, Adal stores the data required for inspection and delivery:

- HTTP method;
- full URI, path, and query string;
- headers and body;
- individual URI, header, and body sizes, plus the total size;
- sender IP address;
- received time and scheduled deletion date;
- the Server and region that received the Request;
- Request status and related Deliveries;
- technical identifiers used to relate the records.

The total size checked against the applicable limit is:

```text
request size = URI size + headers size + body size
```

The HTTP version is not stored as a separate Request field. A supplied `User-Agent` remains available as a header. The overview also surfaces `Content-Type`, but this value only describes the format declared by the sender; it does not prove that the body is valid JSON, XML, form data, text, or any other declared format.

Adal does not enrich a Request with business data or repair malformed content. Validate the format and meaning in the Destination application.

## Accepted and rejected Requests {#accepted-and-rejected}

An accepted Request passes the Server and account checks. Adal can retain the full Request according to the selected storage configuration, uses one credit, and creates Deliveries for the Server's current Destinations.

The aggregate Request status is derived from all related Deliveries:

| Status | Meaning |
| --- | --- |
| `received` | The Request was accepted by a Server with no Destinations. |
| `delivering` | At least one Delivery has not reached a final outcome. |
| `success` | Every Delivery completed successfully. |
| `partial` | Some Deliveries succeeded while others exhausted their retries and failed. |
| `failed` | Every Delivery exhausted its retries and failed. |
| `rejected` | The incoming request failed acceptance rules and was not delivered. |

A request can be rejected because its method is disabled, its total size exceeds the current limit, the HTTP message is malformed, an account limit has been reached, credits are unavailable, or the receiving infrastructure cannot accept it.

For a rejected Request, Adal retains only minimal troubleshooting information, including the method, received time, rejection reason, and necessary technical identifiers or calculated counters. It does **not** retain the URI, path, query string, headers, body, declared content type, sender IP address, or Delivery data.

Rejected Requests have no Deliveries, cannot be replayed, do not use credits, and their discarded content cannot be recovered later.

## Inspect a Request {#inspect-request}

Open [Requests](https://dashboard.adal.cloud/requests) and select a record. The page separates the received HTTP data, Request state, and technical identifiers.

| Panel | Contents |
| --- | --- |
| Request overview | URI, method, path, timestamps, Server, sender address, status, content type, sizes, and rejection reasons where available. |
| Query parameters | Parsed query parameters and their count, or an empty state. |
| Headers | Received header names and values, plus their count. |
| Body | Stored body, declared content type, preview where supported, and download action. |
| Delivery summary | Related Deliveries and their aggregate result, or an empty state. |
| Technical metadata | Request and Server identifiers, region information, and received time. |

**Full URI** includes the path and query string, while **Path** shows only the path. Values after `?` are also parsed into the Query parameters panel. URI, header, and body sizes are displayed separately; **Total size** is their sum.

The header, query, and body panels preserve the received values. JSON can be formatted for preview, while large, binary, or unsupported body formats can be downloaded for inspection.

> **Sensitive data:** Headers, paths, query parameters, and bodies can contain tokens, signatures, personal data, and other secrets. Do not copy a complete Request into ordinary logs, analytics, error reports, public issues, or support messages.

## Deliveries and attempt history {#delivery-details}

The Delivery summary lists every Delivery related to the Request. If no Delivery was created, the page shows an empty state; this is expected when the Server has no Destinations or when the request was rejected.

Each Delivery is tracked independently. The Request remains `delivering` while at least one route is still active. When every route reaches a final result, the aggregate status 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 according to the Destination configuration.

Delivery details can include:

- current status and creation time;
- current or final attempt number;
- response status or recorded error;
- duration and time elapsed since the Request was received;
- the original Request and Destination;
- delivery URL and method;
- attempt timestamps and results.

Adal does not store Destination response headers or response bodies. Use the result, timing, and recorded diagnostic information together with the Destination application's own logs.

A manual retry sends the existing Request to one selected Destination again. It does not create a new Request or affect the other routes. Under the current billing model, manual retry uses one additional credit; automatic retries do not.

## Replay a Request {#replay}

Replay creates a new Request from a retained Request and sends it through the Server's current flow again.

```text
Original Request → Replay → New Request → New Deliveries → Current Destinations
```

- 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 attempt history;
- replay uses one credit under the current billing model;
- replay is available only while the required source data is still retained.

| Action | What it creates | Scope |
| --- | --- | --- |
| Automatic retry | Another attempt for an existing Delivery. | One Destination. |
| Manual retry | Another Delivery action for the existing Request. | One selected Destination. |
| Replay | A new Request and new Deliveries. | The Server's current Destinations. |

Replay can repeat an irreversible side effect. Assess the impact and confirm every affected handler is safe to run again before starting it.

## Duplicates and idempotency {#duplicates-and-idempotency}

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

A Destination can be configured to receive an Adal idempotency header:

```http
X-Adal-Idempotency: <request-key>
```

Deliveries and retries for the same Request use the same Adal key. Replay creates a new Request with a new key, so this header alone cannot detect the same provider event across replays.

Destination handlers should:

- verify the sender's signature and validate all input;
- be idempotent;
- use a stable provider event ID for deduplication when available;
- store the event ID atomically with the business operation;
- return `2xx` only after accepting responsibility for processing.

## Retention and deletion {#retention}

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

When retention expires, Adal permanently deletes the retained Request content and related Delivery data. The Request can no longer be inspected, restored, manually retried, or replayed.

Deleting a Server stops new intake and deletes its Destinations. Previously accepted Requests can remain until their individual scheduled deletion dates; deleting the Server does not turn Adal into permanent storage for those records.

> **Important:** Use your own databases, application logs, backups, and recovery systems for long-term business data. Adal Request retention is temporary and plan-dependent.

## Request security {#security}

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

- verify webhook signatures according to the provider's current documentation;
- enable only expected HTTP methods on the Server;
- validate structure, types, sizes, content type, and allowed values;
- do not treat headers or sender IP address alone as proof of authenticity;
- make processing idempotent and handle duplicate events;
- protect Server URLs, dashboard access, tokens, and Destination credentials;
- choose an appropriate region and retention period;
- keep complete Request data out of ordinary logs, analytics, alerts, and error reports.

Some signature schemes require the exact raw body. When a provider requires that, verify the signature against the original bytes before parsing or reserializing the payload.

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

## Troubleshooting {#troubleshooting}

**The Request does not appear in the dashboard**

Check the complete Server URL, sender delivery log, Server existence, allowed method, total size, credits, and regional availability. Also look for a rejected record.

**The Request was rejected**

Open the record and inspect its reason. Compare the method with the Server configuration and remember that total size includes URI and headers as well as the body. Fix the cause and ask the provider to send the event again; discarded content is unavailable.

**The Request was accepted but has no Delivery**

Confirm that the Server has a Destination. Inspect each route independently: a direct HTTP target can be unavailable, while an Adal CLI route can be waiting for a connection.

**The body is not what you expected**

Compare `Content-Type`, the stored body, character encoding, and the provider documentation. 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 Adal received the expected HTTP response. Inspect the Destination application's state and logs; its internal transaction, queue, or later processing can still fail.

**The event was processed twice**

Review automatic retries, manual retries, and replay. Deduplicate using a stable provider event ID. The Adal idempotency key can identify repeated Delivery of one Request but changes when replay creates a new Request.

## Related pages {#related-pages}

- [Servers](/docs/servers)
- [Core concepts](/docs/concepts)
- [Destinations](/docs/destinations)
- [Delivery retries](/docs/retries)
- [Data storage and retention](/docs/storage)
- [Adal CLI](/docs/adal-cli)