Creating applications

An application is created from a template, which declares the fields it collects. The values go in form_data.

Create

curl -s -X POST "$BASE/warrants" \
  -H "x-api-key: $API_KEY" \
  -H "X-On-Behalf-Of: dr.chen@example.gov" \
  -H "Content-Type: application/json" \
  -d '{
    "template_id": "c47b2a91-5e3d-4f88-b0a2-7d1c6e9f4a53",
    "priority": "URGENT",
    "title": "Emergency detention: Rivera",
    "form_data": {
      "subject_name": "Jordan Rivera",
      "subject_dob": "1994-03-11",
      "facility": "Mercy General Hospital",
      "grounds": "Subject presented in acute crisis and meets the statutory criteria.",
      "physician_name": "Dr. Alex Chen",
      "physician_license": "TX-448120",
      "examination_time": "2026-08-19T13:55:00Z"
    }
  }'

Field	Required	Notes
`template_id`	Recommended	The template the application is built from
`form_data`	Yes	The values for the template's fields
`priority`	No	`LOW`, `STANDARD`, or `URGENT`. Defaults to `STANDARD`
`title`	No	A short label for queues and lists
`document_source`	No	Where the rendered document comes from

A new application is always DRAFT, whatever you send. It is assigned a warrant_number immediately, so it can be referred to in conversation before it is submitted.

What goes in form_data

form_data is an object keyed by the fieldId of each element the template declares. Read the template first and drive your payload from it rather than hard-coding field names:

curl -s "$BASE/templates/$TEMPLATE_ID" -H "x-api-key: $API_KEY" \
  | jq '.elements[] | select(.type=="field") | {fieldId, label, dataType, required}'

Every element marked required must be present and non-empty. A missing one returns 422 validation_failed with param naming the field:

{
  "error": {
    "message": "physician_license is required by this template.",
    "type": "invalid_request_error",
    "code": "validation_failed",
    "param": "form_data[physician_license]",
    "request_id": "req_01HZY5R2K3Q9"
  }
}

Keys the template does not declare are stored and returned unchanged, which is how an agency carries data the template does not know about. They do not appear on the rendered document. The field types and how each is validated are in form elements.

form_data is encrypted at rest and returned only to callers entitled to read the application. See security.

Update

curl -s -X PUT "$BASE/warrants/$WARRANT_ID" \
  -H "x-api-key: $API_KEY" \
  -H "X-On-Behalf-Of: dr.chen@example.gov" \
  -H "Content-Type: application/json" \
  -d '{"form_data": {"…": "…"}, "priority": "URGENT"}'

form_data is replaced wholesale, not merged: read the application, change the keys you mean to change, and send the whole object back. Anything else is a silent data loss waiting to happen.

SIGNED and REJECTED applications are locked and return 409. Reopen a rejected application first (lifecycle).

If several people or systems edit the same application, claim the edit lock first.

Read

curl -s "$BASE/warrants/$WARRANT_ID" -H "x-api-key: $API_KEY"

The response carries the decrypted form_data, the workflow state, the comment thread, the attachments, and, once signed, the judge, the signing time, and a short-lived pdf_url.

List

curl -s "$BASE/warrants?status=SUBMITTED&limit=50" -H "x-api-key: $API_KEY"

Parameter	Purpose
`status`	`DRAFT`, `SUBMITTED`, `SIGNED`, or `REJECTED`
`assigned_to_me`	Only applications routed to the attributed member
`trashed_only`	The trash instead of active applications
`skip`, `limit`	Paging

List responses carry a form_data_summary rather than the full contents: a few display fields, so a queue can be rendered without decrypting every application. Fetch the individual application when you need everything.

Create​

What goes in form_data​

Update​

Read​

List​

Create

What goes in form_data

Update

Read

List