Data storage and retention

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 Endpoint has a selected region and a retention period determined by your plan. Accepted request data remains stored until its individual retention period expires.

Deleting an Endpoint 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 Endpoint 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.

Endpoints

For each Endpoint, 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 an Endpoint
• Its region, determined by the associated Endpoint
• 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 Endpoint or the account.

A request may be rejected when:

• Its HTTP method is not allowed for the Endpoint
• Its total size exceeds the limit for the current plan
• The account has no available credits
• The Endpoint 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 Endpoint.

When a request is received by an Endpoint 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 an Endpoint 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:

• Endpoints in Sweden and Germany use storage restricted to Western Europe
• Endpoints 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 Endpoint.

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

Centrally stored Endpoint records

A limited set of Endpoint configuration data is stored centrally rather than in the regional request database.

This includes:

• Endpoint name
• Ingest URL
• Hashed Adal CLI token
• User-provided Endpoint notes

Central Endpoint 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 an Endpoint 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 an Endpoint

Deleting an Endpoint immediately stops it from accepting new requests.

Adal uses a soft-delete model for Endpoints. The Endpoint 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 Endpoint URL from later receiving webhook traffic intended for its previous owner.

When you delete an Endpoint:

• The Endpoint 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 Endpoint is removed from the dashboard and cannot be used for new deliveries

Stored requests are not deleted immediately when an Endpoint 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 Endpoint 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:

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 Endpoint. One account cannot access Endpoints, 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.