Requests & idempotency
Requests and responses
Section titled “Requests and responses”Every response of an operation carries X-Request-Id; send your own (letters, digits, _ and -, up to 64 characters) to have it echoed back, otherwise one is generated. Quote it when contacting support. A request body over 65536 bytes is 413 payload_too_large; upload_image takes up to 5242880 bytes, for a file in data; a file PUT to a create_image_upload_link link is at most 3145728 bytes.
Idempotency
Section titled “Idempotency”POST operations accept an Idempotency-Key header. Makes a retry of a POST safe: a repeat with the same key, body and GSC-Version returns the stored response with Idempotency-Replayed: true instead of running again. The key protects against repeated execution while the key store works. Saving the change and storing the response under the key are not atomic: if the process or the key store fails between them, the change is kept, the key is released after 15 minutes and a retry runs the request again. After a timeout or a 5xx, read the resource to check the result before retrying. 5xx and 429 responses and responses over 256 KB are not stored, so a repeat runs the request again. A key is kept for 24 hours. The same key with another body or version is 422; a repeat while the first request runs is 409. The reasons are idempotency_key_reused (422) and idempotency_in_progress (409). When keys cannot be kept, a request with a key is refused with 503 temporarily_unavailable.
Source: OpenAPI specification. Paths that start with /v1 are on https://api.getsitecontrol.com.