Exception codes for when legacy data don't exist in R5.1 reports
04 August 2025In a recent post we described how a publisher should signal that it has moved from Release 5 to Release 5.1 in their COUNTER API (sushi) responses, using Exception code 3031. Today, we’ll describe the other side of the story: how to tell your users that older data aren’t available in R5.1, and that they need to request the information in legacy R5 format instead.
This situation is quite common for publishers who became compliant with R5.1 at the start of 2025, and chose not to retrofit older data into the new system. That choice is completely compliant with R5.1, provided the older data remains available in an R5 reporting tool. Publishers who’ve chosen this option must refer users trying to access their older data to the R5 system.
Fortunately, the Code of Practice offers a ready-made solution in the form of Exception 3032. The short message for 3032 is “Usage No Longer Available for Requested Dates”, and 3032 is commonly used to signal that the data being requested is too old. The longer textual description of 3032 makes it clear that the Exception also covers this our migration use case. It read “The service does not have the usage for one or more of the requested months because the requested begin_date is earlier than the first month for which data has been processed and is available.” To make the response even more explicit, publishers can add a Data element to their text which has more detail.
{
"Code": 3032
"Message": "Usage No Longer Available for Requested Dates"
"Data": "[Publisher] has transitioned to R5.1 from [YYYY-MM] onwards. Older data is available using R5 reports. See [registry record] for details."
}
It is even more important than usual not to use an incorrect Exception in this situation. Exception 3030, for example, means “No Usage Available for Requested Dates”. Delivering 3030 instead of 3032 suggests that there is zero usage to report, which could be quite misleading!
More information about errors and exceptions
We’ve published a couple of other posts about handling errors and exceptions recently. You can find them at: