Shopify
Platform
Also known as: Shopify Security Rejection, Shopify 430
Uses the non-standard 430 for security rejections so that it stays distinguishable from 429 rate limiting, which is a genuinely useful separation.
Shopify's edge protects a very large number of independent storefronts, so its responses show up constantly in commerce integrations. Shopify made a deliberate and unusually helpful choice: it separated rate limiting from security rejection by giving them different status codes. 429 means you are going too fast. 430 means the security layer rejected the request.
430 is not a registered IANA status code. Shopify uses it for security rejection, and it is also documented elsewhere as Request Header Fields Too Large, so the number alone is ambiguous outside a Shopify context. Inside one, it is a clear signal.
Because the two codes mean different things, they call for different responses, and conflating them is the common failure. Backing off will eventually clear a 429. It will not clear a 430, because nothing about waiting changes what the security layer objected to.
How to identify it
- A 430 status from a *.myshopify.com host or a storefront on Shopify infrastructure.
- Shopify's _shopify_y and _shopify_s analytics cookies on ordinary traffic.
- x-shopid, x-shardid, or x-request-id response headers.
Headers
- x-request-id: Per-request identifier. Worth capturing when opening a support conversation about repeated rejections.
Cookies
- _shopify_y: Long-lived visitor identifier used for storefront analytics. Marks a Shopify storefront rather than any bot verdict.
- _shopify_s: Session-scoped companion to _shopify_y.
Status codes
430 Security rejection
Blocked. Observed behaviour.
Shopify's security layer rejected the request. Distinct from rate limiting, which Shopify signals with 429.
What triggers it
- Request patterns that trip bot-detection heuristics, such as high volume from one address or identical repeated requests.
- Missing, inconsistent, or rapidly rotating client identity.
- Traffic from data centre address ranges.
How to confirm it
- The 430 status itself, which nothing else in a normal commerce stack returns.
What to do about it
- Do not treat it as a rate limit. Backing off is the right answer to 429 and the wrong answer to 430, and the two need separate handling in your retry logic.
- Where Shopify provides an official API for what you are doing, use it. Programmatic access through a supported API is both more reliable and less likely to be rejected than scraping the storefront.
- Stabilise your client identity. Rapidly rotating identifiers are themselves one of the flagged patterns.
HTTP/2 430 content-type: text/html; charset=utf-8 x-request-id: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
429 Rate limited
Rate limited. Documented by the vendor.
Request rate exceeded. This is Shopify's rate limiting code, and it is the one that clears with patience.
What triggers it
- Exceeding a storefront or API call budget.
- Bursting past a leaky bucket limit on the Admin API.
How to confirm it
- retry-after where present, and API call limit headers on Admin API responses.
What to do about it
- Honour Retry-After. Shopify's guidance is to back off exponentially, and its APIs publish remaining call budget so you can pace against the real limit rather than guessing.
If you run a site behind it
- The 429 and 430 split is a genuinely good pattern worth copying. Callers can build correct behaviour without parsing a body, which is exactly what status codes are for.
If your traffic is being caught by it
- Branch your retry logic on the two codes. Treating them the same guarantees you handle at least one of them wrong.
- 430 is not in the IANA registry, so some HTTP clients and frameworks handle it oddly. Check that your stack surfaces it rather than collapsing it into a generic error.