Integrations

The Integration hub (Admin → Integrations) connects PeoplePit to other systems over their web APIs — a payment provider, a form service, a national federation — entirely through configuration. Define where to call, what to call, test it interactively, then schedule jobs that pull records in on a cadence.

Connectors

A connector describes one external system: its base address, how to authenticate, and any default headers. Supported authentication: none, API key, bearer token, username/password, and OAuth2 client credentials (tokens are fetched and refreshed automatically).

Secrets — API keys, passwords, client secrets — are entered once, stored encrypted, and never shown again (they display as ********). They are also never included when configuration is exported: on the target workspace an administrator re-enters them.

Endpoints

An endpoint is one callable operation on a connector — “list orders”, “get member” — with its method, path, query and body, all supporting {{placeholders}} filled at run time. You also tell it where the records are in the response, and how the API paginates, so a job can walk through all pages automatically.

The test console

The Test console is your in-app scratchpad: pick a connector, define or select an endpoint, fill the parameters, and Run — you see the status, timing, record count and the full pretty-printed response. Iterate here until the endpoint returns exactly the records you expect, before any job depends on it.

Jobs — pulling data in

A job runs an endpoint on a schedule and turns the results into records:

1. Schedule — manual, every N minutes, or daily at a time.
2. Connector + endpoint + parameters — what to call. Jobs can ask only for changes since the last successful run, so recurring syncs stay fast.
3. Mapping — which record type to create, and how each incoming field maps to yours (with simple transforms like trim, upper/lower case, date parsing, and defaults).
4. Key field — the unique identifier (an external ID, an email) so re-runs update or skip existing records instead of duplicating them.

Jobs reuse the same machinery as file imports: validation, record IDs, workflows and notifications all apply to synced records.

Multi-step mappings

One incoming record can produce several of yours, in order: a payment provider’s order first upserts the Person (matched by email), then the Payment (matched by the provider’s ID) with its payer pointing at that person. Steps can also look up existing records by any field to resolve references. For transforms the screen can’t express (say, converting cents to euros), a job can switch to an advanced script mode.

Pipelines

Chain jobs with Then run — sync people, then sync their payments. The chain runs in order and stops if a step fails; chained jobs fire only through their parent.

The call log

Every external call — from the test console or a job — is recorded in the Call log: request, response, status, timing, with credentials always redacted. Each job also keeps a run history with created/updated/skipped/failed counts. When a sync misbehaves, the answer is in the log.

Triggering a job from a workflow

A workflow transition can carry Run integration job — clicking “Send to accounting” on a record fires the transition and the job (with its pipeline). Integration becomes a button your team presses, and automations can run jobs too.