## Where Direct executes {#overview}

Direct delivers an **incoming** request to a connected Endpoint from its receipt region. Neither a browser computer nor CLI is needed for execution. This is not an independent Outbound API submission.

## Prepare a recipient {#recipient}

Use a test HTTPS handler under your control, reachable from the region. Direct cannot use `localhost`, a private IP or a service address. Validation occurs at configuration and actual connection time; a name resolving to an internal address does not bypass it.

The handler must accept the resulting path after appending the incoming path to the base URL. For example, base `https://receiver.example/adal` and incoming `/demo` require `/adal/demo`. The `.example` address is illustrative: replace it with your own test URL. Query parameters in the base URL are forbidden.

## Connect delivery {#setup}

1. Create a [Server](/en/docs/inbound/servers) in the intended region.
2. Create a [Channel](/en/docs/inbound/destinations) of type **Direct**.
3. Add an Endpoint with your test URL, keep **Enabled** on and choose **Save endpoints**.
4. Create an enabled [Router](/en/docs/inbound/routers) connecting the Server and Channel.
5. Ensure that the test handler returns `2xx`.

## Send a new test {#verify}

Copy the full Server URL from its details and set `ADAL_SERVER_URL` without a trailing slash. In Bash:

```bash
curl --silent --show-error --include \
  --request POST "$ADAL_SERVER_URL/demo?source=docs" \
  --header 'Content-Type: application/json' \
  --data-binary '{"event":"docs.direct","value":1}'
```

This JSON is demonstration data. A Server response does not prove delivery: open **Inbound → Requests**, find the request and open the Channel under **Deliveries**. Check Endpoint HTTP success and receipt of `docs.direct` at your handler.

![Successful Inbound request delivered through a demonstration Direct Channel](/images/docs/inbound/request-success-en.jpg)

*Test Direct delivery shown in the Inbound request card. Open the Channel from Deliveries to inspect individual HTTP attempts, and verify event receipt at your handler. English interface.* [Open full-size screenshot](/images/docs/inbound/request-success-en.jpg).

## Check failure {#failure}

For the test recipient only, temporarily return `503` and send a **new** demonstration event. Inspect its failure and subsequent attempts. Restore `2xx`, wait for a due attempt under the schedule and reopen the report. Refreshing a page does not trigger an immediate retry.

## Recipient HTTP call {#http}

Method, body, path and query follow delivery rules. Transport headers, Host and Content-Length are formed for a new connection; the client adds its service headers as well. Direct does not automatically follow HTTP redirects: configure the final handler URL, not a redirecting page.

If Endpoint idempotency is enabled, `Idempotency-Key` contains the accepted request identifier. The recipient must implement its own duplicate-effect protection.

## Configuration changes {#changes}

A new Endpoint does not receive the entire history preceding its connection. Resuming existing work and adding a new recipient are different cases. The history shows the recipient URL used for that delivery; editing a Channel does not rewrite history. Disabling a route does not guarantee cancellation of an HTTP call already started.

## Troubleshooting {#troubleshooting}

Check the full path, reachability from the region, HTTPS certificate, final HTTP status and absence of redirects. Use [CLI](/en/docs/inbound/adal-cli) for a local service. See [retry rules](/en/docs/common/retries) for scheduling and attempt limits, and [Storage](/en/docs/common/storage) for data availability.