Platform overview
One accountable path from a consumer's request to your record of it.
revoq is built around a single idea: every claim your company makes about an opt-out should be traceable to something that was actually written down at the time.
Lifecycle
The four stages, and what each one records
Receive
Configured per website, brand, and channel.
Each website has its own opt-out experience, allowed scopes, disclosure text, and embed rules. The version of the form and disclosure shown to the consumer is captured with the request.
Verify
Possession of the phone number, by one-time code.
revoq requests a code for the number the consumer entered and accepts the submission only after the code checks out. Attempts, resend limits, and expiry are enforced server-side.
Deliver
Sent from revoq's servers to your destinations.
Verified requests are queued to every connection that covers that website and channel, sent with your field mapping, and retried with increasing spacing when a destination fails.
Document
Append-only history, readable by a reviewer.
Request evidence, event timeline, delivery attempts with sanitized responses, and the configuration revision that was in effect for each attempt.
Evidence first
What gets written down, and what cannot be quietly rewritten
Revocation records and delivery history are append-only in the database. Corrections are recorded as new entries rather than edits to the original.
- Request evidence
- Reference number, masked phone number, selected scope, verification method and provider, verification and submission times, and the source of the request.
- Event timeline
- Each meaningful step recorded as its own event: code verified, request submitted, delivery queued, attempt result, exception resolved.
- Delivery attempts
- Destination, attempt number, HTTP status, sanitized response body, which response rule matched, latency, and the next retry time.
- Change controls
- Connection changes are versioned. A material change pauses the connection and requires a fresh passing test before it can go live again.
- Administrative audit history
- Who changed configuration, when, and — for cross-organization access by revoq staff — that the access happened at all.
Capabilities available today
What you can run right now
Hosted and embedded experiences
Phone possession verification
Reference-number receipt
Organization, website, brand, channel setup
Custom suppression API connections
Signed developer webhooks
Guided setup from documentation
Sealed credentials
Server-side destination testing
Deterministic response rules
Retries and attempt history
Role-based access
- Planned, not available today: pre-built native connectors for additional marketing platforms, scheduled file-based exchange, self-service exports by email, a public developer portal, and a public status page.
- Not part of revoq: a cross-company consumer directory, opt-back-in handling, identity verification, and any certification of your compliance posture.
Status vocabulary
Every delivery state, defined
These are the exact words used in the console, in exports, and in this documentation.
- Queued
- The verified request is waiting for its turn at a configured destination.
- Delivery attempted
- revoq built and sent the request from its own servers.
- Response received
- The destination replied, and the reply is recorded in sanitized form.
- Accepted under the configured response rule
- The reply matched the success rule set up for that destination. It is not a legal acknowledgment by the destination.
- Inconclusive
- A reply arrived but did not match the configured success or failure rule.
- Failed
- The destination reported an error, timed out, or was unreachable.
- Blocked
- revoq refused to send — for example a prohibited network target or a paused connection.
- Awaiting resolution
- An exception is open and a person still needs to close it out.