propgate docs

API reference › Domains › Get domain

Get a domain

GET/v1/domains/:id

Returns the stored result, whatever the last check left behind. This call never re-checks; it is a read against Postgres, not a DNS run. To get a fresh result, call verify first.

No CLI command yet — the CLI's domains list covers the common case; reading one domain back is API-only.

curl -s https://api.propgate.dev/v1/domains/019fcf7a-2b3c-7d4e-9f5a-6b7c8d9e0f1a \
  -H "authorization: Bearer pg_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"          # stored, no re-check
{
  "data": {
    "createdAt": "2026-08-03T12:00:00.000Z",
    "externalId": "cust_1",
    "id": "019fcf7a-2b3c-7d4e-9f5a-6b7c8d9e0f1a",
    "lastCheckedAt": "2026-08-03T12:05:00.000Z",
    "lookups": [
      {
        "name": "yourdomain.dev",
        "purpose": "SPF record",
        "server": "8.8.8.8:53",
        "status": "answered",
        "type": 16
      },
      {
        "name": "google._domainkey.yourdomain.dev",
        "purpose": "expected selector",
        "server": "8.8.8.8:53",
        "status": "answered",
        "type": 16
      }
    ],
    "name": "yourdomain.dev",
    "object": "domain",
    "profileVersionId": "019fcf6b-1a2b-7c3d-8e4f-5a6b7c8d9e0f",
    "requirements": [
      {
        "key": "spf",
        "satisfied": true,
        "verdict": "pass",
        "findings": []
      },
      {
        "key": "dkim",
        "satisfied": false,
        "verdict": "fail",
        "findings": [
          {
            "code": "DKIM_RECORD_MISSING",
            "name": "google._domainkey.yourdomain.dev"
          }
        ]
      }
    ],
    "requirementsMet": 3,
    "requirementsTotal": 5,
    "state": "failed",
    "verdict": "fail"
  },
  "error": null,
  "meta": null
}

requirements mirrors verify's response: the same per-requirement satisfied, verdict and findings, just read from storage instead of freshly computed.

Why lookups is here and not on the list

Every check carries the queries that produced it: the DNS name asked, type (the numeric RR type, e.g. 16 for TXT), which server answered (address:port), and status. A verdict you cannot audit is a verdict you have to take on faith, and "why did you say that" is the question a disputed result produces.

status is coarser than it looks: it is answered | timeout | unreachable | malformed | truncated, the transport-level outcome, not the DNS response code. An answered lookup for a name that does not exist, like the DKIM_RECORD_MISSING case above, still reports status: "answered", because the server answered; it just said NXDOMAIN. Read the finding's code for that distinction, not status.

This is the field the list endpoint omits, at roughly 4.4× the per-domain size. Fetch a domain individually when you need to show someone why a check came back the way it did.