Adal Cloud does not grant personnel routine access to your Destination credentials or webhook payloads. We do not sell that data, and we do not make it available to third parties for advertising, analytics, profiling, or any other purpose unrelated to operating the Service.
Our systems use your data to receive, store, process, secure, and deliver webhooks as you configure. Requests are transmitted to the Destinations you designate. Data may also be processed by infrastructure and service providers acting on Adal's behalf where necessary to host, protect, store, or operate the Service. We require such processing to remain limited to the provision of those services and do not permit those providers to use customer data for their own advertising or profiling purposes.
Secrets and delivery credentials
Adal treats the entire Destination configuration as potentially sensitive — not only fields expressly labeled as secrets. A credential may appear in an authentication header, a custom header, the request body, a query parameter, or the URL path itself (for example, api.service.com/user_id:secret_token/server). Webhook payloads may likewise contain personal, financial, operational, or other confidential information.
Persistently stored Destination URLs, headers, bodies, webhook payloads, signing secrets, API keys, and other delivery values are encrypted at rest. That encryption is designed to be reversible: the delivery system must be able to recover the original values in order to send a webhook, retry a failed delivery, replay a Request, or otherwise attempt delivery.
When transient delivery is selected, the accepted Request and its Delivery state are not written to the regional database or Cloudflare R2. They are held temporarily in Redis memory for delivery. Each Destination finishes independently when a Delivery succeeds or its configured attempts are exhausted. The Request remains in memory while any Destination is unfinished, and is deleted when all Destinations finish or when its temporary retention deadline expires first.
One-way hashing is unsuitable for this purpose. A hash can be used to verify a submitted value, but it cannot reconstruct the original URL, header, credential, or payload needed to repeat a request. Accordingly, data required for the delivery workflow is kept in recoverable form while persistent storage protects it at rest, as described below.
We use these values only to provide the webhook workflow you configure. We do not use them for advertising, analytics, profiling, data enrichment, or any unrelated purpose.
Access controls
We design and operate Adal under the principle of least privilege. An authenticated user may access only the accounts, Destinations, webhook data, and delivery history that the user is authorized to use. Application-level access controls prevent one customer from viewing or managing another customer's data.
Adal employees and contractors do not receive standing access to customer data. Production administrative access is restricted to authorized operational personnel and is not provided for browsing, inspection, or other non-operational purposes.
We limit administrative and production access to the systems and permissions reasonably necessary to operate, maintain, and secure Adal. Any additional or exceptional access must be associated with a specific documented request and purpose, limited to the relevant systems and data, restricted to authorized personnel, and logged.
Ordinary support does not involve viewing webhook payloads or Destination credentials. If viewing customer data is necessary to resolve a specific support request, Adal will first obtain the user's explicit consent, limit access to the data relevant to that request, and record the access. You should not send webhook payloads, Destination URLs, tokens, signing secrets, or other credentials in support messages unless Adal specifically requests the information and you have determined that sharing it is appropriate.
Encryption
We encrypt data in transit and configure persistent storage used for sensitive service data to provide encryption at rest. Connections to our public web services use HTTPS; communication between our internal services uses gRPC over TLS; and Adal CLI connects to the platform over secure WebSockets (WSS).
Encryption in transit protects webhook data and delivery configuration as they move between clients, Adal services, and configured Destinations, and among the internal components that receive, process, and deliver webhooks.
Encryption at rest applies to persistently stored Destination configuration and webhook data, including values embedded in URL paths and query parameters as well as values sent in headers or request bodies. Depending on the storage component, this protection may be provided at the application, database, object-storage, volume, or infrastructure layer.
Stored values remain recoverable by the Service because Adal needs the original data to deliver and retry webhook requests. Access to the original values is normally performed by the automated delivery workflow. Exceptional human access is subject to the restrictions, consent requirement, and logging described above.
Logging and observability
Adal's logging and observability systems are designed to exclude the contents of customer Requests and sensitive Destination configuration. We do not intentionally write webhook payloads, headers, request bodies, credentials, or complete Destination configuration to application logs, traces, metrics, error reports, alerts, or monitoring output. Adal currently operates these systems internally rather than sending this information to an external observability provider.
Our observability focuses on the operation of the platform, not the contents of customer requests. We monitor technical signals needed to assess service health and delivery performance — such as component availability, processing duration, delivery outcomes, and error categories — without including the underlying payload or Destination secrets.
The same minimization rule applies to failed and successful requests alike. Operational records may contain limited technical identifiers, timestamps, delivery outcomes, and error categories needed to diagnose and secure the Service, but they should not contain the underlying payload or Destination credentials. An exception, timeout, or failed delivery does not by itself justify recording sensitive request content as diagnostic data.
Persistently stored Request data retained for delivery, retries, or delivery history remains part of the encrypted service data associated with the relevant account. Transient Request data remains only in the in-memory delivery workflow and is not copied into logs or observability systems. Neither mode treats Request content as log data.
Customer control
You control how Adal receives, stores, and delivers your webhooks. You choose which Servers accept incoming requests, which HTTP methods they allow, which region processes them, whether accepted Requests use persistent storage or transient delivery where that option is available, and the applicable retention period.
In persistent storage mode, you can inspect what Adal received, review its delivery history, and decide whether to retry or replay it while it remains retained. In transient delivery mode, the Request is held only until all Destination Deliveries finish or its temporary retention deadline expires, whichever occurs first; it is then deleted and is no longer available for inspection, manual retry, or Replay.
Deleting a Server immediately stops it from accepting new requests and starts deletion of its Destinations, accepted Requests, webhook content, request metadata, delivery history, replay data, and related Server configuration from active systems. This process is normally completed promptly but may take several seconds when a Server has a large number of Requests. Previously accepted data is not retained until its original retention date after the Server is deleted. The Server's ingest URL remains permanently reserved and is not assigned to another user.
For outbound delivery, you decide which Destinations receive requests, whether delivery is enabled, and which URLs, headers, credentials, and other configuration Adal uses. You may add or remove Destinations and rotate or delete their credentials at any time. Removing a Destination or its credentials prevents Adal from using that configuration for future deliveries.
If you believe a URL, token, signing secret, header value, or other credential has been compromised, you should rotate it promptly and update or remove the corresponding configuration in Adal.
Security is a shared responsibility
We protect the Adal platform, stored service data, and the delivery path. You remain responsible for securing the systems and accounts you connect to Adal, selecting appropriate retention settings, restricting access to your Adal account, and protecting Server URLs and Destination credentials from unauthorized disclosure.
Receipt of a request through an Adal Server does not, by itself, establish the authenticity or trustworthiness of the sender or the payload. You should verify webhook signatures or other authentication evidence provided by the sender before acting on a request, and your receiving application should continue to validate data it accepts from Adal.
Use strong, narrowly scoped credentials for Destinations and rotate them whenever they may have been compromised. Keep your receiving services updated, restrict their network and application permissions, and use HTTPS for public Destination URLs.
If you discover a potential security issue in Adal, please report it responsibly to [email protected].