Integrations

Signed webhooks out, your AI in, your infra underneath.

Dotvoid is built to fit into a stack you already have. Verify webhooks with HMAC-SHA256. Plug in the AI adapter you already pay for. Self-host or let us host.

Read the editor source on GitHub ↗

Webhooks

Subscribe per webhook per event.

Webhooks are how Dotvoid talks to the rest of your stack. Your CMS, your archive, your search index, your CDN, your push service - whoever needs to know a document is usable gets a signed payload with the snapshot. Verify the signature, parse the body, do your thing.

Each webhook subscribes to its own subset of event types. Two integrators don't see each other's deliveries. Retries run with exponential backoff; every delivery is logged and can be replayed by hand from the admin UI.

SignedHMAC-SHA256 in the X-Void-Signature header.
SubscribedPer webhook, per event type - not all-or-nothing.
Snapshotteddocument.usable payload carries the doc snapshot.
RetriedExponential backoff plus a delivery log per endpoint.
ReplayableRe-fire any delivery from the admin UI.

In the editor

What an integrator receives.

A webhook fires the moment its event lands. The payload is JSON, signed, and includes the snapshot for document.usable.

Webhook

POST https://crm.example.com/hooks/void0

Subscribes to

document.usabledocument.cancelleddocument.translated

Signed with

X-Void-Signature: sha256=…

↓ fires

// Your endpoint receives: { "type": "document.usable", "tenantId": "newsroom-1", "documentId": "a3e1...", "version": 4, "actor": { "kind": "user", "email": "..." }, "snapshot": { "title": "Cabinet reshuffle", "meta": { "lang": "sv" } } }

Workflows already know when something interesting happens. Webhooks let you forward those events anywhere - CRM, search index, Slack, your publishing pipeline.

AI adapters

Bring your own model.

We don't believe in one model for the whole product. A translation might want one model, a headline rewrite another, a categoriser a third. Each AI operation picks its adapter and its model. Switch them per transition without redeploying.

OpenAINative adapter.
AnthropicNative adapter.
MistralNative adapter.
OpenAI-compatibleAny service that speaks the API.
Per operationModel selection on the operation, not globally.

In the editor

An operation, end to end.

Each operation declares its connector, its prompt, its optional inputs, and where its output lands.

AI operation

Translate article

Bound to the Translate transition on every article workflow.

usable

Connector

OpenAI · gpt-5

Applies to

core/article

Instructions

Translate the article body into the target language. Preserve inline marks and core/link nodes verbatim. Reference user input via `userInputs.targetLanguage`.

User input

SwedishDanishNorwegian+ 5 more

Output targets

textPatchpatchescontent.text

inputPathtargetLanguagemeta.lang

One operation, declared once, bound to any transition. The user picks the language at trigger time; the operation writes the translated text and updates meta.lang in the same atomic step.

Where it runs

Same product, your choice of host.

We don't have a cloud-only tier. A one-person operation can run Dotvoid on a single VPS; a 400-reporter newsroom can run the same code on a Kubernetes cluster. Or let us run it for you out of Stockholm. The capabilities are identical in either case.

VPSSingle-host self-host for a solo operator.
ClusterKubernetes self-host for a large newsroom.
ManagedRun by Dotvoid in Stockholm.
Same codeNo "cloud-only" features. Read the docs and decide.
StackPostgres, S3-compatible storage, Keycloak for auth.

Next step