Skip to main content
Between the moment you submit a filing and the moment it completes, something can come up that no up-front check would have caught. A value carries a typo. The state turns out to require a detail nobody collected. A name that was free when your member picked it is gone by the time Palm files. Or a clerk with the filing in front of them asks a question. A case is how Palm handles every one of them. Rather than fail the filing and send your member back to the start, Palm pauses it, tells you exactly what it needs, and carries on once you answer. Most filings never raise one.
Early access — Cases are in preview and may change in backwards-incompatible ways before they are marked stable. Reach out before building on them in production.

​
How it works

  1. Palm opens a case on the filing and sends a case.opened webhook.
  2. Read what it asks for. Each case carries a list of the values Palm needs.
  3. Collect the answers from your member, rendering your prompts from that list.
  4. Submit the response.
  5. Palm acts on it and the filing continues.

​
What a case asks for

There is no fixed catalogue of questions, so a case arrives with a description of exactly what to collect rather than a scenario code you switch on. For each value it gives you the key to answer under, the type, a human-readable prompt, whether it is required, and an example of the expected format. That is enough to build the form at the moment you need it. Write one handler that reads the list and renders a prompt per entry, and it covers every case without a screen per scenario. For the exact object and field definitions, see Retrieve a case.

​
Respond to a case

Bash
The case.opened payload carries the whole case, so you can act on the webhook without a follow-up read. Key each answer by the field name Palm asked for, and submit while the case is still waiting on you. A successful submission hands the case back to Palm and fires case.updated. When the work behind it finishes, Palm closes the case and fires case.resolved.

​
Whose turn it is

The status says who acts next. needs_response is yours, and it is the only state that accepts a response. under_review means your answer arrived and Palm is acting on it, with nothing needed from you. Two states are terminal. A case reaches resolved when the work moved forward, and superseded when the filing underneath it finished or stopped first. Either way, resolution_reason records why it closed.

​
Find cases

Bash
Filter by parent, status, and kind, with cursor-based pagination. Polling that second call for needs_response is a reasonable safety net if a webhook delivery fails.

​
Webhooks

Three events cover the full lifecycle: case.opened when Palm needs you, case.updated when an open case changes, and case.resolved when it closes. Each payload carries the full case object. See Webhooks for payloads, delivery, retries, and signature verification.

​
Next steps