Rippling Worker Sync

Toku keeps its roster in sync with Rippling so stablecoin elections always map to the right person. Rippling models each person’s HR and employment profile as a worker. Sync is read-only and runs automatically after every connection and on a rolling schedule.

Endpoint

Toku reads workers through Rippling’s workers resource:

curl "https://rest.ripplingapis.com/workers" \
  -H "Authorization: Bearer <access_token>"

Individual workers are readable at GET /workers/{id}. A trimmed, representative example response:

{
  "results": [
    {
      "id": "wrk_3f8a1c9e5b21",
      "legal_name": {
        "given_name": "Ada",
        "family_name": "Lovelace"
      },
      "preferred_name": "Ada",
      "work_email": "[email protected]",
      "status": "ACTIVE"
    }
  ]
}

This is representative, not an exhaustive schema. See Rippling’s reference for the full shape: List workers (endpoint-level details require a Rippling developer sign-in).

What Toku Reads

Field	Purpose
`id`	Stable identifier used to match the worker across systems
Legal and preferred name, work email	Roster display and worker-portal invitations
`status`	Marks departed workers inactive in Toku
Compensation (via Rippling’s compensations resource)	Validates election limits against pay

Sync Behavior

New workers appear in Toku automatically once they exist in Rippling.
Updates (name, email, compensation) flow through on the next sync.
Departed workers are marked inactive and stop receiving stablecoin payments.
A manual sync can be triggered anytime from Settings → Payroll Integrations in Toku.

Worker sync never writes to Rippling. Toku does not modify worker records, compensation, or employment state.

Payroll Sync

How Toku tracks payroll runs and pay periods

The Toku Deduction

How the Toku line item is reflected on the pay run

⌘I

​Endpoint

​What Toku Reads

​Sync Behavior

​Next

Payroll Sync

The Toku Deduction

Endpoint

What Toku Reads

Sync Behavior

Next