Keepable
Foundations

The model

A plan is a reviewed workflow definition. Running it creates correspondence, the durable record your integration reconciles.

The public API has one creation path and one resulting record.

A plan is a reusable workflow configured and published in Workspace. It owns the kind, message, questions, route, conditions, retention, and other policy choices that should be reviewed before automation starts.

Correspondence is one run of that plan. It records the concrete recipients, inputs, state, participants, and results.

Workspace: publish a plan          pln_01J8ZQ4T
API: POST /plans/{plan_id}/runs    cor_01J8ZQ4T

There is no public endpoint for authoring a plan or composing one-off correspondence. The boundary is intentional: an integration automates an approved workflow without reproducing the entire Workspace builder in JSON.

Kinds remain one lifecycle

A plan can create a letter, agreement, approval, consent request, or form. The kind changes what the workflow does, but the integration loop stays the same:

  • run the plan;
  • read the resulting correspondence;
  • reconcile participants;
  • collect claims or responses when the plan produces them; and
  • react to webhook events.

GET /correspondence lists every kind and can filter by plan_id, kind, or status. GET /correspondence/{correspondence_id} reads the current record.

Recipient identity

Plans delivered to people accept recipients addressed by NIN, email, CAC number, or claim. The run reports rejected inputs immediately and participant state records what happened asynchronously. The API does not expose a separate recipient-probing endpoint.

  • Email must match an existing verified account or the run rejects that entry.
  • NIN and eligible CAC identifiers can be retained for later delivery.
  • A claim recipient receives a single-use code that your organisation delivers over its own channel.

See Recipients and reachability.

Configuration stays in Workspace

Use Workspace to author plans, manage teams and connections, configure webhooks, inspect billing and audit history, operate recovery actions, and manage API keys. Those capabilities remain part of Keepable; they are simply not callable by an external machine credential.

On this page