Scripts and automation

Use DomainWarn in scripts, CI pipelines and workflows: query critical domains with curl and jq, stop deploys, webhooks for n8n, Zapier and Make.

On this page

Scripts, CI and automation (n8n, Zapier, Make)

In scripts and CI pipelines the API itself is enough: a token from Settings → API in the Authorization: Bearer header, the rest is curl and jq. The responses are the same JSON structures the dashboard uses.

For a deploy job the question is usually whether anything is open: status=critical on the domain list, or one of the free checks, which needs no token at all. To make the step fail, evaluate the number of findings – jq turns that into an exit code.

Writing calls (create a domain, check now) need a token with write scope; reading ones are enough for everything else.

CI step
export DOMAINWARN_TOKEN=dw_…
BASE=https://api.domainwarn.com/api/v1/orgs/my-agency

# critical domains; fails the step if there are any
curl -sf -H "Authorization: Bearer $DOMAINWARN_TOKEN" "$BASE/domains?status=critical" \
  | jq -e '.data | length == 0'

# before the deploy: check the certificate, without a token
curl -sf "https://api.domainwarn.com/api/v1/tools/ssl?domain=client.example" \
  | jq -e '.data.issues == 0'

n8n, Zapier and Make do not need a dedicated node: the HTTP request node with Authorization: Bearer <TOKEN> talks to the same API, and for the other direction – DomainWarn telling the workflow about something – there are webhooks as a notification channel. A scenario "incident opened → ticket in the helpdesk" is therefore a webhook channel in DomainWarn plus a webhook trigger in the automation tool.

See also: API documentation