API reference

The DMARCify API is organised around standard HTTP verbs and returns JSON. All requests are made over HTTPS to https://app.dmarcify.dev. The current version is v1; every path is prefixed with /v1.

• JSON request bodies, JSON response bodies (UTF-8).
• Errors follow RFC 7807 with application/problem+json.
• Timestamps are ISO-8601 in UTC; durations are integers in seconds.
• An unauthenticated discovery document is available at GET /v1.
• Agent clients can use the same bearer token through the MCP server.

curl https://app.dmarcify.dev/v1

Every request must include a bearer token in the Authorization header. Tokens are created from Settings → API tokens in the dashboard and are scoped to a single organisation.

Authorization: Bearer dm_live_...

Tokens carry one or both of two scopes:

• read — list organisations and domains, fetch summaries, sources, reports.
• write — create child tenants, add/delete domains, trigger DNS rechecks, connect and manage DNS providers.

Errors are returned as application/problem+json following RFC 7807. The HTTP status code is also reflected in the body's status field so you only need to read one place.

HTTP/1.1 404 Not Found
Content-Type: application/problem+json

{
  "type": "about:blank",
  "title": "Not Found",
  "status": 404,
  "detail": "Domain not found: example.com"
}

Reads are not currently rate-limited per-token, but excessive parallelism may be throttled to protect the underlying datastore. Manual DNS rechecks share a 1-per-hour budget with the dashboard recheck button and the MCP recheck tool. Provider credential verification and zone refreshes call upstream DNS provider APIs; retry those with exponential backoff.

API tokens are scoped to one organisation. Agency-tier parent organisations can use that token to create and inspect child tenants; child tenants inherit branding when created with inheritBranding.

{
  "name": "Client GmbH",
  "inheritBranding": true
}

{
  "organization": {
    "id": "01J...",
    "name": "Client GmbH",
    "parentOrgId": "01J...",
    "brandingLocked": true,
    "effectiveBranding": {
      "brandName": "Agency name",
      "customDomain": "reports.agency.example"
    }
  }
}

{
  "name": "Agency Operations",
  "branding": {
    "brandName": "Agency",
    "brandLogoUrl": "https://cdn.example.com/logo.png",
    "brandPrimaryColor": "#111827",
    "brandSupportEmail": "support@example.com",
    "customDomain": "reports.example.com"
  }
}

Provider endpoints manage the same DNS integrations as the dashboard. Secrets are accepted only on create/discovery calls and are never returned. Provider-specific metadata depends on the provider:

• cloudflare — no metadata.
• vercel — optional teamId.
• azure — tenantId, clientId; secret is the client secret value.
• godaddy — apiKey; secret is the API secret.
• aws — accessKeyId; secret is the secret access key.
• google-cloud — projectId, clientEmail; secret is the full service-account JSON.

{
  "provider": "cloudflare",
  "secret": "cf_api_token",
  "metadata": {}
}

{
  "zones": [
    { "name": "example.com", "accountName": "Production" }
  ]
}

{
  "provider": "cloudflare",
  "name": "Cloudflare production",
  "secret": "cf_api_token",
  "discoverZones": true,
  "addDiscoveredDomains": true,
  "domainScope": "all",
  "automaticManagement": false
}

{
  "name": "Cloudflare EU",
  "domainScope": "selected",
  "managedDomains": ["example.com"],
  "automaticManagement": true
}

{
  "fqdn": "example.com",
  "policy": "quarantine",
  "pct": 100
}

204 No Content

Read endpoints accept either an absolute from/to pair (Unix seconds) or a shorthand range=7d / 30d / 90d (up to 366 days). Default is the last 30 days.

The path-versioned prefix (/v1) is stable. Breaking changes ship behind a new prefix (/v2) and the previous version is supported for at least 12 months. Additive changes — new fields, new endpoints — can land in /v1 at any time and should be treated as non-breaking; please ignore unknown fields.

Found a bug or have a feature request? Email hello@dmarcify.dev.