Skip to main content
Every error, on every endpoint, uses the same envelope:
  • error: a stable, machine-readable code. Branch on this.
  • message: human-readable; wording may change, so never parse it.
  • details: present on invalid_request, with one entry per failing field and an index when the payload is an array (census rows, enrollment member checks).

Error codes

Conflicts

409 conflict covers several states. Its message says which:
  • The group is already enrolled (creating an embed session or a second enrollment).
  • The quote is still in_review (POST /enrollments).
  • A live-mode embed session was requested before Prescience saved your iframe origins.
  • The employer’s plan terms are not approved yet (GET /benefits-summary).
  • An enrolled group already exists for this domain (POST /groups).

Request IDs

Every response from the Partner API carries an X-Request-Id header. Log it with every failed call and include it when you contact Prescience; it lets us find the exact request. If you send your own X-Request-Id (up to 128 characters of letters, digits, and simple punctuation), the response echoes it back, so you can correlate our logs with yours. Otherwise, or if your value doesn’t fit that format, Prescience generates a UUID. Treat the value as an opaque string.

Handling patterns that hold up

  • Branch on error; log message and the X-Request-Id header. Codes are contractual; messages aren’t.
  • Most 409 conflict responses mean the thing already exists or isn’t ready yet. Fetch the resource and continue rather than surfacing an error to the employer.
  • Retry 500 and 503 with the same Idempotency-Key on the endpoints that honor one. See Rate limits & idempotency.
  • Don’t blanket-retry 4xx. Other than 429, 409 rates_pending, and the 410 re-quote flow, 4xx errors need a changed request, not a repeated one.