Submitting store checks

POST /v1/{team}/audit-types/{auditType}/submissions

{auditType} is the checklist’s ULID. Only checklists that reps can start themselves accept submissions here.

{
  "customer_id": 42,
  "data": {
    "shelf_count": 12,
    "competitor_presence": "Yes",
    "competitor_activity": "Two-for-one on juice"
  },
  "latitude": 18.0179,
  "longitude": -76.8099,
  "status": "submitted"
}

• customer_id is the numeric id from the sync package. Leave it out when the checklist doesn’t need a customer.
• data holds the answers, keyed by each field’s name. Required fields, conditional fields and each field type’s rules are checked, and errors come back as data.{field}.
• status is submitted (the default) or in_progress for a draft.

The response is 201 with the saved store check, including its score. Checklists that need review start as pending review rather than submitted.

From the offline queue

Store checks made without a signal wait in a queue on the device and are sent in order when the app is back online.

• Treat 201 as done and remove the item from the queue.
• Treat 422 as a problem the rep must fix. Keep the item and show the errors.
• Treat network errors, 429 and 5xx as temporary. Retry with backoff.

Retries can create duplicates

If a request reaches the server but the response is lost, sending it again creates a second store check. Duplicate-safe submissions with a client-generated ID are next on the roadmap.

Photo and file answers can’t be uploaded through the API yet.