Usage
Use cases
The Consumer Credit API supports two primary use cases: retrieving credit reports and retrieving credit decisions. The /creditReport endpoint is used to retrieve credit data about an individual. This endpoint is intended for integration where the customer implements the credit logic and decision‑making internally and uses UC purely as a data source. The response contains credit data from UC’s databases based on the report type specified in the request payload. The exact content of the response depends on the selected report type and customer permissions. The /creditDecision endpoint is used to retrieve a finalized credit decision based on a decision strategy that has been configured together with UC. This endpoint is intended for integrations where UC handles both credit data retrieval and decision logic. The response includes the decision result, the application data used by the strategy, and the associated credit report. All returned data is subject to availability in UC’s databases and customer permissions.
Choose input
In Credit API, consumer information is provided through five predefined report types. Each report type represents a fixed set of data blocks. Larger report types include more extensive and detailed data. The smallest report type is ID_CHECK, which is used exclusively to verify an individual’s identity and national registration details. Report types that include credit data range from XSMALL to LARGE and are requested using the CONSUMER_REPORT_<SIZE> identifier in the request. In addition to the predefined report types, certain data blocks are available as add‑on data. These data blocks can be returned only if the customer has the required permissions and the selected report type supports them. Add‑on data is requested by setting specific request parameters, such as creditCommitmentLevel, numberOfResidents, studentLoans, and scores, in the request payload. For /creditDecision, add‑on data is defined as part of the decision strategy configuration. As a result, this data is not explicitly specified in the API request, as it is already governed by the rules of the configured strategy.
Blockers
Blocker information is provided either by Skatteverket or registered by the individual. A blocker with the value true indicates that a condition related to the inquired person exists which prevents UC from providing any credit data or credit decision. Blockers represent business conditions rather than technical errors and are therefore always included in a successful API response. When a blocker is detected during a credit decision process, no decision object is returned. Instead, the response includes a status within the systemInformation object explaining why a decision is not possible. The status is complemented with the report type CONSUMER_ID_CHECK. This behavior is expected and must be handled explicitly in the customer’s integration logic.
Errors
The Consumer Credit API uses structured and consistent error responses to support programmatic error handling and troubleshooting. Errors are returned when the API is unable to process a request, for example due to invalid or missing request parameters, insufficient permissions, or failures in internal services. An error response will include:
- Error ID, a machine readable error code
- Error message, a descriptive error message in plain text
- Error details, technical details intended for troubleshooting. Included when available
Each error response also includes a requestId, which should be referenced if and when contacting UC support by e-mail at integration@uc.se.