Skip to main content
This quickstart makes a keyless call to check the API is reachable. Then it creates a Customer and Receivable, records a Payment received outside PayPathIQ, and pauses the Receivable. Use synthetic data only. For source-system mapping and expected balances at each step, see the credit-union walkthrough. New to the terms? See the glossary.
Before you start, you need:
  1. A PayPathIQ login with API access, to create a sandbox key. See Get a sandbox key.
  2. Your clientCode. It is shown next to the Client name when you create the key.
  3. A shell with curl, or Node.js 18 or later, or Python 3 with requests.

Set up

Store the key in your secret manager and inject it as PAYPATHIQ_SANDBOX_API_KEY. Set your Client code as PAYPATHIQ_CLIENT_CODE. Sandbox keys have every scope this quickstart needs. Run the steps one at a time. Each key can run only one request at a time, and a second concurrent request returns 429 rate_limit_exceeded. The suffix keeps the immutable Payment observation and other resources independent from earlier runs. Run the setup once for each walkthrough.
Do not use member numbers, loan or account numbers, contact details, or other sensitive values as URL identifiers. Use stable opaque IDs from your integration mapping.

Check the API is reachable

The OpenAPI contract needs no API key. This call proves you can reach the sandbox.
Expect 200 OK and a paypathiq-api-version: v1 header. The body is the OpenAPI document, which begins:
1

Create a Customer

A Customer must exist before a Receivable can reference it.
Expect 201 Created and the saved Customer (trimmed):
Repeating the identical request returns 200 OK without creating another revision. See Safe retries.
2

Create a Receivable

recoverableAmount is the posted source obligation balance. Importing it does not grant recovery authority. Use an approved loan-profile connection for this example.
Expect 201 Created and the saved Receivable (trimmed):
A missing Customer returns 409 dependency_missing. PayPathIQ does not guess or queue the relationship.
3

Record a Payment observation

Use a Payment observation only for money received outside PayPathIQ. It is immutable evidence, not an instruction to collect a payment.
Expect 201 Created and the accepted observation (trimmed):
An allocation larger than the locked current balance fails atomically with 409 allocation_exceeds_balance. Unallocated money stays unapplied.
4

Pause the Receivable

Lifecycle changes use explicit commands rather than ordinary status fields.
Expect 200 OK and the Receivable with "status": "paused".Clear-pause, close, and reopen are separate commands. Clearing a pause or reopening never resumes recovery automation automatically.
5

Verify the resulting record

Read the Integration-facing Receivable back with GET.
Expect 200 OK, "status": "paused" and a recoverableAmount of "1000.00" EUR, which is the EUR 1,250.00 obligation less the EUR 250.00 payment (trimmed):
Save each response’s X-Request-Id for support correlation. Do not send PayPathIQ an API key or full personal-data payload when reporting a problem.
A Bearer header in a curl argument can show in the process list on a shared machine. To keep the key out of curl’s arguments, pass it through standard input as curl config. This is the Customer step; change the URL and body for the other steps.
Turn off shell tracing (set +x) so the key is not printed.

Retrying requests

Lose a response after a Customer PUT, or after recording a Payment? Repeat the identical request. For an uncertain lifecycle-command outcome, GET the Receivable before deciding what to do next. See Safe retries and idempotency.
An exact replay is duplicate-safe. Changed descriptions require a newer source revision; descriptive writes cannot replace financial balances. After a Payment observation, an old representation is rejected rather than restoring paid debt. Read and reconcile before deciding on another operation.

Next steps