Custom Field Values API

Where the Custom Field Definitions API manages the schema, this API manages the data: the actual values on locations (persistent — every future order at that location inherits them) and on order locations (one specific stop on one specific order), plus the acknowledgment trail when drivers confirm a field.

Where this fits in your operation

• Keep operational facts on the address: your system knows the gate code or dock number for a delivery address — set it as a location field once, and every order’s stop at that location carries it to the driver.
• Per-shipment instructions: this particular delivery needs “CALL 1H” — set it manually on the order location, without touching the location’s standing fields.
• Compliance follow-up: a field defined as acknowledgeable (“keys returned”, “temperature checked”) must be confirmed by the driver — read the per-location summary or pull the org-wide acknowledgment report for your QA process.

Interactive API Explorer

Authentication

Authorization: apikey YOUR_API_KEY_HERE

Base URLs

• Production: https://app.zenderatms.com/api/
• Staging: https://staging.zenderatms.com/api/

Location custom fields

Persistent values on a location:

GET    /v2/locations/{locationId}/custom-fields?isActive=true
POST   /v2/locations/{locationId}/custom-fields
PUT    /v2/locations/{locationId}/custom-fields/{fieldId}
DELETE /v2/locations/{locationId}/custom-fields/{fieldId}

Create:

{
  "customFieldDefinitionId": 42,
  "value": "1234#",
  "sortOrder": 1
}

Each LocationCustomField in responses carries id, locationId, customFieldDefinitionId, value, sortOrder, isActive, timestamps, and a nested definition (externalId, label, title, displayStyle).

Update (PUT) takes any of value, sortOrder, isActive — all optional; omitted fields keep their value. DELETE is a soft delete: it sets the field inactive rather than removing it, which is the same as PUT { "isActive": false }. Inactive location fields are not copied onto new orders’ stops during order import (the copy reads active fields only), and they’re hidden from ?isActive=true listings.

Order location custom fields

Values on one stop of one order:

GET    /v2/order-locations/{orderLocationId}/custom-fields
POST   /v2/order-locations/{orderLocationId}/custom-fields
PUT    /v2/order-locations/{orderLocationId}/custom-fields/{fieldId}
DELETE /v2/order-locations/{orderLocationId}/custom-fields/{fieldId}

Each OrderLocationCustomField carries a sourceType telling you where it came from:

• location — copied from the location’s standing fields
• opposite_stop — copied from the other stop of the order
• manual — added directly (this is what your POST creates)

sourceFieldId points back to the originating field for copied values. Create takes customFieldDefinitionId + value; update (PUT) takes a required value.

Acknowledgments

When a field’s definition requires driver acknowledgment, every confirmation is logged. Two read surfaces:

Per-location summary

GET /v2/locations/{locationId}/custom-fields/acknowledgment-summary

Returns fieldStats[] per field: totalUses (times the field was copied to orders), acknowledgedCount, pendingCount, and lastAcknowledgedAt.

Organization-wide report

GET /v2/reports/custom-field-acknowledgments?fromDate=...&toDate=...&page=1&pageSize=50

Optional filters: locationIds (repeatable), fieldDefinitionId, userId, orderId. Returns paginated entries[] — each with the action, the driver’s optional comment, acknowledgedAt, acknowledgedByName, and the field’s fieldDefinitionId / fieldLabel.

Common gotchas

• Location fields propagate; order-location fields don’t. Active location fields are copied onto the stop when an order is imported — set the value on the location when it should apply to every future stop there, on the order location for a one-off.
• DELETE doesn’t remove location fields — it deactivates them. List with no isActive filter to see inactive fields too.
• Badge-style values are short. For fields whose definition uses the badge display style, value is capped at 7 characters.
• Check sourceType before editing. Updating a copied (location-sourced) field on an order location only changes that one stop — the location’s standing value is unchanged.
• PUT semantics differ. Location-field updates are partial (all body fields optional); order-location-field updates require value.

Related documentation

• Custom Field Definitions — define the fields before setting values
• Locations — resolve locationId