Skip to content

Live stream (SSE)

GET /v1/stream/{did} resolves a DID like /v1/resolve, but sends each stage as a server-sent event as soon as it finishes: parsing the DID, DNS, the HTTPS fetch, domain linkage and so on. Use it to show progress in a UI, or to see where a slow or failing resolution stops.

The final result is the same resolution as /v1/resolve. The stream adds timing and order; it does not add any other evidence.

Your clienta DID
DID.is checks
  • DID syntax
  • DNS and address pinning
  • TLS and HTTP fetch
  • Document parsing
  • Domain linkage, history
  • Evidence assembly
Your clientstage … result … done
  1. stageOne event per completed stage, in order.event: stage
  2. result or errorThe full resolution, or an RFC 9457 problem.event: result
  3. doneThe stream ends.event: done
  • Each stage with stage, label, status, startedUs, durationUs and detail. The same stages appear in the trace array of /v1/resolve.
  • The full resolution in the result event, same shape as /v1/resolve.
  • Anything the resolution does not. The stream reports the same evidence with the same limits.
  • Fresh network stages for a cached result. Without ?noCache=true, a cached result shows a cache.hit stage instead of the DNS and fetch stages. The SDKs stream with noCache by default.

The endpoint uses the intensive budget (10 requests per minute). See Errors and rate limits.

Terminal window
curl -N 'https://did.is/api/v1/stream/did:web:did.is?noCache=true'

The SDKs resolve fresh (noCache) by default when streaming and stop after done. Pass { noCache: false } / no_cache=False to accept a cached result.

Start of a live stream (detail lines shortened):

event: stage
data: {"stage":"syntax.parse","label":"DID syntax (DID Core §3.1)","status":"PASS","startedUs":0,"durationUs":3,"detail":"method 'web' · 14 characters"}
event: stage
data: {"stage":"method.web.transform","label":"DID-to-HTTPS transformation","status":"PASS","startedUs":6,"durationUs":9,"detail":"did:web:did.is → https://did.is/.well-known/did.json"}
event: stage
data: {"stage":"egress.dns","label":"DNS resolution and address pinning","status":"PASS","startedUs":28,"durationUs":1629,"detail":"did.is pinned to 104.21.76.195 (all answers public)"}
event: stage
data: {"stage":"egress.fetch","label":"TLS handshake and HTTP exchange","status":"PASS","startedUs":1779,"durationUs":42936,"detail":"GET https://did.is/.well-known/did.json → HTTP 200 · 678 bytes; …"}
…
event: stage
data: {"stage":"evidence.assemble","label":"Evidence assembly","status":"PASS","startedUs":89080,"durationUs":125,"detail":"7 dimensions · 7 graph nodes · verdict RESOLVED"}
event: result
data: { …full resolution… }
event: done
data: {}
Stage status What it means
PASS The stage completed and its check passed.
FAIL The stage failed. An error event usually follows with the problem.
WARN The stage completed with a finding worth reading in detail.
INFO Information only, for example cache.hit.
Final event What to do
result Read it like a /v1/resolve result.
error Handle the problem code as on Errors and rate limits.

If the request is refused before the stream starts (for example 429), you receive a normal problem response instead of an event stream.

  • Resolution explains the result and its evidence.
  • Search a DID on did.is; the result page shows the same stages as a trace.