Connecting Shopify: the Admin API counts points, not requests
This integration does not exist until someone has it built. We have no app in any app store, we are not a Shopify partner, and there is no store where this is already running. What does exist is Shopify’s own documentation, and it describes a model that differs from what accounting packages do: it is not the number of requests that counts, but what each question costs in computation. Understand that, and you also understand why a webshop integration is built differently from an accounting one.
Published on
Does this integration already exist?
Status of this integration: on request. Concretely: it has not been built, it is not installed in any store, and there is no demo to show. If you want it, that starts with the intake call rather than with an install button. What building it takes in time is something we state only once it is clear which questions it must answer — that differs enough per store to rule out a standard answer.
What the rest of the site says about this, it says consistently: integrations are custom work and follow the intake call. What an AI colleague does do today is handle email and WhatsApp Business. So everything below describes what an integration would require, not something sitting ready.
How Shopify bounds usage of the Admin API
| Mechanism | What Shopify documents about it |
|---|---|
| Way of limiting | On calculated query cost: you look at the cost of requests over time, not at their number |
| What the limit is tied to | To the combination of app and store; calls from one app do not affect another app’s limit |
| Limit on paging through | Pagination through arrays of objects stops at 25,000 objects |
| What travels with every request | An access token that authenticates the app and carries the scopes deciding what it may see |
| Available from Novot AI? | On request — there is no app, no installation and no Shopify partnership |
Points instead of requests, and why that changes the build
Shopify writes that calls to the GraphQL Admin API are limited based on calculated query cost, and that you should therefore look at what requests cost over time rather than at how many there are. Underneath it is a bucket that drains a little every second: a heavy question drops more into it than a light one, and once the bucket is full you get an error until room frees up again.
For customer contact that works out well, provided you ask precisely. "What is the status of order X" is one targeted query. "Give me every order this quarter with all their line items" uses the same API but a multiple of the points. An integration built the first way never notices the limit; one built the second way notices it every morning at eight.
The limit is tied to app and store, which is good news for your existing apps
Shopify ties the GraphQL Admin API limit to the combination of app and store: calls from one app do not affect another app’s rate limit, even in the same store. That is the exact opposite of a throttle per IP address, where everything speaking from one place shares the same budget.
In practice: your shipping tool, your review system and your accounting connector do not slow down because something new joins them. What you give up for it is that every integration has its own token and its own scopes, and therefore its own upkeep. An access token authenticates the app and carries the scopes that decide what it may retrieve; Shopify enforces those on every request and returns only what they allow. That makes the question "what may this integration see" answerable without reading the code — you read it off the scopes it was installed with.
What a webshop question actually needs, and where to stop reading
The questions arriving in a webshop are strikingly predictable: where is my parcel, can I still change size, is this delivery address still right, how do I return something. Answering those takes one order, not the whole catalogue and not the whole customer base.
On top of that, Shopify limits pagination through arrays of objects to 25,000 objects. That is a technical boundary pointing in exactly the same direction as the legal one: retrieve what the question needs and no more. An integration that starts with "fetch everything, then filter" runs into both boundaries, and hardest into the second.
That also shapes how a conversation is built. The AI colleague has to work out from the message which order this is about — an order number, an email address, a name with a date — before anything is retrieved at all. Skip that, and it becomes a search engine through your store, which is precisely what you do not want to build.
What we need to know about your store before anything gets built
- The questions your customer service looks up most often in the Shopify admin, and roughly how many times a day that happens.
- Which apps are already installed in the store, so we do not build something that already exists.
- Who on your team may install apps and approve scopes — that is a decision about access, not about technology.
- Whether you have several stores: each store is its own installation with its own keys and its own limit.
The order in which we work is described in our approach. What is not there and is here: a webshop integration only makes sense once the status question really is the most frequently asked one. In many webshops it is, but not in all — in a store that mainly sells advice rather than parcels, the conversation is about sizes, materials and suitability, and the order will not help you there.
What applies legally once an integration pulls personal data out of a package — retrieve no more than you need, and record who the controller is — is set out in AI and the GDPR for SMEs. Which channels an AI colleague serves with us is covered on the channel page about email.