/
General

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