Rippling: Create a new background check candidate

← rest_api operations · Get started · OpenAPI downloads

Contract 2026-10-28 · Operation rippling.rest_api.create_background_check_candidates

Provider route: POST /background-check-candidates/. Alter supplies the connection’s credentials and routing.

Call through Alter

Install @alter-ai/sdk @alter-ai/rippling with npm, or alter-sdk-rippling with pip. Supply your connected customer’s grant ID and the arguments described below.

import { App } from "@alter-ai/sdk";
import { RipplingIntegration } from "@alter-ai/rippling";

async function execute(input: Parameters<RipplingIntegration["restApi"]["createBackgroundCheckCandidates"]>[0]) {
  const app = new App({ apiKey: process.env.ALTER_API_KEY! });
  try {
    const provider = new RipplingIntegration(app, { grantId: process.env.PROVIDER_GRANT_ID! });
    const call = await provider.restApi.createBackgroundCheckCandidates(input);
    const result = await call.wait();
    return result.bodyJson();
  } finally {
    await app.close();
  }
}

import os
from alter_sdk import App
from alter_sdk_rippling import RipplingIntegration

async def execute(arguments):
    async with App(api_key=os.environ["ALTER_API_KEY"]) as app:
        provider = RipplingIntegration(app, {"grant_id": os.environ["PROVIDER_GRANT_ID"]})
        call = await provider.rest_api.create_background_check_candidates(arguments)
        result = await call.wait()
        return result.body_json()

Input

Field	Type	Presence	Description and constraints
$	object	Root	Additional keys: not allowed
body	Model	Optional	Expand Update a background check candidate — request body — body

Referenced models: Update a background check candidate — request body — body

Response

Response media type: application/json. The table describes the pinned successful response. Referenced models link to their complete fields.

Field	Type	Presence	Description and constraints
$	object	Root	Background Check Candidate DTO. Represents a candidate who has been submitted for background check screening. Required on Create (but nullable on read for legacy rows): - email: Required for new candidates, but may be null on read for legacy rows - external_id: Required for new candidates, but may be null on read for legacy rows Optional Fields: - owner_id: May be null if no provider is associated - first_name: May be null if name is not available - last_name: May be null if name is not available - middle_name: May be null if not provided Sensitive Fields: - first_name, last_name, middle_name: Name fields are PII marked as sensitive in the model - These do not require separate OAuth scopes beyond the resource-level scopes (background-check-candidates.read / .read-write) because they are not updating role or worker data, only storing candidate names for background check processing Note: first_name, last_name, and middle_name are NOT filterable. Only external_id, email, created_at, and updated_at support filtering.
created_at	string	Optional	The timestamp when the candidate was created.
email	string	Required within parent	The email address of the candidate. Required on create, but may be null on read for legacy rows.
external_id	string	Required within parent	The provider’s unique identifier for the candidate. Required on create, but may be null on read for legacy rows. Can only be set once (during creation or when null). Cannot be changed after being set.
first_name	string	Optional	The first name of the candidate.
id	string	Optional	The unique identifier of the background check candidate.
last_name	string	Optional	The last name of the candidate.
middle_name	string	Optional	The middle name of the candidate.
owner_id	string	Optional	The ID of the background check provider (OAuth spoke owner).
updated_at	string	Optional	The timestamp when the candidate was last updated.

Policy, approvals and errors

SDK function policy ID: rippling.rest_api.create_background_check_candidates. Catalog operation: create-background-check-candidates. Rules can name either ID; function rules distinguish managed calls and conservatively cover raw calls sharing the route. Existing grant permissions and policy rules apply. wait() returns an immediate result or waits for a required approval; it never approves the request itself. Persist the approval ID to resume after a restart.

Provider errors retain their response; JSON decoding raises ProviderAPIError for provider failures. ManagedOperationError identifies contract/input/retention errors. See error handling and provider-specific behavior. Sensitive input may be refused before approval storage. A decoding error never resubmits a write.

Required provider scopes: ["background-check-candidates.read-write"]

Provider entitlements: ["Background_Check_Platform_API"]

Pinned headers: {"Rippling-Api-Version": "2024-08-01"}

Official provider source