Dear customer / partner,
We are continuously improving our Signhost service with new verification methods, performance and keeping it up to date with the latest security standards. We always keep in mind that our API remains 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 two different invalid request types occurring to our API:
- a Content-Type header in a GET request to us
- null values in JSON.
What is a Content-Type header?
The Content-Type entity header is used to indicate the media type of the resource.
In requests, (..such as POST or PUT..), the client tells the server what type of data is actually sent.
Therefore the Content-Type header is only needed to describe the contents of your POST- / PUT-request.
In order to make good use of our service, please ensure that your implementation does not include a Content-Type header for GET-requests.
If you use our .Net- or .PHP library then there's no Content-Type header present for GET-requests.
We've approached customers and partners who use faulty Content-Type headers directly.
In addition, we would also like to inform you that as of Dec 1, no faulty JSON null values are allowed for booleans and integers, because this is not in accordance with the specs.
Only the value of the datatype string will be allowed to be null.