Skip to content

Build with the record

Errors and integration practices

Handle unavailable data, network selection, response shapes, and retry behavior.

Check the response

Inspect HTTP status and Content-Type before reading the body as JSON. A 200 response from an unrelated host or route can be an HTML page. Use the hosts and paths shown in this reference.

ts
1
const response = await fetch(url, {
2
signal: AbortSignal.timeout(15_000),
3
})
4
if (!response.ok) throw new Error(`HTTP ${response.status}`)
5
if (!response.headers.get("content-type")?.includes("application/json")) {
6
throw new Error("Expected a JSON response")
7
}
8
const body = await response.json()

Separate missing from unavailable

A 404 on a record read means the route did not find the requested record or file. A 5xx means the lookup failed. Keep those states distinct and never treat an outage as a successful verification.

Retry carefully

Use a request deadline and a small, bounded number of retries for transient read failures. Back off between attempts. If a 429 or Retry-After header is returned by infrastructure, respect it. The docs do not specify a public rate-limit allowance.

Preserve context

Store the identifier, selected network, source URL, and time of your read with any decision. Preserve the full registration URI, including its query. Avoid silently substituting a test-network record for a production record.

Respect data boundaries

Public reads should not require a private key, a browser session export, or a CMS administration key. Keep app sessions in the app. Confirm service authentication with the team before building protected workflows.

Get help

Contact Entity.ID with the route, response status, approximate UTC time, and a public record identifier. Omit secrets and identity documents. Describe the fields and availability your integration requires.

Built around the current Entity.ID app.Questions or feedback? ↗