⚠️ You’ll find German domain-specific terms in the documentation, for translations and further explanations please refer to our glossary
This API enables building societies within consumer loans to connect their loan offering to the Europace platform via services with standardized interfaces.
⚠️ This API is continuously developed. Therefore we expect all users to align with the “Tolerant Reader Pattern”, which requires clients to be tolerant towards compatible API changes when reading and processing the data. This means:
unknown properties must not result in errors
Strings with a restricted set of values (Enums) must support new unknown values
sensible usage of HTTP status codes, even if they are not explicitly documented
The version of the API is based on Semantic Versioning and has the format
and is part of the Swagger Definition (
MAJORversion is incremented in case of API incompatible changes (e.g. new mandatory data)
MINORversion is incremented for backward compatible API changes (e.g. new optional specifications)
PATCHversion is incremented if the API remains the same, but the Swagger definition is adapted (e.g. extension or adaptation of descriptions in the API)
You will find the current version of the API within the Releases.
Requests and responses are defined in the Swagger Definition.
The calculation serves to generate offers.
In the process, the data provided for the Finanzierungswunsch as well as the applicant data are transmitted to the product provider.
The product provider:
If all the necessary data is available and the preliminary check was successful, the case can be accepted. In this process, the customer’s request, i.e. the provided data of the Finanzierungswunsch, as well as the applicant data are transmitted to the product provider.
The product provider should then, in turn, carry out all steps necessary for accepting the offer:
The implemented interface accepts data with content-type application/json.
Services that implement the API expect a POST request with a JSON document as request body.
During the offer calculation, it is already ensured that the application data is complete. Nevertheless, the service must be able to deal with missing data. This should not lead to a technical error.
The response will be expected as JSON within the response body.
In general a response with a complete offer and HTTP status code 200 SUCCESS is expected. If the offer is
MACHBAR, at least one document is expected.
In case of a technical error a response with HTTP status code 500 is expected. The response must not contain an offer, but should give an indication of the cause of the error as
A complete offer without document(s) is expected. The feasibilty status is
NICHT_MACHBAR. Completeness messages, that point out the missing data, must be available.
If the application is not feasible due to a shortfall in the Haushaltsrechnung, ideally the duration will be extended. If this is not possible, a downselling of the loan amount can take place.
If a downselling results in a feasible offer, this is marked as
“angepasst”: true and contains appropriate adjustment messages to inform the agent of the adjustment.
If a downselling is not possible, an offer without document(s) with the status
NICHT_MACHBAR and at least one corresponding feasibility message is expected. Duration and loan amount should in this case correspond to the original request.
Messages are generated to provide guidance to the agent on the excecution and feasibility of the application. The following categories are distinguished.
|The application will be rejected.||no influence|
|The application is incomplete and must be completed with missing data.||no influence|
|Note to the agent.||no influence||no influence|
|Information about adjustments of the customer’s request, e.g. monthly payment, loan amount oder insurance.|
|The application is accepted.|
|The application could not be examined conclusively. Product provider and agent need to renegotiate.|
|The application is rejected.|
The method of authentication has to be coordinated between the Produktanbieter and Europace.
The calculation response must be within 4 seconds, slower responses will be discarded. The acceptance response should be within 20 seconds, but responses here may still be processed if certain overruns occur. If the response time is significantly higher, the functionality of our platform deteriorates for other partners, e.g. agents.