Skip to main content
In this phase, you send deliberately incorrect data requests and confirm the Data Holder returns the right error. Under the Consumer Data Standards (CDS), error responses must use specific HTTP status codes and error codes, and follow a set structure. For the full definitions, see Error Codes in the CDS.
Prerequisite: Complete Phase 2 so you have working requests and a known-good response for each persona.

Error response structure

Every error response contains an errors array. Each error has a code, a title, and a detail.
Example error response
For each test, confirm:
  • The HTTP status code matches the table below.
  • The code matches the CDS error code exactly.
  • The detail identifies the field, header, or resource ID at fault, where the CDS says it should, without revealing sensitive information.

Quick reference

Start with these common scenarios, then work through the full list below.

Error scenarios by status code

These errors apply when the resource ID is in the URL path.
These errors apply when the resource ID is in the request body, plus the arrangement and pagination errors.
Test each account and resource error with every test persona. For example, use Persona B’s unselected account to confirm that an account the customer owns, but didn’t share, is still rejected.
For how your Resource Server should return 403, 404, 422, and 500 errors to Fiskil, see Errors.
When every scenario returns the expected status and error code, continue to Phase 4: Consent dashboard and revocation.