In part 2 of the series “Best Practices for API optimization”, let’s continue discussing strategies your app can adopt around optimizing CorePlus API calls. You can review part 1 of this blog post series here.
Leverage cache
With some API calls now subject to fees as part of the Intuit App Partner Program under CorePlus category, it is critical that you review your app’s caching strategies for data pulled from customers’ QuickBooks Online accounts and avoid it from repeatedly hitting our query endpoints.
Some best practices around caching include:
- Store entity data in an in-memory cache with a Time-to-Live (TTL) setting. This ensures that you can reduce frequent reads and at the same time evict stale records for freshness.
- Along with entity details, cache metadata such as SyncToken, LastModified, or LinkedTxn fields, which enables smarter conditional updates without extra read calls.
- When TTL expires, trigger Change Data Capture (CDC) calls or use webhook events to refresh cache entries selectively and hence keep data current.
By intelligently caching both entity information and its associated metadata, apps can serve filtered views of the same data without repeated CorePlus API calls.
Avoid redundant calls
We’ve noticed a common anti-pattern: making redundant calls to fetch data right after creating or updating it, which unnecessarily increases your app’s CorePlus API traffic. Below are some practical tips to avoid redundant read calls immediately after create/update operations.
- After API create/update operations, store the payload in the API response and skip the immediate GET operation.
- Next, cache response payload with a TTL. This prevents immediate redundant reads if another process or view needs the same entity data.
By adopting this flow or implementing your own strategies, your app keeps data coherent and up-to-date across its internal services while preserving CorePlus API quota.
Enhance alerts & monitoring frameworks
While your app might already have its own alerts and monitoring systems in place, you might need to enhance monitoring to catch API usage spikes, especially around the CorePlus API category. Here are some practices you could consider:
- Maintain metrics on API usage per Quickbooks Online companies/realm IDs to help identify which customer accounts are making repetitive or redundant reads.
- Focus on tracking High-volume transactions. Endpoints like Invoice or Customer can generate repetitive reads if not carefully managed so flag these for review. Set baseline normal read/write ratios for such transactions so you can alert on deviations.
- Ensure you set rules for anomalies, such sudden spikes in API calls, periodic background sync jobs fetching empty records, queries retrieving large datasets without filters. Pair each alert with a runbook that routes the app to reuse the write response or a short-TTL cache.
With extensive observability in place, you’ll catch overuse patterns early, preserve your read calls, and keep CorePlus usage predictable as you scale.
Sample architecture
Now let’s design a sample architecture based on strategies discussed in previous sections that focuses on optimizing your app’s overall API traffic.
When a user connects your app to QuickBooks Online (QBO), you need two things to happen reliably: an complete initial data pull that seeds your app with the right information, and efficiently store that data while keeping it fresh so that your app doesn’t keep hitting the Quickbooks Online API endpoints.
Based on your app needs, you can treat the data as needed:
- Use Cache to store Chart of Accounts (CoA), Terms, Tax Codes, and similar “reference” entities don’t change often, but you read them a lot.
- Invoices, Payments, and other high-volume, audit-worthy records belong in your app’s primary datastore. This gives you query flexibility while reducing read calls to QBO.
After the initial data seeding, move to an event-driven sync using Webhooks and ChangeDataCapture.
- When the app receives a webhook event, the app must validate the webhook signature and process the events to extract the changed record IDs. Process webhooks events based timestamp (e.g., read the timestamp field) to update stale data.
- When multiple records of the same type change, fetch them together via the Batch API endpoints to minimize multiple round trip calls.
- Once changed records are fetched, update cache or primary database.
- To compensate for the possibility of missed events – make a ChangeDataCapture (CDC) call.
Conclusion
Reducing unnecessary API reads in QuickBooks Online is important to deliver a responsive, cost-effective app experience for your customers. By combining smart caching with robust monitoring, third-party developers can significantly streamline their API usage while keeping data fresh and accurate.
Note: The strategies discussed in this post are based on general best practices. We strongly recommend conducting your own evaluation before implementation to ensure they align with your app’s needs.