Rippling benefits, dependents and payroll data: API vs SFTP

Key takeaways

• As of 2026-09-30, Rippling's public REST API scope list covers workers, users, compensation, leave, time and org data, but includes no benefits, dependents or payroll scope.
• Two tokens on the same Rippling company can return different worker data, because results depend on the token's scopes and the creator's permission profile.
• Benefits: Rippling's public statement on benefits connectivity, a product overview dated 2023-10-25, describes carrier connectivity, moving enrollment data out to insurers, not a read endpoint for platforms.
• Dependents: no public endpoint is documented, and any feed still has to carry relationship, date of birth and plan link, because a child's coverage eligibility runs until age 26 under federal rule.
• Payroll: Rippling's REST API overview lists a Payroll category (payroll runs, earning types, worker payroll records), but its guide sits behind a Rippling login.
• Rippling's documented file mechanism is a REST upload with a 24-hour URL for documents going into Rippling. Its developer docs have no SFTP specification, and SFTP itself only specifies transport.
• Bindbee reads Rippling benefits and dependents through its Rippling SFTP connection. Payroll also comes through SFTP, or in beta through a legacy connection on Rippling's older V1 API.

Rippling's developer portal reads like one door into a shared customer's account. Walk through it looking for benefits or dependents data, though, and the door doesn't open. A token scoped correctly returns full worker records in a single call. The same shape of request for benefits enrollment has nowhere to go: no such endpoint or scope appears in Rippling's public developer documentation, and dependents inherit the same gap.

As of 2026-09-30, Rippling's public developer documentation describes one programmatic channel for new work: a bearer-token REST API on rest.ripplingapis.com. Its published scope list covers workers, users, compensation, leave, time entries and org structure. It lists no benefits-enrollment, dependents or payroll scope, and the developer portal carries no SFTP specification.

This page walks that gap object by object: what's documented for workers, what's established for benefits, what dependents data needs to carry regardless of channel, where payroll sits, what SFTP would and wouldn't settle, and which connection delivers these objects through Bindbee.

The channel map

Here's how the objects break down in Rippling's public documentation, checked 2026-09-30:

The first row is the only one with complete public documentation behind it, so it's worth knowing what that documentation commits to before treating the rest of the table as gaps to route around.

Worker and compensation data: the documented floor

Rippling's HRIS API is the part of this stack that's fully written down. The GET /workers endpoint returns worker records under the workers.read scope, and Rippling's HRIS getting-started guide walks through authentication, filtering, and expansion for it directly.

Two tokens created for the same company can still see different data, though. What a token returns depends on the scopes selected when it was created and on the creator's own permission profile (how that intersection works). A token built by someone limited to basic personal data won't surface compensation fields, whatever scopes you request.

The endpoint filters on status, work_email, user_id, created_at, and updated_at, and expands into user, manager, legal_entity, employment_type, compensation, and department. Pagination defaults to 50 records per page and caps at 100 (how to page through it inside Rippling's rate limit), and a worker's status moves through INIT, HIRED, ACCEPTED, ACTIVE, and TERMINATED.

curl -G 'https://rest.ripplingapis.com/workers' \
  --data-urlencode "limit=100" \
  --data-urlencode "expand=compensation" \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer '

Beyond HRIS, the public reference also documents leave, time entries and org structure such as departments, teams and work locations. Benefits is where it stops, and it's also the object with the oldest paper trail.

Benefits data: what's public, and what isn't

Rippling's public statement about benefits connectivity comes from a product overview, not the developer docs, and it's dated 2023-10-25: Rippling describes support for EDI, API and carrier-specific forms across major insurance carriers.

That establishes carrier connectivity, meaning Rippling can move enrollment data outward to insurance carriers. It doesn't establish that a third party can read enrollment data back through a documented endpoint, and no such endpoint or scope appears in the public developer reference. Those are two different claims, and the marketing copy only makes the first one.

The EDI Rippling refers to is a format built for carrier transmission. If you need to understand what that specific format covers, our breakdown of the enrollment file handles it separately.

Benefits enrollment and dependents data travel together in practice, since a dependent's coverage is usually tied to the same enrollment record. The next question is what happens to dependents specifically.

Dependents data: the fields that can't go stale

Rippling's public developer documentation shows the same gap for dependents as for benefits: no dependents endpoint or scope is documented.

The gap matters more here than it does for most objects, because dependent eligibility changes on its own schedule. Under 45 CFR 147.120, a plan that offers dependent coverage has to keep a child eligible until they turn 26, and can't restrict that eligibility based on financial dependency, residency, student status, marital status, or employment. Our guide to dependent coverage under 26 covers the rule in full. A feed missing the right fields doesn't break on day one; it breaks the month a dependent ages out and nobody's data said so.

Whatever channel eventually carries this data, three fields have to survive the trip intact:

• Relationship to the covered employee, since eligibility rules differ for a spouse, a domestic partner, and a child
• Date of birth, since it's what triggers the loss of eligibility at 26
• The plan or coverage tier the dependent is attached to, since eligibility runs per plan

Dependents drive deductions once they're enrolled, which is where this stops being an HR question and starts being a payroll one.

Payroll data: a documented category behind a login

Rippling's REST documentation isn't silent on payroll. Its public API overview lists a Payroll category, separate from the HRIS guides, covering payroll runs, earning types and worker payroll records.

The Payroll getting-started guide, though, redirects to a Rippling sign-in page, and the public scope list checked on 2026-09-30 shows no payroll scope. What that category exposes, and to which accounts, has to be confirmed inside a Rippling developer login. If payroll data matters to your build, check it there before you plan around it.

Rippling's older V1 API (api.rippling.com) included a Payroll API, and third-party guides built on V1 still circulate. Rippling's developer guidance is not to start new integrations on V1 unless the resource exists only there, so treat V1 payroll as a legacy path.

Confirming what the Payroll category covers still leaves a separate question open: how data moves once you know it's available, whether that's the API itself or a file a customer proposes sending you by SFTP.

Files and SFTP: what transport does and doesn't settle

Rippling's Files API is its documented file mechanism, and it runs in one direction: into Rippling. A request creates a placeholder and returns a temporary upload URL good for 24 hours, the file is capped at 100 MB, and a confirmation call closes the loop. It's scoped to documents, such as an offer letter attached to a draft hire, and has nothing to do with recurring data exports.

If a customer instead proposes sending data over SFTP, it's worth knowing what that word commits them to. SFTP was never published as an RFC. The version almost everyone implements, v3, is defined in an IETF Internet-Draft that expired in April 2002 and was never finalized. What it specifies is file-system access over an SSH channel: how to list, read, write, and delete files remotely. It says nothing about what's inside the file.

Agreeing to SFTP settles transport and authentication. Field names, record layout, delimiter, encoding and delivery cadence all still need working out separately, the same way they would over an API.

Rippling's Help Center is the other place a customer-specific file feed might be documented, and it's gated: as of 2026-09-30, search results there for API, payroll, benefits, dependents, or SFTP all resolve to a login page rather than an article.

Benefits, dependents, and payroll still have to come from somewhere. The remaining question is how to get them without building three separate one-off connections.

Closing the gaps

Three things are true at once here: workers, time and org data are documented; benefits and dependents aren't; and payroll sits behind a login. The gaps sit in what Rippling has published, and asking more carefully won't close them.

Three paths close these gaps, and they mostly differ in who owns the mapping work afterward:

• Ask the customer's Rippling admin, or Rippling's own partner team, for a benefits or payroll feed built specifically for that account, since both objects have the thinnest public trail
• Build directly against the documented worker scopes, confirm whatever the Payroll category allows in your own account, and handle field mapping and refresh yourself
• Use a unified API that already reads benefits, dependents and payroll from Rippling through a connection built for them

The third option is where Bindbee sits. For Rippling, Bindbee runs three connections, and the one your customer sets up decides what you get:

For benefits and dependents, the answer is the SFTP connection; neither API connection reads them. For payroll, SFTP is the full route, and the legacy connection reads payroll runs in beta.

Two things follow from that. Freshness follows your customer's export schedule, and coverage is capped by what the export includes: a field that isn't in the file can't be fetched, and widening coverage means the customer changing the export. A delivery that quietly stops also looks like frozen data, with no failed sync to flag it, so check each record's modified_at on a schedule.

Once the data lands, it arrives in the same unified models Bindbee uses for every other system. Where a field sits outside those models, Custom Fields maps it through JMESPath, and Passthrough sends a raw request to the underlying provider API. Passthrough only reaches what Rippling's API exposes, so it won't recover benefits data the API doesn't carry.

API connections sync on a 24-hour default that's adjustable, and webhooks fire when a sync starts, finishes or fails and when synced records change. Bindbee holds the credentials your customer grants and syncs through them.

Dependents and benefits data carries real compliance weight (coverage tiers, life events, the age-26 rule from earlier), so handling matters as much as access. Bindbee is HIPAA compliant, SOC 2 Type II and ISO 27001 certified, and GDPR compliant, and a BAA is available. For a closer look at how dependent and beneficiary records move once they're unified, see the dependent and beneficiary data sync use case.

If you're weighing this against a direct build for a specific Rippling customer, book a demo to confirm which Rippling connection covers your benefits, dependents, and payroll objects before you commit to a build.

Frequently asked questions

Does the Rippling API return dependents?

Not through any documented endpoint. As of 2026-09-30, Rippling's public REST API scope list has no dependents scope, so dependents data has to come from another channel, such as a file export your customer sets up.

Can I read Rippling benefits enrollment through the API?

Rippling's public developer documentation lists no benefits scope or endpoint. Its public benefits material describes sending enrollment data out to insurance carriers, which is the opposite direction from a platform reading it.

Does Rippling support SFTP?

Rippling's developer documentation has no SFTP specification; its documented file mechanism is the Files API, for uploading documents into Rippling. File exports out of Rippling are set up per customer, which is how Bindbee's Rippling SFTP connection receives data.

Does the Rippling API include payroll data?

Rippling's REST API overview lists a Payroll category covering payroll runs, earning types and worker payroll records, but its guide sits behind a Rippling login and the public scope list checked on 2026-09-30 shows no payroll scope. Confirm what it exposes inside your own Rippling developer account.

Which dependent fields does a benefits feed need to carry?

Relationship to the employee, date of birth, and the plan or coverage tier the dependent is attached to. Under 45 CFR 147.120 a child stays eligible for dependent coverage until age 26, so a missing date of birth breaks eligibility quietly.