Skip to main content

The Form-Data Pattern

Most resources in Destiny that you can create or edit expose a companion endpoint that returns the data needed to build the form: the valid options, dropdown lists, and field metadata. You'll see these throughout the API as:

  • Get … Create Form Data — everything needed to render a create form.
  • Get … Edit Form Data — the same, pre-populated for an edit form.

Examples: Get Unit Create Form Data, Get Vehicle Edit Form Data, Get Client Create Form Data, Get Driver Create Form Data.

Looking for the actual endpoints?

Every Get … Create Form Data / Get … Edit Form Data endpoint is listed under its resource in the API Reference (e.g. HTTP API → Units → Get Unit Create Form Data). This guide explains why they exist; the Reference is where you'll find each one's exact response shape.

Why it exists

Many fields are references to other records (a unit type, a client, a vehicle group, a sensor model). Rather than hard-coding those option lists, you fetch them from the form-data endpoint so your UI always reflects what the server will accept.

The flow

1. GET …/create → form data (option lists, defaults, field metadata)
2. Build your form from that response
3. POST … → create the record using a valid selection

For edits:

1. GET …/{id}/edit → current values + option lists
2. PUT …/{id} → submit the updated record

Example

# 1. Fetch what a new unit needs
curl "https://www.acmdestiny.net/api/v1/units/create" \
-H "Authorization: bearer YOUR_TOKEN"

# 2. …render a form, let the user choose valid options…

# 3. Create the unit
curl -X POST "https://www.acmdestiny.net/api/v1/units" \
-H "Authorization: bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{ /* fields chosen from the create-form options */ }'
tip

Always drive your create/edit UIs from the form-data endpoint rather than assuming option lists. It keeps your integration correct as ACM adds unit types, sensors, expense types and so on. See Creating a Unit for a worked end-to-end example.