Event schemas

One page per event of the FitMyType event catalogue, generated from the JSON schemas the API checks events against. Each page shows when the event is sent, its required and optional fields, an example, and the checks that Tracking debug in your back office makes, with the same messages.

Every event needs a tracking_id

Send a non-null tracking_id with every event: the visitor id that the widget and the tag keep in fmt_device_id. It joins the events of one visitor. An event without it is rejected, except carts and orders: those are kept but marked untracked, and they cannot be joined to the visitor's size answer.

What POST /events answers

Send one event, a JSON array of events or {"events": [...]} (at most 50 per call) to POST /events. Once the call is safely queued it answers 202 with {received, accepted, rejected}:

• received: the events in the call.
• accepted: the events taken into the queue.
• rejected: the events refused at the door, each with its index in the call and an error (not_an_object, missing_event, unknown_event, missing_client_id, event_id_conflict, duplicate_event_id).

{
  "received": 3,
  "accepted": 2,
  "rejected": [
    {
      "index": 2,
      "error": "unknown_event"
    }
  ]
}

A rejected event is not stored and not counted: fix it and send it again. An accepted event that fails a field check later is stored as invalid: it is never counted in your dashboards, and Tracking debug shows it with the reason, using the messages listed on each event's page.

Events