Preliminary information
Availability of the API
Connection and use of the service
Preliminary information
What is CoFFEE and CoFFEE-MRR?
CoFFEE (Common European Funds Platform) is the common IT platform for the management of European funds. It aims to integrate the various modules supporting the management of European funds under the competence of the General Secretariat of European Funds (SGFE) into the multiannual financial framework 2021-2027 (MFF 21-27). It is the evolution of the information systems that support the management of the European Regional Development Fund (ERDF) in the financial frameworks prior to 2021-2027, but it has been designed to support other funds and/or mechanisms.
CoFFEE-MRR is a CoFFEE module that takes advantage of technology, cross-cutting processes, information incorporation mechanisms, etc. the platform, which incorporates the necessary functionality for the planning, management and monitoring of initiatives associated with the Recovery and Resilience Mechanism, and in particular the Recovery, Transformation and Resilience Plan (PRTR).
How do I request access to CoFFEE/CoFFEE-MRR?
The procedure for requesting access to Budget Administration systems is described in the
“Access Control” section of the Budget Administration Portal.
Availability of the API
What is the point of the CoFFEE API?
The electronic services are put into operation to facilitate the executing entities of the initiatives to comply with the provisions of the regulations that regulate the Plan, and in particular in Order HFP/1030/2021, of 29 September, by which the management system of the Recovery, Transformation and Resilience Plan (Management Order) is configured, and Order HFP/1031/2021, of 29 September, by which the procedure and format of the information to be provided by the Entities of the State Public Sector, Autonomic and Local Entities for the monitoring of the fulfillment of milestones and objectives are established.
Entities that do not have this capacity can incorporate the information interactively, for which they must first request access.
Is the REST API already available to connect me?
Yes, yes. The status of implementation of the various endpoints can be found at:Status of endpoints.
List of versions
| Date | Version | Environment | Link to the IPR | New developments |
|---|
| August 2025 | 2.0.10 | Production | Link to version 2.0.10 | Improvements to the Indicator Progress documentation |
| June 2025 | 2.0.9 | Production | Link to version 2.0.9 | Inclusion of payment scenarios in indirect financial instruments |
| May 2025 | 2.0.8 | Production | Link to version 2.0.8 | New endpoint for the edition of amounts of legal instruments |
| April 2025 | 2.0.7 | Production | Link to version 2.0.7 | New endpoint for differential editing of progress report |
| April 2025 | 2.0.6 | Production | Link to version 2.0.6 | Adaptation to functional changes of CoFFEE |
| April 2025 | 2.0.5 | Replaced by v2.0.6 | Link to version 2.0.5 | Adaptation to functional changes of CoFFEE |
| February 2025 | 2.0.4 | Replaced by v2.0.5 | Link to version 2.0.4 | Adaptation to functional changes of CoFFEE |
| December 2024 | 2.0.3 | Replaced by v2.0.4 | Link to version 2.0.3 | New legal instruments: Direct financial instruments, indirect financial instruments, implementing agreements, intermediation agreements. |
| October 2024 | 2.0.2 | Replaced by v2.0.3 | Link to version 2.0.2 | Definition of services for the recording of progress of indicators. Definition of the services for the consultation of (non-) revocation certificates. |
| June 2024 | 2.0.1 | Replaced by v2.0.2 | Link to version 2.0.1 | Definition of services for the discharge of proceedings, instrumental sub-projects, sub-projects and projects. Definition of services for the recording of progress and monitoring of indicators. |
| March 2024 | 2.0.0 | Replaced by v2.0.1 | Link to version 2.0.0 | |
| May2025 | 1.5.3 | Production | Link to version 1.5.3 | The methods of registering recipients are declared to be obsolete. |
| March 2024 | 1.5.2 | Production | Link to version 1.5.2 | Optional proprietary parameter in some listings and project information in sub-projects, instrumental sub-projects and actions. |
| January 2024 | 1.5.1 | Replaced by v1.5.2 | Link to version 1.5.1 | Adaptation of the definition of services to the functional changes of CoFFEE. Correction of errors. |
| November 2023 | 1.5.0 | Not implemented | Link to version 1.5.0 | Adaptation of the definition of services to the functional changes of CoFFEE. |
| April 2022 | 1.3.1 | Not implemented | Link to version 1.3.1 | Statements of indicator progress (also limiting the possible values for qualitative indicators) and financial performance are dealt with separately. Finally, the accounting documents OJ and OJ/ are included. |
Are there alternative mechanisms to the API to provide information to the platform?
Yes, depending on the type of information to be reported, the system will provide mechanisms for the information to be provided interactively by users connecting to it, and also by incorporating (interactively) a file containing all the data to be processed.
Naturally, CoFFEE will perform the same validations when information is provided on a mass basis through the uploading of a file.
What is the coding format of the JSON file that is uploaded to CoFFEE?
The codification is UTF-8.
Connection and use of the service
How do I request access to the API and what procedure does it trigger?
In case you wish to proceed with integrating an external management application with CoFFEE, you should refer to the document with the instructions for compliance with the authorization to update information in CoFFEE using APIs.
The procedure can be summarised in these points:
2.La OIP will contact the requesting technical department via the CoFFEEDesarrollo@igae.hacienda.gob.es mailbox indicating the user who identifies the management application.
3.Los responsible for node information (PRTR projects, sub-projects and instrumental sub-projects) authorise the user who identifies the management application that serves them to access and edit node data.
4.El requesting technical department sets up the electronic certificate to be used for secure communication.
How do we achieve security of access?
Client Web services will be authenticated using HTTPS/TLS (1.2 or higher). In particular, a certificate of seal of administration, body or entity of public law will be used for automated administrative action, or a qualified electronic seal certificate derived from the eIDAS Regulation, issued in any case by one of the certification service providers recognized by the @Fira service.
During the organizational process of access authorization, the certificate to be used by the client end of the service is agreed between the Office of Budgetary Informatics and the technical contact of the agency concerned.
How is a typical interaction with the service (a call to an API method)?
Once the access authorisation process has been completed, the client system is in a position to make use of the service. To this end, any interaction will be carried out under a secure communication (TLS) using the pre-agreed seal certificate.
Each call to the REST service will include in the HTTP request, in addition to the parameters indicated in the documentation of the service itself, two additional parameters (idUser and idApplication), which will contain the values that were provided during the access configuration process.
Can several organizations use the same seal certificate to interact with the API?
Although not usual, this possibility is enabled if two requests for access are processed, one for each of the organizations, and the same certificate is configured in both. In the authorization process, a different service user (idUser) will be created and assigned for each of them, and the corresponding profiles operating in each of the areas will be configured in CoFFEE.
Since each request to the service includes among its parameters the service user code (idUser), CoFFEE will be able to determine the origin and will be able to act accordingly, applying the corresponding security profile.
Notwithstanding the above, it should be borne in mind that if one of the organizations were to use the user-id assigned to the other, there would be no mechanism for identifying the impersonation, so this possibility would be carried out at the risk of the client organizations.
Are there any limits set for the use of the service?
The following limits have been defined:
- Maximum petition size: 100MB.
- Maximum document size: 60MB.
- Maximum limit of items in a collection: 100 elements.
- Maximum number of requests per second: 5 requests.
- Maximum number of documents uploaded without association: 20 documents.
General questions on the IPR
What is the format of the dates?
The OpenApi 3.0 specification referring to the definition
RFC 3339, section 5.6 is followed, e.g.
2022-07-21.It is important to note that some requested dates must be specified in quarters.
Are all API fields mandatory?
No, only those fields that are marked as such (with a red asterisk) are obligatory.
In relation to indicator statements of progress: does the “date” field (the reference date of progress) have to be the current date?
The reference date for the progress of an indicator is that when the value of the indicator being updated is considered to have been reached, and therefore it has to be earlier than or equal to the current date, i.e. no future dates are allowed.
Why in the case of quantitative indicators is “variation” reported and in the case of qualitative indicators is “value” reported?
Indicators are indicators of achievement and may be quantitative (their value is a numerical figure within a range) or qualitative (they may take a value from a closed set of options).
- In the case of quantitative indicators, the variation from the previous value of the indicator should be reported. For example, if the indicator is " Number of electric vehicles registered " and the number of vehicles has risen from 1,000 to 3,000, it will be declared " 2000 " .
- In the case of qualitative indicators, the new value that has been taken from among the possible ones (start, ongoing and completed) must be reported.
The reason why the variation is provided for quantitative indicators is that the system allows for the incorporation of a justification (textual and, optionally, accompanied by archives). It is understood that at the time of the declaration, the increased (or decreased) value of an indicator is being justified, not the final value achieved (in the example above, the 2000 vehicles that have been registered are justified).
In the case of qualitative indicators, there is a change in their status, and therefore the status achieved is declared.
What is the reference to a legal instrument?
Statements of accounting execution specify a reference to the legal instrument under which the statement is made. The typical case is a contract or a subsidy, but all the instruments envisaged must be capable of being identified.
The reference is therefore a code identifying the specific legal instrument in the field of Action for which enforcement is recorded.
The reference usually coincides with the code of the instrument itself that is established by the person registering it with CoFFEE (either by screen, mass loading, ...).
For example, in the case of a grant registered with CoFFEE with the BDNS code '576282', the reference is exactly that same code. Or a contract (not PLACSP) which has been registered with CoFFEE with the contract code '2023OIP45544', will have that same code as a reference.
However, there is a more complex case which is that of PLACSP contracts, and which is specifically addressed in the following question.
How does a contract that is registered on the Public Sector Procurement Platform (PLACSP) differ from one that is not?
PLACSP contracts are identified by three codes: contracting authority code, tendering code, and contract code (see next question for a detailed explanation). Non-PLACSP contracts are identified by a single code.
In the registration of contracts in CoFFEE, the two types of contract are identified separately.
Since references to legal instruments are made through a single field, in the case of PLACSP contracts (which, as indicated, have three codes) the reference corresponds to the concatenation of the three values using the “~” separator between them, even if the fields were empty.
What are the contracting, tendering and contract body codes of PLACSP?
The contracting authority code is an identifier used by the Public Sector Procurement Platform (PLACSP) associated with each of the contracting authorities (in PLACSP it is referred to as the " Platform ID " ). Each contracting authority may consult its own on the administrator screen of the PLACSP " recruitment authority administrator " profile.
In addition, the General Directorate of State Heritage regularly publishes the list of codes on an
Excel sheet, which is being updated.
In the case of PLACSP and for each contracting authority, the tender and contract codes are those that uniquely identify a contract that is incorporated into the Public Sector Contracts Platform:
The tender code corresponds to the File Number in PLACSP, which is the file number provided by each contracting authority.
The contract code corresponds to the PLACSP Contract. It is also a value that is determined by the contracting authority. It corresponds to each contract in the file.
In any case, both are values provided by the manager to PLACSP. Both can be seen in the following image.
When is the “Other Sources of Funding” field completed?
Information on other sources of information will be completed when the operation is funded by some other source, in addition to funding from the Recovery and Resilience Mechanism. In this case, the mechanism or fund that financed the operation will be identified.
Significant changes from v1.3.1 to v1.5
The highlighted changes are listed according to the type of data:
- All types:
- code Initiative is now code Action
- Measure:
- date Start its value is one quarter
- dateFin its value is one quarter
- Contract:
- contract PLACSP is now Instrument Code, Tender Code and Organizational Code
- contract NoPLACSP is now codeInstrument
- Subsidy:
- announcement BDNS is now codeInstrument
- Initiative:
- Separated into Project, Subproject, SubprojectInstrumental and Action.
- date Start its value is one quarter
- dateFin its value is one quarter
- Financial Declaration
- DeclarationForwardIndicator
- code Initiative is now called code OriginProgress
As a general rule, missing camps do not need to be reported.
Significant changes from v1.5.0 to v1.5.1
- Route:
- Updated POST/execution/other instruments/addressees path
- The detailed routes of a legal instrument have been updated. The {reference} parameter is converted to the query parameter. For example, GET /structure/actions/{code}/agreements/{reference} becomes GET /structure/actions/{code}/agreements/detail?reference={reference}
- Action:
- The field transferFrom Economic ResourcesTo Action Sub-project has been updated and becomes optional.
- The Critical Objectives field has been added to Action.
- The type of the Economic Resources of Action field has been updated.
- Sub-project:
- The costEstimated field of Economic Resources of Sub-project has been removed.
- Instrumental sub-project:
- The costEstimated Economic Resources field of Instrumental Sub-Project has been removed.
Significant changes from v1.5.1 to v1.5.2
- Owner code The parameter Owner code becomes optional in the following paths:
- /V1.5/Structure/projects
- /V1.5/Structure/subprojects
- /V1.5/Structure/Instrumental sub-projects
- /V1.5/Structure/actions
If not included, the list will contain all items of the corresponding type to which the user has access.
- Project Subprojects, instrumental subprojects and actions include a summary of the project to which they belong (project ownership).
Significant changes from v2.0.0 to v2.0.1
- Legal instruments.
- The methods of updating PATCH by PUT for the nine types of legal instruments have been changed.
- The role fields of the ChangeSetter, ChangeSetter and ChangeReceiver schemes have been changed. The description is now returned and not an object.
- The name of the SinVAT to SinVAT field has been updated.
- The UID has been added to the Operations Manager requests.
- A bug has been fixed in instrument profile requests that does not involve expenditure that did not show the correct route.
- An endpoint has been added to the legal instruments to cancel a request for an operating officer.
- An endpoint has been added to the legal instruments to obtain the details of a request for an operating officer.
Significant changes from v2.0.1 to v2.0.2
- Progress of indicators
- The URL of progress reports to indicator progress is modified.
- The code of the node to which the report belongs is included in the URL.
- It includes the endpoints required for the paginated consultation of documents.
- Legal instruments.
- The fields SinIvaFirstLevel and TotalFirstLevel are returned in the information of a legal instrument.
- The number-lot field is allowed to be edited by contractors.
- Milestones and objectives.
- ｟ADMIN｠ Se definen e implementan los endpoints de consulta de certificados de (no) revocación.
- Economic resources
- The endpoints for the consultation of economic resources are included.
Significant changes from v2.0.2 to v2.0.3
- Progress of indicators
- New types of editing of progress reports.
- Legal instruments
- Direct financial instrument.
- Indirect financial instrument.
- Implementing Agreement.
- Brokering agreement
- New types of perceptor editing.
- New field date of creation.
- Milestones and objectives.
- Modification of endpoints for registration and editing.
- Follow-up to the plan
- Modification of PUT /subprojects/{code}/submeasures/{submeasure} by POST /subprojects/{code}/submeasures/{submeasure}
Significant changes from v2.0.3 to v2.0.4
- Milestones and objectives.
- New type of document 'Additional documentation to the certificate'
- Allow multiple documents in first-level controls of a certificate
- GET /milestones/{code}/tracking/certificates/{uid-certificate}/control-first-level
- GET /milestones/{code}/tracking/certificates/{uid-certificate}/control-first-level/{uid-document}
- GET /milestones/{code}/tracking/certificates/{uid-certificate}/control-first-level/{uid-document}/content
- Improvement in document information associated with an achievement:
- GET /milestones/{code}/tracking/documents
- GET /milestones/{code}/tracking/documents/{uid-document}
It includes:- Origin of the document
- In signed certificate
- Imported at a higher level
- Status of (no) revocation
- GET /milestones/{code}/follow-up/state-revocation
- Confirmation cycle associated with a certificate of (non-)revocation
- GET /milestones/{code}/tracking/certificate-revocation/{uid-certificate}
- Follow-up to the plan
- State transition information for P, SP and SPI.
- GET /projects/{code}/historico-states
- GET /subprojects/{code}/historico-states
- GET /sub-projects-instrumentalities/{code}/historico-states
- Documents
- Endpoint for consultation of uploaded but unassociated documents.
Significant changes from v2.0.4 to v2.0.5
- Milestones and objectives.
- New type of spreadsheet in HGC, HGnC and CID
- New type of document Index of verification mechanisms
- Endpoints for lower node verification mechanisms
- GET /milestones/{code}/tracking/bottom-level/documents
- GET /milestones/{code}/tracking/bottom-level/documents/{uid-document}
- GET /milestones/{code}/tracking/bottom-level/documents/{uid-document}/content
- POST /milestones/{code}/tracking/bottom-level/documents/{uid-document}/import
- DELETE /milestones/{code}/tracking/bottom-level/documents/{uid-document}
- Legal instruments.
- TotalFirstLevel is added in direct and indirect financial legal instruments.
- Corrected Contract Type Code "COSECPUPR - Collaboration between the public and private sectors"
- 9. Proceedings.
- Revision of mandatory fields.
- A new endpoint for changing a legal instrument for action.
- POST /proceedings/{code}/legal instruments/{single-code}/move/{target-code}
- Indicators.
- The field "CumulativeProgress value" returns -1 in the case of having different values in some milestone or objective
- Documents.
- Limited document names to 180 characters
Significant changes from v2.0.5 to v2.0.6
- Legal instruments.
- New field 'Gross equivalent subsidy' for financial beneficiaries of IFD and IFI-type legal instruments
Significant changes from v2.0.6 to v2.0.7
- Progress of indicators.
- New endpoint for differential report editing
- POST /indicator progress/{code}/reports/{uid-report}/change-differentials
- Follow-up to the plan.
- New endpoints for the monitoring of measures
- GET /measures/{code}/tracking/documents
- GET /measures/{code}/follow-up/reports
- GET /measures/{code}/tracking/users
- GET /measures/{code}/follow-up/request-of-responsibility
Significant changes from v2.0.7 to v2.0.8
- Legal instruments
- New endpoints for the edition of IIJJ amounts with historical
- GET /contract/{single-code}/changes
- POST /contract/{single-code}/changes
- GET /convention/{single-code}/changes
- POST /convention/{single-code}/changes
- ...
- Follow-up to the plan
- New endpoints for the monitoring of measures
- GET /measures/{code}/tracking/documents
- GET /measures/{code}/follow-up/reports
Significant changes from v2.0.8 to v2.0.9
- Legal instruments
- Inclusion of payment scenarios in indirect financial instruments
General questions on the v2.0 API
How do I get the single code of a legal instrument?
The single code of a legal instrument is obtained in three ways:
- Discharge of legal instrument: the response of the discharge operation returns the unique code assigned to the legal instrument. For example:
POST /v2.0/contracts - Consultation of legal instruments of an action: the list of legal instruments includes the single code of each legal instrument.
GET /v2.0/actions/{code}/instruments-juridical - Single code consultation: there is a utility in obtaining the single code of a legal instrument on the basis of the code of action and the reference of the legal instrument.
GET /v2.0/instruments-juridical/utilities/single-code
How is the upload of documents carried out?
Document uploading consists of two steps:
- Upload of the document: A new document is added to the system and the locator required for other operations is obtained. The document is created with the PENDING type. Documents uploaded and not associated with an item will be deleted periodically. The service used is:
POST /v2.0/documents - Association of the document with an element: The document raised in the previous point is associated with one element. The association indicates the location of the document, the effective type and the additional metadata. The service used depends on the element, e.g. to add a document to a contract, the service is:
POST /v2.0/contracts/{single-code}/documents
If you want to associate the same document with several elements, you only need to upload the document once and you can use the locator as many times as you need.
Other doubts
I have functional doubts about the management of the Transformation and Resilience Recovery Plan and its management system, where can I turn?
The description of the operation of the Plan is articulated with two Ministerial Orders:
- Order HFP/1030/2021, of 29 September, setting up the management system of the Recovery, Transformation and Resilience Plan.
- Order HFP/1031/2021, of 29 September, establishing the procedure and format of the information to be provided by the State, Autonomous and Local Public Sector Entities for the monitoring of the fulfilment of milestones and objectives and of budgetary and accounting execution of the measures of the components of the Recovery, Transformation and Resilience Plan.
I have more technical doubts about the API, where can I turn?
For further technical questions on the CoFFEE REST API, a message can be written to the support email address@soportesgffee.zendesk.com.