-
Notifications
You must be signed in to change notification settings - Fork 40
The link to the preview swagger doesn't work.
https://docs.ted.europa.eu/api/latest/convert.html#_swagger_api_endpoints
https://api.preview.ted.europa.eu/swagger-ui/index.html#/Conversion/convertNotice
On the other hand, we are trying to test the stop-publishing operation in preview (API V3) but it doesn't seem to work correctly.
If it does not find the notice to stop, it returns a correct response:
{
"code": "notice.NOTICE_NOT_FOUND",
"message": "No notice found with businessId=f33ed95e-f72a-4d66-a94c-1db75e64a033 and versionId=03",
"showDetails": false
}
But if the notice exists, it gives us a timeout:
POST /v3/notices/33a43de7-41f1-4d39-af48-ff726e74ac29-03/stop-publication HTTP/1.1
Mon Jun 30 12:30:14 CEST 2025:ERROR:java.net.SocketTimeoutException: Read timed out
Is there a problem with the preview swagger (API V3)?
What about the stop-publication operation in preview (API V3)?
Thanks in advance,
Alex
All reactions
Dear Greta,
Our team is actively investigating the issue with the stopPublication endpoint. We appreciate your patience and cooperation as we work to resolve this matter.
To provide more context, our initial findings indicate that:
-
In the Preview environment, the stopPublication endpoint works as expected when the notice is not in a workflow error state. However, when a notice is in a workflow error state, the endpoint times out and returns a 504 error. -
In the Production environment, the stopPublication endpoint generally functions correctly, but in rare instances, it may return a 500 Internal Server Error. Although the notice is effectively stopped, its status is not updated correct...
Replies: 3 comments 1 reply
Hi, the Preview Swagger issue is now fixed.
Regarding stop publication: there’s an issue with stop requests timing out for notices in workflow error, which we’re currently investigating. We’ve also received your request via the Helpdesk and will provide a detailed reply there.
Thanks for your patience!
All reactions
Hello,
We’ve noticed an issue with the stopPublication endpoint. On the preview environment it doesn’t seem to work at all, and on production we are getting 500 Internal Server Error responses.
image
This is quite important for us because of how our system works, as it relies on this endpoint as a compensatory mechanism.
Could you please confirm if there is still an open issue being investigated?
Best regards,
Greta
All reactions
Dear Greta,
Our team is actively investigating the issue with the stopPublication endpoint. We appreciate your patience and cooperation as we work to resolve this matter.
To provide more context, our initial findings indicate that:
-
In the Preview environment, the stopPublication endpoint works as expected when the notice is not in a workflow error state. However, when a notice is in a workflow error state, the endpoint times out and returns a 504 error. -
In the Production environment, the stopPublication endpoint generally functions correctly, but in rare instances, it may return a 500 Internal Server Error. Although the notice is effectively stopped, its status is not updated correctly in the list of submitted notices (via GET /v3/notices).
We are committed to resolving these issues and ensuring that the stopPublication endpoint operates reliably in all scenarios. We will keep you informed of our progress and appreciate your understanding as we work to address these issues.
Best regards,
Stefan
All reactions
-
👍 1
Dear @greta-pavlova,
We would like to provide an update on the issue previously reported with the stopPublication endpoint.
Following the latest release, the behaviour of the endpoint has been improved both in terms of reliability and error handling.
In particular, when a notice cannot be stopped because it is in a workflow error state, the API now returns a clearer response instead of timing out. For example, in such cases the endpoint returns 403 Forbidden with a structured response such as:
{
"code": "notice.NOTICE_CANNOT_STOP",
"message": "Notice with business id [28465e90-eb83-4efe-ab0c-d016488df725-01] cannot be stopped because it is in workflow error in our internal system, awaiting manual review by our operators. Please try again later (in a few minutes).",
"showDetails": false
}
Other error situations are also returned with the appropriate HTTP status codes, as documented in the Swagger/OpenAPI specification, for example when the notice does not exist or is not accessible, or when the notice is temporarily locked due to concurrent processing.
If you receive a 403 response because the notice is in workflow error, or a 423 response because it is temporarily locked, please retry after a short delay. If the problem persists, please contact us with the relevant business ID.
We have also addressed the issue where, in some error scenarios, the status returned by GET /v3/notices did not correctly reflect the notice’s actual state after a stopPublication request.
The status returned via GET /v3/notices should now be consistent with the outcome of the stopPublication request, including cases where the notice cannot be stopped and the API returns an appropriate error response.
Best regards,
Stefan
All reactions
-
🎉 1