Company Leave Types

This indicates the sequential employee number within their company. This number continues to grow as each employee is onboarded. i.e if you are the 65th employee to join the company with 32 active employees, the employeeNumber would be 65.

This is the unique role ID of the employee. A role ID exists per 1 and only 1 company.

Whether the employee is an international employee or not.

The unique identifier of the employee's manager. This value can be null.

The photo of the employee stored in Rippling

The employee's role status - roleState meanings:

INIT: An initial record of an individual. An offer has not been made and they have not started working at the company.

HIRED: An offer has been made but they have not accepted or started yet.

ACCEPTED: An offer has been made and they have accepted, but they have not started yet.

ACTIVE: The employee currently works at the company and their start date is today or in the past.

TERMINATED: The employee is no longer active.

The small photo of the employee stored in Rippling

An array of the teams that the employee is on

This is the unique user ID of the employee. A userID can span across 1 or many companies.

Employees

Leave Balances

This indicates the system that manages the Leave Request. PTO = managed by Rippling's Time Off app. LEAVES = managed by Rippling's Leave Management app. TILT = managed by third-party partner Tilt.

Allowed values: PENDING, APPROVED, REJECTED, CANCELED

Leave Requests

Rippling HR

Returns the currently accessible company for the given token. Please note, the returned fields depend on the scopes that are enabled for your access token or API key.

GET Current Company

Returns a list of departments for the given company.

GET Departments

Retrieves the list of active employees. The fields retrieved depend on the employee scopes that you have access to for your access token or API key. The only guarenteeed fields include id, personalEmail, and roleState.

For optimal performance, ensure pagination is used via our limit and offset parameters. Pagination should be set to a maximum of 100.

GET Employees

Returns the list of work locations for a given company.

GET Work Locations

Returns the custom fields for the given company.

GET Custom Fields

Retrieves the list of teams for the company.

GET Teams

Retrieves the levels for the company. Levels are set positions for an organization, such as Manager, or Executive.

GET Levels

Retrieves the information for a single employee based on the scopes that your API key or access token have access to.

GET Employee

This endpoint is similar to the active employees endpoint, but instead, it includes both active and terminated employees.

For optimal performance, ensure pagination is used via our limit and offset parameters. Pagination should be set to a maximum of 100.

GET Employees (Including Terminated)

Retrieves basic information about the Rippling user whose access token you're using. This is generally used for the SSO flow.

GET Current User

Please note, the Groups endpoint requires an OAuth application (i.e. approved 3rd party partners), as the end point is intended for mapping third-party application “Groups” within Rippling organizations.

Lists the current third-party groups for an organization.

GET Groups

Creates a generic group, that can be associated within the third-party application.

POST Groups

Please note, the Groups endpoint requires an OAuth application (i.e. approved 3rd party partners), as the end point is intended for mapping third-party application “Groups” within Rippling organizations.

Using the PUT method, all of the group fields will be updated, even if the corresponding parameter is missing. If the PATCH method is used, and a param is missing, its value won’t be changed.

PUT Group

PATCH Group

Please note, the Groups endpoint requires an OAuth application (i.e. approved 3rd party partners), as the end point is intended for mapping third-party application “Groups” within Rippling organizations.

Deletes the specified group.

DELETE Group

Retrieves the current leave requests.The query can be filtered by a number of specific query parameters.

GET Leave Requests

Create a leave request. This endpoint is currently in alpha and should not be used by default. Only TILT managed requests can have a status other than PENDING.

POST Leave Request

Retrieves the current company leave types. The query can be filtered by managedBy field.

GET Company Leave Types

Retrieves the leave balances for employees

GET Leave Balances

Retrieves the leave balances for a given role. A role represents 1 employee. An employee can work at 1 and only 1 company.

GET Leave Balance

Returns a SAML IDP metadata file for the current app integration. Note that this endpoint is only accessible using a token associated with an app integration that has SAML enabled; otherwise it returns a 404 error.

Rippling's SAML Metadata is per customer app installation. It is not the same across all customers. It is not the same if the customer uninstalls and reinstalls your app. Any time a new app is installed, unique SAML Metadata will be generated specific to that app.

GET SAML Metadata

Pushes a candidate from an applicant tracking system directly into the Rippling onboarding flow. Please note, this endpoint is only available to applications integrating with OAuth2.0.

POST New Candidate

Retrieves the activity for a given company.

The most reliable method to ingest all activity from Rippling is to use a pagination cursor via the 'next' parameter. This will ensure that events are not skipped or duplicated due to the lack of timestamp precision.

The general sequence of steps to leverage the next parameter:

1. Issue an initial request using startDate with a value set to some date in the last 90 days
2. Retrieve the next page of events through the next value from the response data.
3. Issue the paginated request
4. Retrieve the next page of events through the next value from the response data
5. Pause and repeat the previous step


GET Company Activity

Approve or decline a leave request. Only pending requests can be processed (approved / declined). Only an admin or manager is capable of taking action on a request.

POST Process Leave Request

PATCH Leave Request

This endpoint can be hit to mark your app as installed in Rippling, if you aren't hitting Rippling's other endpoints on installation. The endpoint does not require any scopes.

Please note, hitting any other endpoint should mark your app as installed as well.

Mark App Installed

Quickbooks

BambooHR

NetSuite

Gusto

ADP Workforce Now

Google Workspace

Workable

Sage HR

Deel

HiBob

# Delete Employee

This scenario allows your application to delete a Employee from any external application. 
You will pass ID of the Employee you want to delete and Integration.app will handle the rest.

## How It Works

1. **Delete Employee API call**:
   - Call Integration.app REST API or SDK with ID of the Employee you want to delete and Integration.app will send the correct request to the external app.


Delete Employee

Deletes Employee in any external application

Workday

Personio

# Continuous Import of Employees to Your App

This scenario enables your application to continuously sync Employees from any external application to your app's API. It handles the initial import of Employees and keeps them synchronized when a Employee is created, updated, or deleted in the external application.

When receiving Employees data from the external application, the data is transformed into a format supported by your app's API. Additionally, if needed, your customers can customize the data mapping based on their specific external application setup.

## How It Works

1. **Initial Import**:
   - Perform the initial import by calling the Integration.app REST API or SDK in a loop from your code to retrieve data page by page.
   - Integration.app transforms the output into a consistent format compatible with your API, allowing you to save the data efficiently.

2. **Continuous Sync**:
   - Enable subscription via a single API or SDK call to continuously receive created, updated, or deleted events.
   - Integration.app manages all integration-specific logic, including subscribing to/unsubscribing from webhooks, custom polling of events, or performing periodic full syncs.
   - You will only receive the necessary events as real-time as supported by the external application's API.

Continuously Import Employees to my App

Import Employees and receive created/updated or deleted events

# Create Employee

This scenario allows your application to create a Employee in any external application in the same way. 
You will pass Employee fields in any format your application support and Integration.app will handle mapping of them to the schema of any selected application.
Additionally, if needed, your customers can customize the data mapping based on their specific setup.


## How It Works

1. **Configuration**:
   - You will setup the schema of fields that you wish to create Employee with and configure mapping to our default model

2. **Create Employee API call**:
   - Call Integration.app REST API or SDK with payload matching the field mapping you configured. You can run it for any external application via the same request.
   - When called, Integration.app transforms your Employee data into a format compatible with the selected external application.
   - It then makes an API call to create the Employee in that specific application.


Create Employee

Creates Employee in any external application

# Realtime Full two-way Sync of Employees

This scenario enables your application to fully sync Employees between your app and any external application in both directions. It handles the initial import/export of Employees and then sends events when a Employee is created, updated, or deleted on any side, as close to real-time as possible.

Employee fields will be mapped from your application's schema to the application-specific schema.

## How It Works

1. **Initial Sync**:
   - Perform the initial import by calling the Integration.app REST API or SDK in a loop from your code to retrieve data page by page. Integration.app transforms the output into a consistent format compatible with your API, allowing you to save and match data efficiently.
   - Make another set of requests to create Employees in external app, if needed.

2. **Continuous Sync from External App**:
   - Enable subscription via a single API or SDK call to continuously receive created, updated, or deleted events from external applications.
   - Integration.app manages all integration-specific logic, including subscribing to/unsubscribing from webhooks, custom polling of events, or performing periodic full syncs.
   - You will only receive the necessary events as real-time as supported by the external application's API.


2. **Continuous Sync from Your App**:
   - You will get a single webhook URI that you will use to send events about created, updated, or deleted Employees to Integration.app.
   - Once send, Integration.app will map the webhook payload to the format supported by external application and send the correct request


Two-way realtime sync of Employees

Bi-directional realtime sync of Employees with records deduplication

# Update Employee

This scenario allows your application to update a Employee in any external application in the same way. 
You will pass  ID of the Employee you want to update and Employee fields in any format your application support and Integration.app will handle mapping of them to the schema of any selected application.
Additionally, if needed, your customers can customize the data mapping based on their specific setup.

## How It Works

1. **Configuration**:
   - You will setup the schema of fields that you wish to update Employee with and configure mapping to our default model

2. **Create Employee API call**:
   - Call Integration.app REST API or SDK with payload matching the field mapping you configured and ID. You can run it for any external application via the same request.
   - When called, Integration.app transforms your Employee data into a format compatible with the selected external application.
   - It then makes an API call to update the Employee in that specific application.


Update Employee

Updates Employee in any external application

# Get all Employees

This scenario enables your application to get a complete list of Employees from any external application to your app's API in the same way. 

When receiving Employees data from the external application, the data is transformed into a format supported by your app's API. Additionally, if needed, your customers can customize the data mapping based on their specific external application setup.

## How It Works

You will call a Integration.app REST API endpoint or SDK methods to retrieve a single page of Employees along with the `cursor` if next page is available.
Repeate this request in a loop from your code to retrieve all Employees page by page.


Field Name	API Key	Type
Path Parameters	pathParameters	object
Employee Id	pathParameters.employeeId	string
Query	query	object
Headers	headers	object

Field Name	API Key	Type	Description
Id	id	string	This is the unique role ID of the employee. A role ID exists per 1 and only 1 company.
User Id	userId	string	This is the unique user ID of the employee. A userID can span across 1 or many companies.
Name	name	string	Full name of the employee
Preferred First Name	preferredFirstName	string
Preferred Last Name	preferredLastName	string

Rippling HR API Integration Profile

GET Employee in Rippling HR API

Build every single integration your customers need with AI