Errors & fail-open semantics
cause (per ES2022 Error.cause) so you can chain through to the underlying failure when reporting.
BlursecError
Base class. You’ll rarely instantiate it directly, but you can use it for catch-all branches:
BlursecValidationError
Thrown synchronously when you call the SDK with invalid arguments. Examples:
new Blursec({ apiKey: "" })blursec.credentials.checkHash("not-a-valid-hex")- Negative or non-finite
timeoutMs
BlursecAPIError
Thrown when the API returns any non-2xx response. Carries:
When the SDK swallows vs. throws BlursecAPIError
For blursec.credentials.* and blursec.sessions.verify() calls, fail-open swallows 5xx errors and returns a safe default. 4xx always throws — those indicate a caller bug (bad key, malformed request, etc.) and silently allowing the login would mask the misconfiguration.
For every other call (auth.*, client.request()), every non-2xx throws.
BlursecTimeoutError
Thrown when a request is aborted — either by the SDK’s internal timeout or by a caller-supplied AbortSignal.
BlursecCircuitOpenError
Thrown by the internal circuit breaker when too many recent requests failed and the breaker has tripped open. While open, the SDK short-circuits new requests instead of hammering a struggling API.
credentials.* / sessions.verify this is swallowed by fail-open (the result carries failedOpen: true, failureReason: "circuit_open"). You can inspect breaker state for a /health endpoint via the exported CircuitBreaker.
The fail-open contract (credentials.* + sessions.verify)
By default, blursec.credentials.check(), checkToken(), checkHash(), and blursec.sessions.verify() never throw on transient failures. Instead they return:
Always check
risk.failedOpen if you care about distinguishing “definitely safe” from “we don’t know”:
Opting out
SetfailOpen: false for any single call to switch to throw-on-error semantics:
- You’re running offline tests and want deterministic behavior
- You have a fallback risk source and want to surface Blursec failures explicitly
- You’re auditing the integration and need to see every error
failOpen: true) is almost always correct.
