Skip to main content
POST
← Employees API Add employees to the directory of the commuting survey: a name, an email or both, and whether they still work there. Nothing is calculated, so the request is synchronous (see how bulk ingestion works): it answers 201 Created with the created employees. It also records an ingest job, born completed, that sends no webhook. An employee has no emissions until their commuting periods are known: send them with Create Commuting Periods (v2), or collect them with the commuting survey. This route never sends an email: no survey goes out when an employee is created.
Beta. Part of the bulk ingest API, in beta. The contract may still change before general availability.

How it works

  1. Every record is checked: it has an email, a name or both, and its email is free. An email is unique in the organization, without regard to case: one that an employee of the organization already has, or that another record of the request has, rejects the record. If any record is invalid the whole request is rejected with 422 and nothing is created (all or nothing): rejected is the number of invalid records and errors lists them (up to 100).
  2. Every employee is created in one transaction and returned, in the order sent, with status: loading (as the app’s import does) until their commute is known. source_row_index is the position of the record in records, and client_row_id echoes yours.
  3. The employees belong to the x-organization-id organization. A record cannot name another one, not even one of your perimeter: send each organization’s employees with its own x-organization-id.
An employee without an email is not matched against the ones already stored: sending the same name twice creates two employees. To retry a request safely, repeat it with the same Idempotency-Key.

Request

Headers

string
required
Your API key (see Authentication).
string
required
The organization the employees belong to.
string
required
1 to 255 characters, one per batch, looked up per organization across every v2 bulk route. Within 24 hours, the same key with the same route and body answers the same employees (with Idempotent-Replayed: true) instead of creating them again; the same key with another body or on another route is 422 IDEMPOTENCY_KEY_REUSED, and while the first request is still being processed 409 IDEMPOTENCY_KEY_IN_PROGRESS. After 24 hours the key is free, and a request with it is a new one. See The Idempotency-Key.

Query Parameters

boolean
default:"false"
Check only: the same 422 for invalid records, nothing written; 200 with {"dry_run": true, "submitted": n, "valid": n} when every record is valid. It does not check or store the Idempotency-Key.

Body Parameters

array[object]
required
The employees to create, 1 to 1,000. A field not listed here is rejected (SCHEMA_INVALID).

Response

201 Created with items: one per record, in the order sent, with its source_row_index, client_row_id and the created employee (id, organization_id, email, name, situation, status, created_at). Its id is the one Delete Employees (v2) takes.

Errors

Problem details. Per-record codes in errors[].error_code of a 422 BULK_RECORDS_REJECTED: Request-level errors: 401 for a missing or invalid API key, 403 LOGGED_USER_NOT_MEMBER when the key’s user is not a member of the organization, 422 REQUEST_VALIDATION_FAILED for a malformed body (no records, more than 1,000, no Idempotency-Key), 422 IDEMPOTENCY_KEY_REUSED, 409 IDEMPOTENCY_KEY_IN_PROGRESS, and 429 beyond the rate limits.

Limits

Delete Employees (v2)

Delete employees by id

List Employees

The employees stored, and their ids

Resend Commuting Survey

Send the survey, on request

List Ingest Jobs

The job each request records