API Connector Pulse Call Limits: Quotas by Tier and Planning Tips

Every Pulse Hawklist recovers for your store is logged in the Stream, and the API connector is the programmatic door into that Stream: your own spreadsheets, internal dashboards, and scripts can read the recovered purchase data instead of copying it by hand. That door checks a key every time you open it, and the key usage is metered in calls per day. On the Starter free tier you get 100 calls a day, on Growth you get 1,000, and on Pro the read side stops being metered at all. Merchants who understand those limits before they build a reporting routine avoid the failure mode where a script works fine on day one and then starts failing mid-month as volume climbs. If you are mapping where the connector fits in a full tracking setup, the complete Shopify conversion tracking guide covers the pillar picture of capture, recovery, and delivery; this guide zooms into the one piece that article leaves for the integration layer: what a call is, what the tiers allow, and how to plan your usage so the quota never becomes the reason your report is blank.

The Quick Answer

The API connector lets your own tools read the recovered Pulse data from the Stream, and each read request counts against a daily quota that depends on your plan. Starter, the free tier, allows 100 calls per day and also caps recovered volume at roughly 500 Pulses per month. Growth at $29 per month lifts the quota to 1,000 calls per day and removes the Pulse volume cap. Pro at $79 per month replaces the daily cap with unlimited read calls. Scale at $199 per month keeps the unlimited-read behavior and adds the Hawk assistant and multi-store management for agencies. A call is one request that pulls Pulse data; polling several times per hour with retries heavy enough, a small store can cross 100 calls by late morning, while a nightly single pull uses one call per day. The practical planning rule: match your pull frequency to how fast the data actually changes for your decisions, page only through what you need, and make retries deliberate rather than automatic so the quota covers the reads that matter.

What Is the API Connector?

The API connector is a shipped Hawklist capability that exposes your recovered conversion data for programmatic access. When Shopify order webhooks and storefront activity are converted into Pulses and delivered to Meta CAPI or Google Ads, each delivered Pulse is recorded in the Stream, the live log of recovered purchases. The connector is the read side of the recovery engine: it answers requests from systems you operate, and it returns the Pulse records exactly as they were logged, including delivery status per Channel.

The scope is worth stating plainly, because merchants often mistype the connector for something else.

It is not an ingestion path. Pulse capture runs on the shipped webhook and storefront snippet layer, which sits inside Shopify and sends order completions, abandoned checkouts, and full-funnel moments to the signal engine without touching the browser where blockers and privacy controls operate. You do not need the API connector to recover conversions. It exists after recovery, for the consuming side.

It is not a reporting destination either. The Overview, built around the ROAS dashboard, revenue trend, and Clarity Score, already answers the questions most teams ask daily. The connector exists for the questions that live in a specific tool your team already runs: the finance model in a spreadsheet, the client wrapper in an agency’s own portal, or a script that pings a manager when Pulse volume relative to Shopify orders drifts.

The vocabulary keeps this straight: Shopify sends, Hawklist recovers, the Channel delivers, the Stream records, the API connector reads the Stream. Each step is separate, and the quotas apply only to the last step.

The Call Limits by Tier

The quota is tied to the pricing tiers, which are published and current:

Tier	Price	API connector allowance
Starter (free)	$0	100 calls per day
Growth	$29/mo	1,000 calls per day
Pro	$79/mo	Unlimited read calls
Scale	$199/mo	Unlimited read, plus assistant and multi-store

Three things in that table drive most planning mistakes, so take them one at a time.

First, the Starter allowance of 100 calls per day is a hard daily number, and the free tier separately caps recovered volume at roughly 500 Pulses per month. The two caps interact. A store doing a few hundred recovered orders a month has a data set small enough that one daily pull reads everything new, and 100 calls is comfortable. A store that grows past that volume hits the Pulse cap first, and rising call usage on top of it is usually a sign the read pattern, not the data set, needs redesign.

Second, Growth’s 1,000 calls per day is roughly ten times the free allowance, which is enough for several pulls per hour around the clock, plus retries and a second consumer on top. Teams that collide with this number are usually polling two systems at one-minute intervals against the same Stream, or looping reads that page through the full history repeatedly.

Third, Pro’s unlimited-read line means the meter stops mattering. No Pro team ever loses a report to a daily quota, which changes how you design consumers: you can check data more often than feels strictly necessary because the frequency decision is about freshness only, never about budget.

The pricing detail matters because the mechanical ceiling a team hits is informative for the upgrade decision. If a store’s ideal pull pattern takes 300 calls a day, the free tier will fail it by design, and the cheapest correct answer is Growth rather than redesigning the read logic down to 100 calls. If the ideal pattern is unknowable because the store has never measured its change rate, the next section provides the measurement.

What Counts as a Call

A call is one request your system sends through the API connector to read Pulse data. The metering model is per-request, so the consumption math follows directly from how the consumer is built.

Keep the metering model in mind: each request your tool makes, whatever it asks for, is one call. That single rule produces most of the practical outcomes.

Two design choices in the consuming system decide where the count lands. The first is frequency: a script that reads once per hour is one of 24 calls per day, and a script that reads once per minute is 1,440, which no tier will welcome and which the data does not need.

The second is breadth: a read scoped to the last hour’s Pulses is one call with a short answer, while a read of the full historical Stream forces the connector to page through and answer everything on record. Pagination multiplies consumption whenever the consumer re-reads data it already had. The structural habit that keeps the count sane is incremental reading: store the last-read timestamp or order ID, request only the newer records, and let each day’s 100 or 1,000 calls cover new Pulses rather than repeat old ones. Repeatable full-history reads on a schedule are the single consumption habit that no quota survives indefinitely.

One caution on the free tier specifically: at 100 calls per day, any background job that fires every fifteen minutes consumes 96 of them, and a single unplanned redeploy or duplicated consumer that day exhausts the allowance. That is why the step-by-step section later pushes for measuring the data’s change rate before choosing any fixed interval.

Why It Matters for Your Shopify Store

The stakes are data availability in the tools your decisions are made in, and the failure arrives quietly rather than loudly.

Consider the typical setup. Julian Juenemann of MeasureSchool has documented 40 to 60 percent client-side pixel loss for the average Shopify store, concentrated in Safari and ad blocker users. Hawklist’s recovery engine exists to close that gap and feed Meta CAPI and Google Ads the complete record. The Overview then shows delivery health, but the finance and merchandising layers of many businesses read from somewhere else: an exported sheet reviewed during the weekly call, a margin model in a spreadsheet, or a script that compares Shopify order counts with Pulse counts and alerts on drift. Every one of those integrations reads from the Stream through the connector, and every read spends the quota.

When the allowance runs out, the read fails, and the downstream effect is a report with a hole in it, discovered during the meeting rather than before it. A store that runs a consistent Pulse-per-day script against a 100-call daily budget and then adds a second consumer for a client is not doing anything wrong; it simply outgrew the tier. Because the cap is daily and resets, the symptom can appear intermittent, stronger on busy days, and the audit trail points the other direction entirely.

There is a second, subtler reason the limits matter for planning volume: recovered Pulse volume itself grows with match quality improvements. When Match strength rises and identity gaps close, more of the orders you already record in Shopify arrive in the Stream as fully matched Pulses, which enlarges the data set your consumers read. Growth in the good direction still consumes quota, and that needs space in the plan rather than surprise weeks after a fix lands. Stores that work the recovery checklist and re-audit monthly see exactly this cascade: more recovered Pulses, more reads across more reports, tighter quotas on lower tiers.

Root Cause 1: Polling Cadence Sized to the Wrong Interval

The most common way stores waste quota is polling far faster than the data division ever changes, on an interval inherited from an example rather than measured from the store.

An automation exported from an integration guide often nudges every few minutes, which is a safe default for the integration engineer and a costly default for a merchant needing a margin report refreshed at one.

Each read against an unchanged Stream still counts as a call. A reduction of the polling interval from five minutes to one hour with the same consumer drops daily consumption from 288 calls to 24, and nothing on any report changes, because recovered Pulses arrive continuously through webhooks as orders happen rather than on the pull schedule. The cadence only decides how fresh the copy in your tool is, not how complete the data on record is.

What interval is right, then, arrives from the consumer’s tolerance for staleness, not from the integration mechanics. A margin sheet refreshed once before the daily standup needs a pull cadence of one per day, whatever its size. A client-facing dashboard arguing for a team’s budget during the working day earns an hourly pull. Almost no consumer, on a Shopify store, makes a case for a pull every minute.

The cheapest diagnostic along these lines is to compare the count of Pulses returned by two consecutive polls spread an hour apart on a normal day. If the hour between them adds, say, 30 Pulses midday and none overnight, the correct polling cadence tracks the shape of that curve: a corresponding mid-afternoon pull, a lighter morning pull, and no late-night repeated schedule at all.

Stores that think through this shape once usually settle on a cadence several times sparser than their original script, and the resulting headroom stays until store volume doubles.

Root Cause 2: Retries and Re-Reads After a Failure

The second amplifier of consumption is the retry, and the way a read consumer is written will either spend it or not.

When a read fails mid-response, some systems re-issue the retry immediately, in a tight loop, until the response arrives. During that loop, every attempt is a call. When a read errors on a busy code path, a loop that re-issues several times per minute for several minutes can burn through an entire day’s budget against a free tier before anyone sees the diagnosis. The correct form is deliberate: when reading again, wait plainly rather than tighten, and cap the number of attempts. Pull only the subset that failed, page by last-read position, rather than the whole day again.

The related amplifier is re-reading data already in hand. A consumer that reloads the full recent history at every run re-reads the whole record each cycle and multiplies consumption with daily volume. The alternative is incremental reads anchored on the last position, a pattern that also keeps a failure cheap to repair: the fix reaches forward from where the last success stopped rather than re-issuing everything. Rate-limit discipline exists independently of Hawklist quotas, and the general case is universal, but here there is an exact number attached to getting it wrong.

The saving grace is that the reads in question are covered by the shipped delivery layer: Pulse delivery to Meta and Google runs through the Channel, retries on the delivery side are handled by the capture design as a brand-new read of the same record. When the connector request lives nowhere near the conversion path, a failed report pull is stopped, not the reporting, and nothing about ROAS delivery or attribution is affected by your consumers.

Root Cause 3: Reaching for API Pulses Where the Webhook Layer Already Ships Data

The third trap is architectural, and the confusion between the word webhook and the word call shows up in buyer questions frequently enough to warrant its own section.

Shopify marks its own transaction paths as webhook-native: order creations, abandoned checkouts, and storefront moments travel through webhooks. Hawklist’s shipped capture layer reads those webhooks plus the snippet-on-storefront activities, converting each into Pulse events that then travel to the Channels. Shopify’s own developer documentation describes this design, including its webhook delivery layer providing order data without a custom integration asking for it. The capture design is server-side from Shopify’s machinery, meaning ad blockers, Safari ITP, and iOS ATT restrictions cannot drop the record on the way in, and Meta Business Engineering materials have documented how much volume this path can recover.

The API connector, then, is not the fourth path after three attempted ones. It never carries the Pulse into Hawklist, and it never carries the Pulse to a Channel. Reading the Stream after the data has arrived is the only thing it does.

Because of that architecture, keeping the read tier honest never risks data delivery. A consumer that read-polls the Stream and fails keeps Shopify orders flowing into Meta and Google on the same schedule the Channel is already configured for, and a merchant auditing reruns of a reporting script is never also auditing their ad delivery for the same moment. That separation is structural, not coincidental, and it is one of the quiet advantages of the capture-versus-read split in a signal layer design: problems can be in one half without being in the other.

For teams asking which path to use to move conversion data out of Shopify, the honest answer is the one the shipped layers already attend to, and the read side exists for a margin sheet, not for Meta.

How to Plan Usage Before the Quota Bites

The quota conversation ends the same way every time if the store has never measured its own read behavior, so the useful move is to make the measurement first. Run the sequence once, write the numbers down, and revisit after any material change to store volume or consumers.

1. Inventory every consumer. List the spreadsheet, the client wrapper, the scripts, and anything else reading the connector, noting each one’s interval and scope. Two consumers double the per-day budget that any single plan must carry.

2. Measure the true change rate. Note Pulse counts returning from a few polls on a normal day, hourly, and find the parts of the day where additions happen. This gives an honest interval decision rather than a felt one.

3. Match cadence to consumers, not machinery. Write down the staleness each one actually tolerates, and set the intervals from that. Cheap and cheerful wins: pulling daily for a weekly sheet, hourly for a dashboard. Under this rubric, most stores land on 25 to 50 reads per consumer, each day.

4. Make the retry deliberate. Cap attempts per failure, delay rather than tighten between them, and make the retry narrow rather than comprehensive. A re-read loop that spends a budget without improving anything is the amplifier no report needs.

5. Total the numbers. Add daily reads across consumers plus expected retries. At 100 calls per day, the Starter free tier carries one to two light consumers; at 1,000 calls per day, Growth carries several running at hourly cadence; at unlimited reads, Pro removes the ceiling entirely. Exhibit the number and check it against the tier table above before any new consumer ships.

6. Watch the metric, not the quota. Weekly checks on reads versus the quota, in the same review as Clarity Score and Pulse volume, catch the climb weeks before the report comes up empty. Guide that review toward the abandoned checkout Pulse and its Missed window mechanics at the same time, since read consumption tends to climb alongside recovered order volume in the weeks identity fixes land.

FAQ

What exactly are the API connector call limits?

Starter, the free tier, allows 100 calls per day. Growth at $29 per month raises that to 1,000 calls per day. Pro at $79 per month replaces the cap with unlimited read calls, and Scale at $199 per month keeps unlimited read while adding the Hawk assistant and multi-store management. Each call is one read request against the Stream.

What happens when I hit the daily quota?

Reads through the connector stop succeeding until the allowance resets. Nothing else moves: Pulse capture from Shopify webhooks continues, Channels keep delivering, and the Stream keeps recording. Only the external consumer is affected, and a report built on it shows a gap for the rest of that day.

Does the quota affect delivery of Pulses to Meta or Google?

No. Delivery is a separate shipped layer running through Meta CAPI and the Google Ads Channel, fed by the Shopify webhook layer. The API connector reads the Stream after delivery; it neither carries conversions to the platforms nor interrupts delivery when its quota is spent.

How often should my script pull from the Stream?

Match the interval to how stale the data in your tool can be: once daily for a weekly review sheet, hourly for a dashboard in use during business hours. Pulse data changes continuously as Shopify orders arrive, so polling faster than your consumer’s tolerance just spends calls without changing any report.

Can I use the API connector to send conversions to Meta?

No. The connector is a read path for recovered Pulse data. Conversions are delivered server-side by the Channel layer, through Meta Conversions API and Google Ads, on the shipped webhook and storefront capture. If you are building a second delivery path from scratch, read what the second conversion Channel for Shopify covers first, since delivery mechanics and identity requirements differ per platform.

Does the 500 Pulse per month cap apply on the free tier alongside the call cap?

Yes, and the two caps are independent. Starter covers roughly 500 Pulses per month of recovered volume and 100 API connector calls per day. A store can bump into one before the other, so check which limit is binding when planning, not just the read side. For teams verifying what each recovered Pulse carries, the CAPI event quality checklist walks the identity and formatting fields end to end.

Related Resources

• Read the Shopify conversion tracking guide for how the Stream sits inside the full capture, recovery, and delivery flow.
• Work through the abandoned checkout Pulse and Missed window guide for how recovered volume grows when identity gaps close.
• Check the CAPI event quality checklist for what a recovered Pulse carries into Meta and Google before your read layer consumes it.
• Read adding a second conversion Channel for Shopify to understand the delivery side the API connector does not provide.