## Overview {#overview} Adal stores accepted webhook requests for a limited time so you can inspect them, deliver them to configured destinations, replay them, and review their delivery history. Each Server has a selected region and a retention period determined by your plan. Accepted request data remains stored until its individual retention period expires. Deleting a Server immediately stops it from receiving new requests and removes its Destinations. Previously accepted requests remain retained until their scheduled deletion dates. This page explains what Adal stores, how rejected requests are handled, how retention works, and what happens when stored data is deleted. ## What Adal stores {#what-adal-stores} Adal stores the data required to receive webhook requests, deliver them to configured destinations, provide request history, and maintain account access. ### Webhook requests For each accepted request, Adal stores: - The full request URI, including its path and query string - Request headers - Request body - The sender IP address - The date and time when the request was received - The Server that received the request - Delivery attempts and their results, including the returned status or error, such as `200 OK` or `404 Not Found` Adal does not store the HTTP version separately. The User-Agent header is stored as part of the request headers. Adal does not store response headers or response bodies returned by a Destination. It also does not separately store TLS or proxy IP information. ### Servers For each Server, Adal stores: - Its selected region - Its name - Its ingest URL - The HTTP methods it accepts - User-provided notes - A hash of its Adal CLI token Adal does not store the original CLI token. When a CLI client connects, the provided token is hashed and compared with the stored hash. ### Destinations For each Destination, Adal stores: - Its connection to a Server - Its region, determined by the associated Server - Its delivery type: Direct HTTP delivery or delivery through Adal CLI - The destination URL provided by the user - The configured maximum number of retry attempts - The delivery interval - User-provided notes ### Account information For each account, Adal stores: - The registration date - The email address - The name provided by the user - A hash of the password, when the account uses email and password authentication When an account is created through Google or GitHub, Adal stores the identity provider and the account data provided by that provider. ### Authentication and sessions Adal stores refresh tokens in encrypted form to maintain signed-in sessions. Access tokens are temporary and expire after five minutes. They are used to authorize access to account data and are not stored as long-lived session credentials. ## What Adal does not store {#what-adal-does-not-store} Adal does not store certain data that is not required to receive, deliver, and inspect webhook requests. Adal does not store: - Passwords in their original form - Adal CLI tokens in their original form - HTTP versions as a separate request field - Response headers or response bodies returned by Destinations - TLS connection details - Proxy IP addresses as separate metadata - The `User-Agent` value as a separate field, because it remains part of the stored request headers For rejected requests, Adal does not store the request URI, headers, body, or sender IP address. It stores only the time of rejection, the HTTP method, and the rejection reason. Adal does not receive or store full payment card details. Payment processing is handled by the payment provider. ## Rejected requests {#rejected-requests} Adal rejects an incoming request when it does not meet the configured requirements for the Server or the account. A request may be rejected when: - Its HTTP method is not allowed for the Server - Its total size exceeds the limit for the current plan - The account has no available credits - The Server has been deleted or is no longer available - The request cannot be processed because of a validation or service error For rejected requests, Adal stores only the minimum information required for troubleshooting: - The date and time of the rejection - The HTTP method - The rejection reason Adal does not store the request URI, headers, body, sender IP address, or delivery data for rejected requests. Rejected requests are not delivered to Destinations, cannot be replayed, and do not consume credits. ## Where data is stored {#where-data-is-stored} Adal stores request data in the region selected for the Server. When a request is received by a Server in a specific region, its request metadata and delivery data remain in that region. Request bodies are stored in object storage restricted to the jurisdiction assigned to that region. For example, metadata for a request received by a Server in `se1` remains in Sweden, while its request body is stored in object storage restricted to Western Europe. ### Request bodies Request bodies are stored in Cloudflare R2 object storage. Adal uses separate R2 buckets for each region: - Servers in Sweden and Germany use storage restricted to Western Europe - Servers in Kazakhstan use storage restricted to Asia Pacific Each regional bucket has separate access credentials. Services can access only the bucket assigned to their region. ### Request metadata and delivery data Request metadata is stored in Adal-managed databases located in the same region as the Server. This includes: - Request URI, headers, sender IP address, and received time - Request status and retention information - Delivery attempts, delivery status, and delivery errors - Regional Destination records and their configuration Destination data is stored only in the region of the associated Server. ### Centrally stored Server records A limited set of Server configuration data is stored centrally rather than in the regional request database. This includes: - Server name - Ingest URL - Hashed Adal CLI token - User-provided Server notes Central Server records do not include request bodies, request URIs, request headers, sender IP addresses, delivery history, or Destination records. ### Usage statistics Adal collects limited usage statistics centrally to calculate service usage and display account-level statistics. These records do not include request bodies, request URIs, request headers, sender IP addresses, Destination IDs, or Destination configuration. For example, Adal may record that a Server used one credit for an incoming request at a particular time, or that a region used a total number of credits during a reporting period. ## Retention period {#retention-period} Adal stores accepted request data for a limited period determined by your current plan. The retention period starts when Adal accepts the request. Each request has its own scheduled deletion date. You can view this date in the request details in the Adal dashboard. When the retention period ends, Adal permanently deletes the request and its associated stored data. This includes the request body, URI, headers, sender IP address, delivery history, and delivery attempt records. Requests whose retention period has expired cannot be restored, replayed, or delivered again. ## Deleting a Server {#deleting-a-server} Deleting a Server immediately stops it from accepting new requests. Adal uses a soft-delete model for Servers. The Server is removed from your dashboard and cannot be used, but its ingest URL remains permanently reserved and is never assigned to another account. This prevents a deleted Server URL from later receiving webhook traffic intended for its previous owner. When you delete a Server: - The Server stops accepting new requests - All associated Destinations are permanently deleted - Pending deliveries are cancelled - Delivery attempts and other Destination-related delivery data are permanently deleted - The Server is removed from the dashboard and cannot be used for new deliveries Stored requests are not deleted immediately when a Server is deleted. They remain stored until their individual retention periods expire. While retained request data is still available, Adal Support may be able to restore a deleted Server on request. Restoration is only possible before the retained requests expire and does not restore deleted Destinations, delivery attempts, or other permanently deleted delivery data. After the retention period ends, the remaining request data is permanently deleted and cannot be restored. ## Request size limits {#request-size-limits} The maximum request size depends on your current plan. You can view the applicable limits on the [pricing page](/pricing). Adal calculates the size of the complete incoming request: ```text request size = URI size + headers size + body size ``` The limit applies to the entire request, not only to its body. When an incoming request exceeds the size limit of your plan, Adal rejects it before storing any request content. The rejected request is not delivered to Destinations and does not consume credits. After you upgrade your plan, the larger request size limit applies to requests received after the upgrade. Previously rejected requests are not stored or restored automatically. ## Security and access {#security-and-access} Adal protects access to account data and stored request content through account authentication, short-lived access credentials, encrypted connections, and regional storage isolation. ### Account access Each Adal account is associated with a verified email address. Users who register with email and password must confirm their email address before they can sign in and access the dashboard. Accounts created through Google or GitHub use the identity information provided by the selected provider. Stored request data is available only through the Adal account that owns the associated Server. One account cannot access Servers, requests, Destinations, or delivery data belonging to another account. ### Credentials and sessions Adal does not store passwords or Adal CLI tokens in their original form. - Account passwords are stored as hashes - Adal CLI tokens are stored as hashes and are verified by comparing hashes - Refresh tokens are stored in encrypted form - Access tokens are temporary and expire after five minutes ### Encrypted connections All connections to Adal use encryption in transit: - The dashboard and API use HTTPS - Adal CLI connections use WSS or gRPC with TLS, depending on the connection type - Internal service communication uses TLS where applicable ### Request content and logs Adal keeps operational logging intentionally minimal. Request bodies, request headers, request URIs, sender IP addresses, and other request content are not written to ordinary application logs. Logs are limited to operational and critical error information required to investigate service failures. ### Regional storage access Request bodies are stored in separate regional storage buckets. Each region uses separate credentials that are restricted to the storage assigned to that region. Regional services do not use shared storage credentials that provide access to request bodies from every region. ### Service operator access Adal does not provide an internal administrator dashboard for browsing customer request data. The service operator may have direct infrastructure access when it is necessary to maintain, secure, or troubleshoot the service. Such access is not available to other Adal users and is not used for advertising, profiling, or unrelated purposes. Two-factor authentication is not currently available for Adal accounts.