{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidlp5mr4gpbyacgzgl5sjfvxukf2hmmdiglqyslcp75cb2nkb5ese",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mokxbsf4pfx2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiaafpfcuzratwocqawjsggt5kc5bpqdl2vo4sbfjc6bfjyzn4oley"
    },
    "mimeType": "image/webp",
    "size": 306768
  },
  "path": "/masadashraf/how-i-cut-our-shopify-api-usage-in-half-without-losing-features-48cd",
  "publishedAt": "2026-06-18T13:26:25.000Z",
  "site": "https://dev.to",
  "tags": [
    "shopify",
    "api",
    "graphql",
    "webhooks",
    "Reducing Shopify API Consumption Costs"
  ],
  "textContent": "If you build on Shopify long enough, you hit the wall. Throttled requests. Stalled inventory syncs. Webhook backlogs piling up during a flash sale.\n\nShopify does not charge you per call in dollars. It charges you in rate limits. Blow through them and your app slows to a crawl. The real cost shows up as engineering time, infrastructure bills, and lost sales from stale data.\n\nHere is what actually moved the needle for us.\n\n##  First, know what you are paying for\n\nShopify uses two rate-limiting models depending on the API.\n\nAPI | Model | How it works\n---|---|---\nREST Admin | Leaky bucket | Fixed requests per second\nGraphQL Admin | Query cost | Points based on complexity\nStorefront | Query cost | Higher limits, complexity-based\n\nThe GraphQL model is your friend here. You pay for what you ask for. Ask for less, pay less.\n\n##  Move from REST to GraphQL\n\nThis was our biggest single win. REST makes you stitch together multiple calls to get related data. GraphQL gets it in one.\n\nFetching an order with its line items, customer, and shipping in REST:\n\n\n\n    // REST: 4 round trips\n    const order = await fetch(`/admin/api/2024-01/orders/${id}.json`);\n    const customer = await fetch(`/admin/api/2024-01/customers/${custId}.json`);\n    const lineItems = await fetch(`/admin/api/2024-01/orders/${id}/line_items.json`);\n    const shipping = await fetch(`/admin/api/2024-01/orders/${id}/shipping_address.json`);\n\n\nThe same thing in GraphQL:\n\n\n\n    # GraphQL: 1 request, only the fields you need\n    query GetOrder($id: ID!) {\n      order(id: $id) {\n        name\n        customer { firstName lastName email }\n        shippingAddress { address1 city zip }\n        lineItems(first: 50) {\n          edges { node { title quantity } }\n        }\n      }\n    }\n\n\nOne request. No over-fetching. Lower cost.\n\nThe trap: people migrate to GraphQL and then request every field anyway. Don't. Every field adds to your query cost. If you only need a title and price, do not pull variants, images, and metafields.\n\n##  Stop polling. Use webhooks.\n\nPolling is the silent budget killer. An app that checks for new orders every few seconds burns thousands of calls a day, and most return nothing new.\n\nWebhooks flip it. Shopify pushes the event the moment it happens.\n\n\n\n    // Instead of polling every 5 seconds...\n    app.post('/webhooks/orders/create', verifyWebhook, (req, res) => {\n      const order = req.body;\n      queue.add('process-order', order); // hand off, respond fast\n      res.sendStatus(200);\n    });\n\n\nTwo things to get right:\n\n  1. **Respond fast.** Acknowledge with a 200 immediately, then process async. Shopify retries if you are slow.\n  2. **Expect duplicates.** Shopify sometimes sends the same event twice. Use an idempotency key so you do not fire redundant follow-up calls.\n\n\n\n\n    async function handleEvent(event) {\n      const key = event.id;\n      if (await seen(key)) return; // already processed\n      await markSeen(key);\n      await process(event);\n    }\n\n\n##  Use Bulk Operations for big data sets\n\nPaginating through 50,000 products with standard queries shreds your rate limit. The Bulk Operations API runs the whole thing async and hands you one file.\n\n\n\n    mutation {\n      bulkOperationRunQuery(\n        query: \"\"\"\n        { products { edges { node { id title } } } }\n        \"\"\"\n      ) {\n        bulkOperation { id status }\n        userErrors { field message }\n      }\n    }\n\n\nApproach | Calls | Rate limit hit\n---|---|---\nStandard pagination | Hundreds to thousands | High\nBulk Operations | One operation | Minimal\n\nPoll the operation status, download the JSONL when done, process locally.\n\n##  Cache the stuff that does not change\n\nA surprising amount of API traffic fetches data that is stable for hours or days. Product descriptions. Collection structure. Store settings.\n\nData | Cache? | Why\n---|---|---\nProduct descriptions | Yes | Rarely changes\nCollection structure | Yes | Stable\nStore settings | Yes | Infrequent changes\nLive inventory | Carefully | Changes constantly\nOrder status | Short TTL | Updates often\n\nInvalidate on the relevant webhook instead of guessing at TTLs.\n\n##  Handle rate limits like an adult\n\nEven a lean app hits limits sometimes. Read the headers Shopify returns and throttle before you crash.\n\n\n\n    async function callWithBackoff(fn, retries = 5) {\n      for (let i = 0; i < retries; i++) {\n        const res = await fn();\n        if (res.status !== 429) return res;\n        const wait = Math.pow(2, i) * 1000; // exponential backoff\n        await new Promise(r => setTimeout(r, wait));\n      }\n      throw new Error('Rate limited after retries');\n    }\n\n\nCentralize this in a middleware layer so every call gets the same treatment. Do not scatter retry logic across your codebase.\n\n##  The checklist\n\nTactic | Impact | Effort\n---|---|---\nREST to GraphQL | High | Medium\nRequest only needed fields | High | Low\nBulk Operations API | High | Medium\nCache stable data | High | Medium\nWebhooks over polling | Very High | Medium\nBatch requests | Medium | Low\nSmart rate limiting | Medium | Medium\nDeduplicate calls | Medium | Low\nAsync processing | Medium | High\nMonitor usage | High | Low\n\n##  Start here\n\nIf you do nothing else: replace polling with webhooks, switch to GraphQL with trimmed queries, and cache stable data. Those three alone cut our usage roughly in half.\n\nThen layer in batching, async jobs, and monitoring for the long game.\n\nI wrote a longer version with deeper architecture notes on our blog: Reducing Shopify API Consumption Costs. Happy to answer questions in the comments.\n\nWhat is the worst API throttle situation you have run into? Drop it below.",
  "title": "How I Cut Our Shopify API Usage in Half (Without Losing Features)"
}