API limits

Be aware of API limits when configuring accounts and building apps

Overview of API limits

What is an API?

API stands for Application Programming Interface. An API is a set of rules and protocols that allows different software applications to communicate and interact with each other. APIs provide defined endpoints, which are application-specific URLs that perform specific actions—such as creating a user, updating data, or retrieving information. By making these endpoints accessible, APIs enable seamless data exchange and operational automation across systems. Most of Middle’s integrations rely on APIs to connect, ensuring efficient data flow between applications.

Why API limits?

Most, if not all, APIs have API limits. These are limits that control how often an API user, can make a call to an application, and how many calls that user can make. Software providers impose API limits to control costs and help limit possible bad actors. API limits can be by the day, by the minute, by the hour, etc. The bottom line is that if you are making too many API calls you will be rate limited and will receive 429 errors.

API costs

Sometimes API users are charged per call. It's important when setting up an API relationship with a software provider to understand what costs are associated with using their API. Oftentimes, APIs are priced at a flat fee for a certain number of calls per day or per month. If the API user exceeds this threshold, they are then billed extra.

How to avoid API limits

At Middle, we want to make sure you are smart about how you use APIs so you don't hit limits and incur unnecessary API charges. This article provides tips on how to maneuver API limits for both account configuration and app development.

App connection syncs

Middle has three sync types:

• Complete transfers: Grab all the data available from an endpoint or external resource.

• Primary key lookups: Request data for a specific record using a primary identifier

• Recent record updates: Syncs data using a datetime range, such as a last modified date

Complete transfers and recent record lookups

Complete transfers and recent record lookups are the most efficient way to get data. They get a lot of data a minimal number of calls. Due to pagination and the amount of data being returned, these syncs can equate to a varying number of API calls. To decrease the number of times recent record lookups and complete transfers are invoked, you can expand the time between syncs in an app's settings.

Primary key lookups

Primary key lookups are the least efficient sync in terms of API calls. When a workflow is dependent on related data you'll want to turn on primary key lookups to maximize workflow reliability. These automatic primary key lookups can rack up a lot of API calls, as they often run once per a record or a small handful of records. When first launching an account it's often a good idea to turn on complete transfers and recent record lookups before primary key lookups to build an initial data set.

Workflow calls

Almost every action in a workflow will make one or more API calls. Workflows that are triggered by a large set of data can lead to a lot of API calls, particularly if a workflow runs several of actions in one execution.

When building a workflow consider if there's a way to limit the number of actions a workflow requires. Lean on data already synced in Middle using related data and changes from the previous record. Always filter out as many records as possible using trigger discard logic and decision nodes before performing an action. Branching of workflows using decision nodes can help keep unnecessary actions from executing.

Manual and bulk executions

Before performing manual syncs and workflow executions, always consider whether the API volume these will generate. The same goes for the configuration of bulk workflow executions.

When building apps

App code has a big impact on API call efficiency and how an app responds when a function is rate limited.

Understand the use case

A clear understanding of the API you are integrating to and the use case is important when developing a Middle app to estimate anticipated API volume.

Sync data in bulk

When building syncs, favor endpoints that enable developers to grab data in bulk. Use these endpoints to develop recent record poll syncs and complete trasnfers

Page size

If possible and stable, you should use the largest page size possible when syncing data from another app. This will likely reduce the number of API calls that are needed to get the data you need.

Bulk primary key lookups

In cases where an API allows a developer to bulk lookup an array of primary keys in a single API call, you should take advantage of this. With this ability Middle will batch a number primary keys to grab missing record.

API limit errors

When a sync or an action hits an API limit the best course of action is to raise a restart to re-queue the sync or action execution for later. This gives the function other chances to complete successfully and hopefully allows enough time to pass for the API limit to suffice.

Do not use sleep to address API limits. When you use sleep this runs up AWS (Amazon Web Services) Lambda time which can result in increased load and cost for your Middle instance. Restarts are the most efficient method to handle 429s.

Sync frequency

When creating a recent record lookup and complete transfer syncs consider the impact of the sync frequency and overlap. High sync frequency increases API calls through more sync function executions. High sync overlap increases API calls by grabbing more data and possibly increasing pagination.

Primary key lookup controls

When to fetch data

Since primary key lookups have the potential to cause large volumes of API calls, Middle provides a number of controls for this sync type. You can toggle under which conditions foreign key lookups should be performed. Options for this behavior include:

• Fetching unseen records only

• Fetching seen and unseen records

• Do not fetch records

Generally, we suggest the "fetch unseen records only" setting. This will limit API calls while ensuring that workflows have the data they need to run.

Fetching seen and unseen records is useful when the record type does not have a sync that reliably picks up on changes and a primary key lookup is the only way to ensure data is up to date.

Batch limits

In situations where batch primary key lookups can be performed, there is a setting that allows you to determine the max number of primary keys per call. A higher number without sacrificing sync reliability will be your best bet for API call efficiency.