Delivery connections
Send verified requests to the systems you already run.
revoq does not ask you to replace your suppression tooling. It delivers each verified request to the endpoints you configure, applies your field mapping, and records exactly what came back.
Two connection types available today
How revoq reaches your systems
Custom suppression API
Signed developer webhook
- One connection can cover every website or a specific set of websites and channels.
- Multiple connections can receive the same request, each with its own attempt history.
- Requests are always sent from revoq's servers, so the destination sees one predictable origin.
Boberdoo is also available as a native connection with the request shape already built: see the Boberdoo suppression integration.
Setup
Guided setup, then a real test before anything goes live
Describe the destination — name it and provide the address revoq should call.
Paste the destination's API documentation if you have it. revoq proposes the request shape and fields, and you confirm or correct them.
Enter the credential. It is encrypted before storage and never displayed back in full.
Map fields: which parameter carries the phone number, in which format, alongside any fixed values the destination requires.
Define response rules: what a success looks like, what a duplicate looks like, and what a failure looks like — including destinations that report errors with a 200 status.
Choose coverage: which websites and channels this connection serves.
Run a destination test from revoq's servers using a test number you choose, then read the sanitized reply and revoq's interpretation of it.
Activate. A connection cannot go live without a passing test, and a later material change pauses it until it is tested again.
Safeguards
What revoq enforces on every send
- HTTPS only
- Destination addresses must use HTTPS.
- Network target checks
- revoq validates the resolved destination before connecting and refuses internal or private network targets.
- Sealed credentials
- Keys are encrypted at rest and are never returned to the interface in full.
- Sanitized evidence
- Recorded responses are truncated and scrubbed so credentials and unnecessary personal data do not end up in evidence.
- Pinned configuration
- Each attempt records which configuration revision and credential version it used.
- Retries with spacing
- Failed attempts are retried automatically with increasing intervals, up to a bounded number of attempts.
Roadmap, stated plainly
Not available today
- Pre-built native connectors for additional marketing and lead platforms.
- Messaging-provider and content-management plug-ins.
- Scheduled file-based exchange and self-service export delivery by email.
- A public developer portal with hosted API reference documentation.
Anything on this list is planned work, not a current capability. If one of these is a requirement for you, raise it in a readiness review so it is discussed honestly rather than assumed.