Skip to content
Integrations

Rippling SCIM

Connect Rippling to Paycux, step by step, with the exact values to paste on each side.

Introduction

This guide connects Rippling to Paycux over SCIM. Work through it once per organization — each customer gets their own connection, with its own values.

You configure two sides: the application inside the provider, and the connection inside the Paycux dashboard. Neither side is complete on its own, so keep both tabs open.

What Paycux provides

Paycux generates a SCIM endpoint URL and a bearer token for the directory. Paste both into the provider's provisioning settings:

ValueWhere it goes
SCIM endpoint URLThe provisioning base URL in the provider.
Bearer tokenThe API token the provider authenticates with. Shown once.

The token is per directory. Rotating it in Paycux immediately stops the old token from provisioning.

What you'll need

Before you start, make sure you have the following in place:

  • A Paycux account with access to the project you are configuring.
  • An API key for the environment you are working in. Staging keys start with sk_test_; production keys start with sk_live_.
  • Admin access on the system you are connecting, so you can create the application and read its metadata.
  • A redirect URI registered in the Paycux dashboard under Developer → Redirects.

Set up your Directory Sync endpoint

Directory Sync keeps your user list in step with the customer's directory. Paycux receives create, update and delete operations and normalizes them into a single shape regardless of the source system.

Deletes arrive as deactivations. Treat a deactivated user as a user who can no longer sign in, and decide separately whether to delete their data.

Create your Rippling application

In Rippling SCIM, complete this step before moving on. The values Paycux generated for this connection are on the connection page in the dashboard — copy them from there rather than retyping.

Configure your integration

Configure your integration is configured per environment in the dashboard, so staging and production can differ while your application code stays identical.

Changes take effect on the next request. There is no deploy step and no cache to clear.

Assign users and groups to your application

Assign the users and groups who should have access. Anyone outside the assignment is rejected at the provider, before the request reaches Paycux.

Group names sync as-is. If you use groups to drive roles in your application, map them once in the dashboard under Authorization rather than branching on group names in code.

Frequently asked questions

Frequently asked questions applies specifically to Rippling SCIM. It behaves the same in both environments, and the values it depends on are visible in the dashboard for the environment you have selected.

If the behaviour you see does not match this description, check which environment your API key belongs to before anything else — a staging key against production data is the most common cause.

Can I add additional custom fields to this SCIM integration?

Can I add additional custom fields to this SCIM integration? applies specifically to Rippling SCIM. It behaves the same in both environments, and the values it depends on are visible in the dashboard for the environment you have selected.

If the behaviour you see does not match this description, check which environment your API key belongs to before anything else — a staging key against production data is the most common cause.

Verify the connection

Verify the setup end to end before you hand it to a customer. Run the flow from a private browser window so no existing session masks a broken step.

  1. 1Open the connection in the dashboard and confirm its status reads Active.
  2. 2Start the flow from your application, not from the provider, so the redirect URI is exercised.
  3. 3Sign in as a test user and confirm the profile arrives with an email address.
  4. 4Check the connection's event list — a successful sign-in appears within a few seconds.

Troubleshooting

If something does not work, check these first — they cover the large majority of failed setups:

  • The values were pasted into the wrong environment. Staging and production hold separate configuration.
  • A trailing slash or stray whitespace in the ACS URL or redirect URI. Both are matched exactly.
  • The connection is saved but not activated. An inactive connection returns connection_inactive.
  • Attribute names differ from what the mapping expects, so the user is created without an email address.

Every failed authentication is recorded with a reason on the connection's page in the dashboard. Start there before reading application logs.