Q&A summary of the TED eSender workshop (25 September 2026)  

These consolidated questions and answers have been reviewed and may have been regrouped or modified to provide a more cohesive and complete response. Some answers might no longer be accurate, as the Publications Office (OP) has updated its approach based on feedback. 

The presentation slides as well as the recording of the live session are available in the agenda section. 

Questions from the participants: 

• What are your thoughts about the upcoming legislative changes to the procurement directives, and how will they affect TED SDKs? Will the SDK retain the same technical structure? 

Answer: The idea is to continue using the SDK as has been done for eForms. 

One option for the future direction is to avoid sending a complete notice to TED every time information changes. Instead, it should be possible to submit the missing or updated data categories and link them to information already available in TED, which could be done by having more unique identifiers for business entities. 

For example, if a public summary of a competition has already been published, later award information could be sent with a link to that competition information, instead of repeating all the information again. This should help avoid duplicated information and improve data quality. 

SDK 2.0 is important for this direction, as it supports a move towards validation and consistency checks beyond the isolated notice. More identifiers and links will be needed so that information can be connected correctly across the lifecycle of a procedure. 

The SDK is expected to remain the main vehicle for exchanging structured information. Its overall approach is not expected to change completely, although changes and improvements are expected, in particular around semantic information, ontology alignment and the structures introduced with SDK 2.0. 

The Public Procurement Act proposal is available at: https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1817 

• Will it be possible to submit with SDK 1.15 in Production by mid-October? Why is SDK 1.15 going into Production at the same time as SDK 1.16? 

Answer: SDK 1.15 is already available in Preview. The current target is to make SDK 1.15 available for API submissions in Production by mid-November. 

This concerns API submissions. Front-end users of eNotices2 are expected to move directly to SDK 1.16, while the API will support SDK 1.13, 1.14, 1.15 and 1.16. 

It was clarified that activating SDK 1.15 in Production earlier is not possible due to technical constraints in the OP applications. SDK 1.15 will be activated in Production when SDK 1.16 is also ready and activated. 

The plans have changed compared with earlier roadmaps. SDK 1.15 and SDK 1.16 have both introduced delays of a few weeks, but the current target remains to make the relevant SDK versions available in Production as part of the planned release wave. 

• If plans change at every workshop, why publish a plan? 

Answer: The aim is to be transparent, even when plans later change. Some roadmap items are intentions based on the information available at the time and may need to be adjusted. 

For SDK 1.15, the delay is currently around two or three weeks. SDK 1.16 may also be a couple of weeks later than initially planned, but the work is continuing and the current plan remains to deliver SDK 1.15, SDK 1.16 and SDK 2.0. 

• What would be the lifespan of SDK 1.16 and later versions? 

Answer: SDK 1.15, SDK 1.16, SDK 1.17 and SDK 2.0 are expected to be aligned in terms of lifespan, alongside SDK 1.13 and 1.14, until at least the end of 2027. 

They are expected to remain available until there is a legal requirement to move, in particular through the 3rd amendment to the eForms Regulation. However, eSenders are recommended to stay up to date, as the longer an implementation remains on an older SDK version, the larger the eventual migration gap may become. 

• We use SDK 1.x now. Is it reasonable to skip SDK 2.0 and wait for the directive? 

Answer: This depends on each implementation, resources and planning, but it is not recommended to simply skip SDK 2.0 and wait for the new Public Procurement Act. 

At some point, implementations will need to move to an SDK 2.x version, since future SDK versions after SDK 2.0 will continue in the SDK 2.x line and future business changes will come through later SDK versions. eSenders will need to implement the 3rd amendment to the eForms regulation on SDK 2.x, which could bring eForms closer to what is planned for the new PP Act. 

If an implementation is already planning to move to SDK 1.15 or SDK 1.16, moving to SDK 2.0 can also be considered. The difference between SDK 1.16 and SDK 2.0 is expected to be limited for many implementations, depending in particular on their exposure to EFX. 

 The recommendation is to upgrade SDK versions as soon as this is reasonable for each implementation. 

• Did I understand correctly that the processing of notices is changing and that we will get a new status? 

Answer: The existing notice statuses, such as “Submitted”, and the existing properties will not change. The overall notice lifecycle remains the same. 

An additional property, called processingStatus, is foreseen to be added. This will only apply while the notice is in “Submitted” status and will provide additional information for those who need it. If the existing status is sufficient for your needs, you can continue using it. This is not intended as a breaking change. 

• When will the API endpoint v3/notices/{businessId}/validation-report start returning 404 for successful validations? 

Answer: This is expected around mid-November, together with the same release wave that includes eNotices2, TED Monitor, backend changes and SDK 1.16. 

The relevant eNotices2 release will clean up old successful validation reports and stop storing successful validation reports. After that change, the endpoint will return 404 for successful validation reports that will no longer be stored. 

• Will the new undisclosed group be repeatable, so that one group of fields can have one reason and date, and another group of fields can have another reason and date? 

Answer: There can be repeatable groups of undisclosed fields. This means that different groups of fields can be withheld separately. 

However, only one reason, one description and one potential disclosure date applies to all fields in all groups in the notice. The previous, more granular approach has been removed, as the data showed that even where more granularity was available, users almost always applied the same reason and date to the fields concerned. 

• Do you plan to provide libraries for runtime EFX evaluations? 

Answer: Yes, but not together with the initial SDK 2.0 release. 

After SDK 2.0 is released, the next milestone is to use it for live validation in eNotices2. The plan is to provide JavaScript support for this. The general idea is to have a JavaScript script generator, similar to the current script generator in the toolkit. The generated JavaScript would be shared in the SDK. 

This would depend on a JavaScript runtime in a separate repository, which would be open source and reusable by eSenders. Contributions to that repository would also be possible. 

-

Last update: 20 October 2026