Using Task Extended Data

Similar to extended data on Units, Task extended data lets you attach custom fields to a task using the optional extended_data object. When an inspector starts an inspection task in the Record360 app, matching fields are automatically mapped into the inspection checklist — pre-filling data from your system, so inspectors don't have to re-enter it.

Common use cases include passing contract numbers, work order details, or customer information from your ERP or rental management system directly into the inspection. This is a great to send temporary or time sensitive data to inspections without having to reconcile it later (like you would if you used custom unit fields for non-unit data).

How it works

1. Your integration creates or updates a task with an extended_data object.
2. The data is visible on the task in the Record360 dashboard and mobile apps.
3. When the assignee starts the inspection, each key in extended_data is matched against checklist fields. Matches are filled automatically.

Adding extended data

Include extended_data when creating or updating a task. It accepts any set of key-value pairs and is wholly optional.

curl -X POST https://api.record360.com/v3/tasks \
  -H "api-key-id: YOUR_KEY_ID" \
  -H "api-key-secret: YOUR_KEY_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Complete Inspection - B4WU11009",
    "assignee_username": "[email protected]",
    "due_by": "2026-01-31T12:00:00Z",
    "reference_number": "B4WU11009",
    "requires_inspection": true,
    "workflow_id": "abc1234dz",
    "extended_data": {
      "contract_num": "F4466",
      "customer_name": "Acme Equipment Co."
    }
  }'

The task response includes the stored object:

{
  "id": "21",
  "object": "task",
  "type": "inspection",
  "status": "incomplete",
  "name": "Complete Inspection - B4WU11009",
  "extended_data": {
    "contract_num": "F4466",
    "customer_name": "Acme Equipment Co."
  }
}

To modify extended data, send PATCH /tasks/{task_id} with the updated extended_data object — you can add or remove key-value pairs.

Understanding auto-mapping

When the inspection starts, each extended_data key is matched to checklist fields:

• Keys are matched against the checklist field id first, then the field label if there is no id match.
• All matching fields are filled — if a key matches multiple fields, every match is populated.
• If a field already contains data from a higher-priority source, it is skipped.

Priority order (highest first):

1. Previous inspection data
2. SDK-provided data
3. Task extended data
4. Unit data

Supported field types

For dropdowns and radio fields, the value must match an item that already exists in the field — non-matching values are not added as new items.

Best practices

• Use checklist field ids as keys where possible — they're stable even if labels change.
• Send dates in ISO 8601 format (e.g., 2026-01-31 or 2026-01-31T12:00:00Z).
• For dropdown and radio fields, send values that exactly match the configured items.
• If fields are dependent on a specific workflow, specify the workflow_id on the task to automatically push the user to the right flow.

Limitations

• Checkbox and pass/fail fields are not currently supported for auto-mapping.
• Keys that don't match any checklist field are skipped. They remain visible on the task, but nothing is pre-filled if there is no where to map it.
• Draft inspections are incompatible with extended data. Task extended data cannot be added to a task that has a draft inspection attached — the request will return a 4xx error. Draft data always takes precedence over extended data.
• For the first release, there is no dashboard UI for adding or editing extended data; it is managed entirely through the API.