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.

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.