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
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 OKor404 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
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-Agentvalue 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
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
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
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 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
The maximum request size depends on your current plan. You can view the applicable limits on the pricing page.
Adal calculates the size of the complete incoming request:
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
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.