Retries for Electronic Prescription Service APIs
Find out how to retry without duplicated data for Electronic Prescription Service (EPS) APIs.
To retry an EPS API, you must meet one of the following requirements:
-
you preserve the full request ID, correlation ID and request body
-
you have the ability to recreate the request entirely and precisely for retries with the same request ID and correlation ID (the only thing that may need to regenerate is the authHeader if the old one has expired)
Which HTTP status codes to retry
Any 5xx response should be retried, especially ‘503 Service Unavailable’ and ‘504 Gateway Timeout.
A 400 response should not be retried.
Some other 4xx responses can be retried, for example ‘408 Request Timeout’ or ‘429 Too Many Requests’.
How often to retry
The first retry should happen at least 30 seconds after the initial response.
If there is still an error, there should then be a backoff retry with some delay from the initial retry. You should back off further retries to avoid duplication and give the system a chance to recover from internal errors.
You should decide on the frequency of backoff retries based on message urgency and impact on user experience.
Retries should not be attempted after 30 days because this risks creating duplicate data.
Nominated release retries
For nominated release requests, the retry attempt must be greater than 4 hours and less than 30 day, or validation may fail.
Last edited: 4 July 2025 3:57 pm