Thanks @Liam ! We’ve been getting more error status codes as well. To some extent, it’s caused by this issue in the Shopify Admin Python SDK. Our workaround is to fetch only a subset of orders with each API call.
Topic summary
Surge in 430 (Shopify Security Rejection) responses on Admin REST and Storefront GraphQL APIs, especially for server-side rendered (SSR) headless storefronts and s2s apps, despite using the Shopify-Storefront-Buyer-IP header.
Recent context: After Shopify’s Aug 2023 change touting “no rate limits” on Storefront API, partners report stricter bot protection and more frequent 430s. Several note 430s arrive without a Retry-After header and can occur even at low traffic.
Observed behavior: 430s appear tied to IP-based or broader network heuristics (Cloudflare suspected), not per-credential limits. Some report random first-try failures (e.g., createDraftOrder). This conflicts with Shopify docs stating per-store/API-key rate limits.
Tried mitigations:
- General: request optimization, caching, queuing/throttling (limited help for mutations like carts/checkout).
- Admin SDK issue workaround: fetch smaller subsets of orders.
- Networking: moving away from shared IPs; using static/dedicated egress via VPC connectors. Some saw 430s vanish after recreating a VPC connector; others still see 430s even with a static IP, hinting at route-based factors.
Status: No official fix. Support responses mixed; guidance focuses on reducing calls. Open questions: reliability of Buyer-IP header, presence of Retry-After for 430, and whether enforcement is IP vs credential-based.