Data storage and retention

Overview

Adal supports two modes for accepted webhook requests: persistent storage and transient delivery.

With persistent storage, Request metadata and Delivery data are written to the regional database, and the body is written to regional Cloudflare R2 object storage. The Request remains available for inspection, manual retry, Replay, and other supported interactions until its retention period expires or the Server is deleted earlier.

With transient delivery, the Request is not written to the database or R2. Adal holds it only in Redis memory while delivering it to the Server's Destinations, then deletes it according to the lifecycle described below.

Deleting a Server immediately stops it from receiving new requests and starts deletion of its Destinations, accepted requests, stored request content, request metadata, and delivery history. Deletion normally completes promptly but may take several seconds when the Server has a large number of requests. The data is not retained until its previously scheduled deletion date.

This page explains both modes, how rejected requests are handled, how retention works, and what happens when data is deleted.

What Adal stores

The Request data stored by Adal depends on the Server's storage mode. Account, Server, and Destination configuration is stored separately from accepted Request data.

Webhook requests

In persistent storage mode, Adal stores the following for each accepted Request:

• 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.

In transient delivery mode, the same incoming data may be held temporarily in memory to perform Deliveries, but it is not written to the database or R2 and is not retained as Request history. Adal does not store response headers or response bodies returned by a Destination in either mode. 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-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

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 processes Request data in the region selected for the Server.

In persistent storage mode, 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

Persistently stored 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

In persistent storage mode, 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.

Transient delivery in Redis

In transient delivery mode, Adal does not write the accepted Request or its Delivery state to the regional database or Cloudflare R2. The complete Request is held temporarily in Redis memory in the Server's region only while it is needed for automatic delivery and retries.

Adal tracks the work for each Destination independently. Delivery work for a Destination finishes when that Destination returns a successful 2xx response or when its configured attempts are exhausted. If Destination A succeeds while Destination B still has a pending attempt or retry, the Request remains in memory for Destination B.

Adal deletes the complete transient Request and its temporary Delivery state when every Destination has finished, or earlier when the Request's temporary retention deadline expires. If that deadline expires first, remaining pending Deliveries and retries stop. After deletion, the Request cannot be inspected, manually retried, replayed, restored, or otherwise used through Adal.

Transient Request data is not written to backups or ordinary application logs. Limited account-level usage, billing, security, and abuse-prevention records may still be kept, but they do not contain the Request URI, headers, body, sender IP address, Destination configuration, or Delivery history.

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

In persistent storage mode, Adal stores accepted Request data for a limited period determined by your current plan and Server configuration.

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 attempt records.

Requests whose retention period has expired cannot be restored, replayed, or delivered again.

In transient delivery mode, the retention setting is an upper limit on the in-memory delivery lifecycle, not a promise that the Request will remain for that whole period. Adal deletes it earlier as soon as all Destination Deliveries have succeeded or exhausted their attempts.

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

• Previously accepted requests and their stored content are permanently deleted

• Request metadata, delivery attempts, delivery history, and Replay data are permanently deleted

• The Server is removed from the dashboard and cannot be used for new deliveries

Deletion normally completes promptly but may take several seconds when the Server has a large number of requests. While deletion is in progress, the Server remains inactive and its data cannot be inspected, delivered, retried, or replayed through the Service.

Deleting a Server overrides the scheduled retention dates of its requests. Adal does not continue retaining those requests until the end of their original retention periods.

A deleted Server and its data cannot be restored. Its ingest URL remains permanently reserved and is not assigned to another account.

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:

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 Request content through account authentication, short-lived access credentials, encrypted connections, regional isolation, and encryption at rest for persistently stored sensitive data.

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.