Summary: We are improving our API security. This message is relevant if you use our API.
18th of January we will phase out allowing invalid Accept headers to be communicated to our API. Please check your implementation for adhering to the http internet standards and our documentation. Sending an Accept header for a message type we cannot and never could deliver will stop working. We are not changing our API or removing backwards compatibility, but will strictly interpret API messages conforming to security specs.
Full message:
We are continuously improving our Signhost service with new verification methods, performance and keeping it up to date with the latest security standards. We are always striving to keep our API backwards compatible as we document it on https://api.signhost.com.
However, in the API so far we have always accepted requests that differed from what we have documented, as well as some requests that did not meet the HTTP standard and/or JSON. API requests that do not meet the standards are not supported by us.
Because we want to be able to keep rolling out new features and we don't want to jeopardize the safety of our product, invalid requests will not be accepted anymore. What has changed:
If there is a correct API implementation that adheres to internet standards such as HTTP/1.1 (RFC2616), ISO8601 and our documented Model types and properties then nothing will change. Our API remains as it was for you. We do not introduce a new version, the current version v1 will continue to work as it is. There is no v2 version of the API.
For reference version 1.1 of the HTTP standard can be found at https://www.w3.org/Protocols/rfc2616/rfc2616.html and is still supported by us. Use the Model types and properties as documented and don't rely too much on example requests / responses.
We see a number of different invalid request types occurring to our API: - a Content-Type header in a GET request to us, when you send us content of a whole differerent type (eg. JSON instead of PDF) - null values in JSON - Invalid Accept headers, where a type of message is requested which we cannot and never could deliver. (eg. docx. when requesting a signed pdf.)
What was done? Our initial test of phasing out the Accept header workaround was reverted due to some unforseen issues on December the first. Null values where succesfully phased out. Invalid Content type GET requests will be phased out fully later in 2021. This will be communicated on this channel. https://status.signhost.com/incidents/dr9lg69z0w1q
We have contacted customers who we suspect sending incorrect Accept headers, and advise all our API customers to double check a correct Accept header implementation.
Not sure what to do? If you do not specify an accept header, we are unrestricted in our response to your request and no issues will arise.
An easy way to test your outgoing headers is through a webhook test endpoint such as webhook.site.