Work as we hold it: what was issued, what became of it, and how it measured up.

kpi_fact against kpi_plan, plus time_worked, are the point of reading a task back — what was asked for, what was achieved, how long it took. status says where it got to.

Twenty-four fields, not the forty the table has. Eight of the rest configure how the mobile application behaves while the job is done — whether it demands a photo, records a location, keeps the steps in order. That is a task template's business, and neither useful nor settable here.

include=items adds the steps, include=managers the people who approve or are notified. Without them the keys are absent, never null standing in for "not asked for".

updated_since is what an export should page on, as an instant: a task moves through its statuses inside a working day, so a caller polling for completions needs to say which minute.

statuses takes created, started, paused, completed, incompleted and pastdue. Three more exist in the database and none is offered: finished and unfinished are deprecated spellings, and pending is reached only through approval. A value that cannot be explained is worse than one that is absent.

Oldest first. A first call lands on the earliest task this company ever issued, which for a long-standing one is years back. That order is what lets a full export finish in one walk, and it is not what you want for "what happened lately": ask with updated_since, or narrow with due_from and due_to.