Reference · built on requestConnectorHR, scheduling & workforce

Rippling

Workers, users, leave requests, schedules, and time entries from Rippling through the v2 REST API at rest.ripplingapis.com.

Request accessPricing ↗

About

Rippling combines HR, IT, and finance on one employee graph. Its v2 REST API at https://rest.ripplingapis.com exposes workers and users, departments and work locations, compensations, leave types, balances and requests, schedules and shift assignments, time cards and time entries, and custom objects, with dated versions pinned by the Rippling-Api-Version header. The older V1 API at api.rippling.com is legacy and not for new work.

An operator on Fibric reads the worker roster, leave, schedules, and time entries, and proposes a leave request, a time entry, or a shift assignment for your approval. Every proposal is recorded with its reason and its undo.

This is a reference listing. It documents what Fibric would read from Rippling and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Workers, the employment records, and users, the person profiles, expanded through GET /workers?expand=employment,compensation
  • Departments, work locations, legal entities, and companies through the Organizational Data endpoints
  • Leave types, leave balances, leave accruals, and leave requests under the Time API
  • Schedules, shift assignments, and unassigned shifts, plus shift inputs, time cards, and time entries
  • Worker change events, hires, field updates, and offboardings, through GET /worker-changes with applied_on and effective_on timestamps
  • Kiosk badges for the timeclock

Proposed actions

  • Target capability: propose a leave request through POST /leave-requests, or an update to one
  • Target capability: propose a time entry or shift input, created or corrected through the Time & Attendance endpoints
  • Target capability: propose a shift assignment, or assigning a worker to an unassigned shift
  • Target capability: propose a draft hire that follows Rippling's review and approval policies
  • Target capability: propose a record in a custom object, after describing the object's fields

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Fill an open shift from people who are actually available

    Read unassigned shifts, leave requests, and time cards, then propose which worker to assign and post the assignment on approval.

    With Open Shift Offer, Shift Coverage

  • Stop overtime before it is worked

    Sum time entries against the schedule as the week runs and propose a shift change or a cutoff message before hours cross the line.

    With Overtime Guard, Intraday Balance

  • Offboard on the day the record says

    Poll worker changes by applied_on, catch hire and offboarding events including future-dated ones, and propose the access removals for IT to confirm.

    With Offboarding Sweep, Access Offboarding

Requirements

  • A Rippling account and a token owner whose permission profile covers the workers in scope, for example The entire company
  • Scopes selected on the token for each endpoint, such as workers.read, leave-requests.read-write, time-entries.read, and schedules.read
  • The Worker Changes API entitlement, enabled through your Rippling Technical Account Manager, for the change feed
  • A pinned Rippling-Api-Version date so responses do not shift under you
Authentication
A Bearer API token created in Tools > Developer > API Tokens for your own company, or OAuth 2.0 for an app installed from the Rippling App Shop; a token carries the intersection of its owner's permission profile and its scopes.

Limits

  • A burst threshold of 300 requests per IP in a sliding 10-second window; exceeding it rejects every request for the next 10 seconds
  • Pages hold 50 records by default and 100 at most; expand goes two levels deep and a filter may carry 64 nodes
  • A token is revoked when its owner is terminated or it goes unused for 30 days, and ownership cannot be transferred
  • Fields the token owner cannot see come back as null or REDACTED rather than as errors

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Rippling ↗

Questions and answers

Should I use the v2 REST API or the V1 API?
The v2 REST API at rest.ripplingapis.com. Rippling's documentation says not to start new integrations on V1 at api.rippling.com unless a resource exists only there, and maps V1 paths such as /platform/api/employees to v2 /workers or /users.
Why does a field come back null?
Usually because the token cannot see it, not because it is empty. Access is the intersection of the owner's permission profile and the token's scopes. Check __meta.redacted_fields, confirm the owner can see that data in the product, and add expand for nested objects.
Does Rippling push webhooks to outside systems?
Webhooks to a third-party URL are documented for apps installed through the App Shop, with events such as employee.created, employee.updated, employee.hired, employee.terminated, and leave requests, delivered with a lag of about five minutes. A company's own token-based integration polls, for example the worker changes feed.
Ask about Rippling

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Rippling through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy