General

Levels of estimated error severity.

If an error is present in the context of an API (or endpoint), it applies only to that API (or endpoint).

Critical	This severity level implies that the process always/usually works badly.
MAJOR	This severity level implies that the process works badly in some cases.
MEDIUM	This flaw results in unfavorable behavior but the system remains functioning.
LOW	This type of flaw won’t cause any major breakdown in the system.

List of identified issues in this category (click on the title to show details)

Description	If a specification requires some field to be in a specific format, applications should have proper server-side validation to prevent their users from entering incorrect data. Perfect examples are fields where the value is expected to be an email (like email in Mobility Factsheet API) or a URL (like website-url in Institutions API).
Estimated severity	MAJOR
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Monitoring system Problem occurred for at least 15 providers in PROD (link1, link2)

Description	Fields specified as required (e.g. decision-weeks-limit in Mobility Factsheet API) must be provided in the API response. Such errors in many cases can be easily detected in your tests by validating your responses with the XSD schemas. You can also use validators available in the DEV Registry Service.
Estimated severity	Critical
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Monitoring system Problem occurred for at least 11 providers in PROD

Description	A server attaches full request body and parameters in error-responses.
Estimated severity	MEDIUM
Examples
Suggested action	A server should stop doing this, because it might result in leaking private data when such errors are reported with the Monitoring API.
How communicated	Monitoring system Problem occurred for at least 2 providers in PROD (link1, link2) and 1 other in DEV

Description	A server attaches full stack traces of errors in error-responses.
Estimated severity	LOW
Examples
Suggested action	A server should stop doing this, because full stack traces aren't helpful to other partners and are only making reports sent with the Monitoring API less readable. In case of unknown errors it is enough to return some generic message, e.g. "Something went wrong. Administrators have been notified. We'll try to fix it ASAP.", as suggested in the specification.
How communicated	Monitoring system Problem occurred for at least 2 providers in PROD (link1, link2).

Description	According to specification “Once you receive a change notification, you respond with HTTP 200, and add the received identifiers to a queue. Later on, in the background, you will attempt to update your locally stored information on the received entities (e.g. by calling the `get` endpoints of the APIs which describe this entity). You SHOULD NOT try to refresh your data before sending your CNR API response. Refreshing the data (e.g. calling the `get` endpoint) is a separate operation, and the result of this operation MUST NOT influence the HTTP response of your CNR API” A number of partner send some error codes instead.
Estimated severity	MAJOR
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Email correspondence with providers, testing sessions, GitHub This error was encountered in a number of mobility systems