## Choose by task {#overview}

Adal combines incoming webhook receipt, delivery directly or through CLI, and independent HTTP job submission through the API. Compare the actual data path and desired outcome; the categories below do not imply official integrations or an assessment of every individual product.

## Temporary tunnels {#temporary-tunnels}

A tunnel opens a network path to your application. Adal CLI delivers Server requests into a local environment with its own attempts and journal. If you only need network access to a local application, consider a tunnel. If you also need stored incoming requests, recipients and attempt inspection, consider Inbound with CLI.

## Webhook inspectors {#webhook-inspectors}

An inspector helps you see a sender's call. In Adal, an accepted request can be inspected and delivered to connected applications. A visible HTTP request and successful business processing are different outcomes: observability does not replace checking the handler.

## HTTP delivery infrastructure {#webhook-delivery-infrastructure}

Use Inbound when the sender calls a Server URL and recipients are configured through Channels and Routers. Use Outbound when your application submits an HTTP job through the API and selects a region. Neither flow should be treated as promising exactly-once external effects or strict global order.

## Application queues {#application-queues}

An application queue manages internal jobs and business state. Adal executes HTTP delivery and exposes results, but cannot transact together with your database. Use your own transactions, event ledger and recipient idempotency where required. Adal's limited retention does not replace archives or backups.

## Next {#related-pages}

- [Inbound quickstart](/en/docs/inbound/quickstart) — start receiving webhooks.
- [Outbound quickstart](/en/docs/outbound/quickstart) — submit an HTTP job.
- [Core concepts](/en/docs/common/concepts), [retries](/en/docs/common/retries) and [storage](/en/docs/common/storage) — check behavioral boundaries.