We tightened how the API checks requests. Most integrations need no changes. Check the list below if you sign requests, send the access key in more than one place, or pass long lists of request patterns.
Signed requests must use GET
Signed requests were always documented as GET only, because the signature covers the query string and not a request body. A POST request is now rejected with the signature_is_not_valid error when it carries a signature, or when its access key requires signing. Unsigned POST requests with a key that doesn’t require signing work as before.
One access key per request
You can send the access key in the access_key parameter, in the request body, in the X-Access-Key header or as a bearer token. A request that carries two different keys is now rejected with the access_key_invalid error instead of using one of them. Sending the same key in several places still works.
Clearer invalid access key errors
When an access key starts or ends with whitespace, or contains characters that an access key never has, the access_key_invalid error now says so. This often happens when a key is copied together with a line break or a quote.
Up to 100 request patterns
The lists of patterns for blocking requests and for failing when a request fails accept up to 100 patterns each. A longer list returns the request_not_valid error. Matching the patterns is also faster: before, some patterns could slow down rendering.
