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.
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 */ }'
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.