Rippling API rate limits, pagination and query limits

Key takeaways

• Rippling caps REST API calls at 300 requests per IP address every 10 seconds. The limit follows the calling IP address, whichever token or account sends the request.
• Crossing it returns 429 Too Many Requests and starts a 10-second penalty that rejects every request. When the penalty ends, the counter resets to zero in one step.
• Page size defaults to 50 and tops out at 100 rows per request on most endpoints; asking for more returns a 400.
• A pagination loop exits when next_link comes back null.
• A single filter expression is capped at 64 nodes, and Rippling's own worked example counts a simple condition as three nodes.
• expand is limited to two levels and ten fields per request, and a linked object such as a worker's compensation comes back null until you expand it.

Rippling's REST API doesn't fail gracefully when a client asks for too much. It fails all at once: cross the request-rate limit and Rippling rejects every request from that IP address for a full ten seconds, including the one sent in a hurry to compensate.

The instinct is to retry right away. That's exactly the request that lands inside the closed window and fails again, and a job that doesn't know the rule can turn one dropped call into a run that stalls far longer than the ten seconds actually cost.

Rippling puts the ceiling at 300 requests per IP address, per 10-second window. Page size tops out at 100 rows per request, a single filter expression tops out at 64 nodes, and expand stops at two levels and ten fields. Those four numbers, taken together, decide how a sync client has to be shaped.

The table below has each limit with its exact scope and the Rippling documentation page it comes from. The sections after it cover what happens at the rate edge, how pagination terminates, how query size gets counted, and how to design a benefits, payroll or HR-tech sync that stays inside all four limits at once. For how these limits sit alongside authentication and data access, see our overview of the Rippling API.

All four figures are verified against Rippling's developer documentation as of 2026-09-30. Rippling's pages carry no publish or update date, so treat this table as current as of that check.

Every figure applies to Rippling's v2 REST API at rest.ripplingapis.com. Guides built on the older V1 API (api.rippling.com/platform/api) describe offset paging and different endpoints, and Rippling's own developer guidance is to start new integrations on v2.

What happens when a client goes over the rate limit

Rippling counts requests against one budget and works through it in a fixed order:

1. Window: every request from an IP address counts toward a sliding 10-second window.
2. Breach: once a client goes past 300 requests inside that window, Rippling returns 429 Too Many Requests.
3. Penalty: for the following ten seconds, every request from that IP address is rejected, including requests that would have fit the budget.
4. Reset: when the penalty ends, the counter drops straight to zero. The next window opens like a fresh one.

Rippling's rate-limit documentation names the status as 429 Too Many Requests. Treat a 429 as terminal for that call and schedule the retry for after the penalty.

The reset behavior is what makes the naive fix backfire. The counter only zeroes when the penalty ends, so a request sent one second into the penalty gains nothing: the window is still closed, and it fails too. The first retry with a real chance of succeeding goes out after the full ten seconds.

The limit tracks the IP address making the call, not the token or the account behind it. Two sync jobs, or two separate customer integrations, running behind the same egress address draw from a single 300-request window. Authenticating with two different tokens doesn't open a second one. Tokens decide what a call is allowed to see, which is a separate set of rules covered in how Rippling API tokens are scoped and revoked.

As of 2026-09-30, Rippling applies this uniformly: there are no endpoint-specific rate limits. A request to a heavily used endpoint and a request to a rarely used one draw on the same shared budget. The limit is a property of the caller.

How pagination works, with next_link

Two parameters control a page. limit sets how many rows come back. It defaults to 50, most endpoints allow up to 100, and a value above an endpoint's maximum returns a 400. cursor is an opaque token that tells Rippling where the last page left off. A client never builds it; it arrives inside the previous response.

The response carries two fields back. results is the array of rows for that page. next_link is the full URL of the next page, and Rippling's guide says to request it as-is, so a client never reassembles the query string by hand. Rippling's engineering write-up on its API design shows next_link carrying limit, cursor and order_by together.

That shape gives the pagination guide a simple loop:

1. Request: fetch the first page with limit at 100 or less, and no cursor.
2. Process: read results and handle the rows.
3. Follow: if next_link is present, request that URL exactly as returned.
4. Stop: if next_link is null, the last page has been read.

Here is that loop in Python, with the 429 handling from the previous section folded in and a counter that keeps the client under the burst threshold in the first place:

import time
from collections import deque

import requests

BASE = "https://rest.ripplingapis.com"
HEADERS = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/json",
    "Rippling-Api-Version": API_VERSION,  # pin the dated version you tested against
}
BUDGET, WINDOW = 250, 10.0  # headroom under Rippling's 300 per 10 seconds per IP
sent = deque()  # one process only; jobs sharing an egress IP need a shared counter

def throttle():
    now = time.monotonic()
    while sent and now - sent[0] > WINDOW:
        sent.popleft()
    if len(sent) >= BUDGET:
        time.sleep(WINDOW - (now - sent[0]))
    sent.append(time.monotonic())

def list_all(path, params=None):
    url = f"{BASE}{path}"
    params = {"limit": 100, **(params or {})}
    wait = 10  # the penalty is 10 seconds, so never retry sooner
    while url:
        throttle()
        resp = requests.get(url, headers=HEADERS, params=params)
        if resp.status_code == 429:
            time.sleep(wait)
            wait = min(wait * 2, 120)  # exponential backoff, per Rippling's guidance
            continue
        resp.raise_for_status()  # any other 4xx means the request itself needs fixing
        wait = 10
        body = resp.json()
        yield from body["results"]
        url = body.get("next_link")  # None on the last page ends the loop
        params = None  # next_link already carries cursor and limit

for worker in list_all("/workers", {"filter": "status eq 'ACTIVE'"}):
    ...

requests URL-encodes the quotes and spaces in the filter value, which Rippling requires. The throttle() counter only sees one process; jobs that share an egress IP need a shared counter, such as one kept in Redis.

Rippling pages by cursor, which is why the exit condition is next_link being null. Cursor-style pagination stays correct even when records are inserted or deleted between page requests, a case where an offset scheme like page=3&size=50 can skip or repeat rows mid-scan.

Getting the loop right settles how many rows come back. What comes back inside each row, and which rows qualify at all, is governed by a different set of limits.

The limits on filter, expand and order_by

Rippling's query-parameters documentation defines a filter node as one condition: a field, an operator, and a value. Its own worked example doesn't follow that description. first_name = John reads as one condition, and the docs count it as three nodes.

Budget against the worked example, not the prose. At three nodes per simple condition, the documented 64-node ceiling holds roughly 21 straightforward field = value conditions. Quotation marks and spaces inside a filter value also have to be URL-encoded, or the request fails before node counting even matters.

Some data doesn't show up unless asked for by name. When a field points at another object, such as compensation on a worker, Rippling returns the ID with the object itself set to null until the request includes it in expand. A client that never expands anything can be missing data it doesn't know is there.

order_by carries no hard ceiling of its own, but the fields it accepts, id, created_at and updated_at among the common ones, vary by endpoint, and sorting on a field that is itself an object returns a 400. Check a given endpoint's field list before assuming a global set applies everywhere.

Crossing any of these, a filter that's too large, an expand that's too deep, or a field an endpoint doesn't support, returns a 4xx response. Rippling's limits page lists these as a 4xx without naming one code, while the pagination and query-parameter pages name 400 for an oversized limit and an object sort field. Either way, a client should inspect the request and fix it before sending it again.

Designing a sync that stays inside all four limits

Each of these limits is straightforward on its own. A production sync hits all four at once, on a schedule, across however many customer accounts it serves. Design for the combination:

• Calculate the ceiling. At a 100-row page size, 300 requests every 10 seconds per IP address works out to a theoretical ceiling of 30,000 rows every 10 seconds. Treat that as a cap to design under.
• Put every concurrent job on one shared budget. Two sync jobs behind the same egress IP address, even against two different customer accounts, draw from the same 300-request window, so a scheduler has to coordinate across accounts.
• Back off the way Rippling's own documentation recommends. On a 429, stop sending temporarily and use exponential backoff or retry-after logic before the next request.
• Narrow the pull with a filter wherever the endpoint allows it. List workers, for example, accepts filters on status, work_email, user_id, created_at and updated_at, so a scheduled run can ask only for workers updated since the last one.
• Track the window yourself. Rippling's rate-limit documentation describes no response header that reports remaining quota, and the IETF's proposed RateLimit / RateLimit-Policy header pair is still an Internet-Draft. A client has to count its own requests against the 10-second window, as the sample above does.
• Keep every number in configuration. Rippling can change these limits to mitigate abuse, improve performance, or support infrastructure changes, and a threshold buried in code turns that update into a deploy.

Where a unified API changes the polling model

Every rule above is buildable: a rate limiter that respects the 10-second window, a pagination loop that exits on next_link, a filter kept under budget, and a refresh check for when one of these numbers moves. None of it is difficult by itself, but it's one full client for one system, and most products that need Rippling data need several other HRIS or payroll systems built the same way.

Rippling is one of the 110+ HRIS, payroll, ATS and benefits systems Bindbee connects to through one API.

The default model behind that API is a sync that runs once every 24 hours, adjustable, with webhooks that fire when a sync starts, finishes or fails, and when records are created or updated. Your code reads Bindbee's synced copy, so it isn't polling Rippling's REST API on its own schedule. Where a product needs a field or endpoint that model doesn't cover, passthrough makes a raw request directly against the underlying provider API.

Bindbee's API documentation separates the two budgets. Your reads against Bindbee are limited to 200 requests per minute per connector token. The source system's own limit, Rippling's included, governs how fast Bindbee can sync; it shows up as sync duration, and you never receive a 429 from it. Passthrough is the exception to the synced copy: it returns the provider's response untouched, down to the provider's own pagination.

Rate limits are only half of what shapes a Rippling integration. Rippling's API also carries no benefits or dependents data at all, which is covered in where Rippling benefits, dependents and payroll data come from.

The limits documented above don't disappear behind any integration method, unified or not. They're Rippling's rules for calling Rippling. What changes between building the client yourself and working through a connector that already has one is who spends the engineering hours keeping all four budgets (rate, page size, filter size and expand depth) respected on every run.

If Rippling is one of the systems on your integration list, book a demo of the connection.

Frequently asked questions

What is the Rippling API rate limit?

300 requests per IP address in a sliding 10-second window, as of 2026-09-30. Rippling applies it uniformly, with no endpoint-specific limits.

What happens when a Rippling API client gets a 429?

Rippling rejects every request from that IP address for the next ten seconds, including ones that would have fit the budget. When the penalty ends, the counter resets to zero, so the first retry worth sending goes out after the full ten seconds.

Is the Rippling rate limit per token or per IP address?

Per IP address. Two jobs or two customer integrations behind the same egress IP share one 300-request window, even if they authenticate with different tokens.

How does Rippling API pagination work?

Set limit (default 50, up to 100 on most endpoints), read results, and request next_link exactly as returned. When next_link is null, you've read the last page.

How large can a Rippling filter or expand be?

A filter expression is capped at 64 nodes, and Rippling's own example counts a simple condition as three nodes, so budget for about 21 conditions. expand is limited to two levels and ten fields per request.