Restrictions¶
Overview¶
This is a high level overview and explanation of the restrictions put in place by the default terms of use agreement.
Before using the APIs please make sure that you've read and understood the restrictions laid out in the page. If you have any questions or concerns please let us know at [email protected].
The restrictions put in place by the terms of use are primarily to ensure that data accessed via the APIs is used in accordance with the licencing agreement. Some restrictions are also put in place to protect security and provide resiliency.
Access Locations¶
The Spec Check APIs are intended to be accessed server-to-server. The APIs should never be accessed directly by end-user browsers or mobile devices.
Direct access to the APIs for development purposes is allowed.
Storage¶
Permanent storage of any data returned via the APIs is a breach of the terms of use. There are two exceptions to this rule; caches and mappings.
Caches¶
Building performant applications without utilising caching is exceptionally difficult, as such we do allow data to be cached in RAM for up to 24 hours, after this time data must be refreshed.
Mappings¶
There is no restriction on the storage of identifiers and keys where used as a mapping.
For example, if in your own system you have machines and would like to match them against results from the APIs, then there is no problem with storing the machine id, variation id, or revision id.
An example that would not be permissable however is storing an attribute value for later reference.
Redistribution¶
All forms of redistribution of the data must be discussed before implementation to ensure they are covered by your specific licence agreement.
Rate Limiting¶
Rate limiting measures are in place to protect the APIs - initially a limit of 1,500 requests per hour will be placed on each API key, this limit operates over a rolling 1 hour windows, and can be increased once the APIs have been accessed.
When a request is rate limited the server will response with a 429 - Too Many Requests response. In the response headers there will be a value for Retry-After, this value will be given in seconds and client applications should wait at least this length of time before attempting to reconnect.
Ad-hoc rate limiting may also be used if the APIs are subject to heavy loads to protect from loss of service.
Exceptions¶
If required exceptions can be made to the restrictions above where there has been agreement with Spec Check. In these scenarios an amendment to the terms of use will be agreed upon, this may include additional restrictions.