The documentation for this API call shows an example response that includes an expires_on value, 2014-01-01T05:20:00.12345Z. Today the API call currently deviates from this format, retuning dates like, 2019-04-15 16:27:00 +0000 UTC. This is breaking the official Go SDK (see issue 190) and client integrations. Either the documentation and Go SDK are incorrect, or the service API is breaking the contract. However, in this case since there are likely multiple parties coded to the observed contract (what the service is doing now) the only backwards compatible path forward is to publish an additional expires_on_X field that includes the date in the documented format.
1 Like
Good find. The format specified would be ISO 8601 and even though it seems to require T as a separator it appears as if 2019-04-15 16:27:00 was still a valid string (as well as 2019-04-15 16:27:00+0000) but the returned string is not (particularly because of the space between the time and timezone).
Is this the preferred bug reporting channel? Iād love to have feedback from the CF team.
These things always take a bit of pushing. Cloudflare doesnt seem to be all too active on their Github pages and even here it often requires nagging to an extent that it borders pestering.
2 Likes
Another month. Broken API is one thing, but having no real bug reporting channel is a problem.
This is probably being worked on. I upload a custom cert to one of my domains and got an email only this week that the time format reported by that api endpoint was changng to be in line with what you request. So there seems to be movement around standardizing those formats.