Skip to main content

Kanban Task State

Transition tasks through workflow states on a Kanban board. External systems can move tasks between statuses directly from the kanban context.

Prerequisites

All endpoints on this page require a valid JWT token, API key, and tenant header. See Authentication for details.


Update Task State​

Transition a task to a new workflow state.

PUT/apidev/v1/kanban/tasks/{taskId}/state
PermissionAPICLI_KANBAN_WRITE
Rate Limit10 req/min (sliding window)

Request Headers​

Every request to a protected endpoint requires these headers:

HeaderRequiredDescription
AuthorizationYesBearer token obtained from the Login endpoint. Format: Bearer <token>
X-API-KeyYesCompany integration key provided during onboarding. Format: gtk_xxx...
tenantYesYour assigned tenant domain (default: geotareas.com) — always send your assigned tenant
Content-TypeConditionalapplication/json — required for POST and PUT requests

Path Parameters​

ParameterTypeRequiredDescription
taskIdstringYesTask unique identifier (BigInt)

Request Body​

FieldTypeRequiredConstraintsDescription
board_idstringYesMax length 30Board the task belongs to (BigInt)
target_statusstringYesMax length 10Target status: ACE, INI, USU, FIN, CAN
driver_idstringNoMax length 30Driver to assign (BigInt)

Response​

FieldTypeDescription
task_idstringTask unique identifier (BigInt)
previous_statusstring | nullStatus the task was in before the transition. Read just before the change; null on the rare occasion it could not be read
new_statusstringStatus after the transition
updated_atstringISO 8601 timestamp
previous_status is populated

The status is captured immediately before the transition is applied, so you get the real prior value — useful for building an audit trail without a separate read. Treat null as "unknown", not as "no previous status": the transition itself still succeeded.

Code Examples​

curl -s -X PUT "$TENANT_URL/apidev/v1/kanban/tasks/5001847291847291/state" \
-H "Authorization: Bearer $TOKEN" \
-H "X-API-Key: $APIKEY" \
-H "tenant: $TENANT" \
-H "Content-Type: application/json" \
-d '{
"board_id": "8391728491728491",
"target_status": "FIN"
}'

Example Response​

{
"success": true,
"data": {
"task_id": "5001847291847291",
"previous_status": "INI",
"new_status": "FIN",
"updated_at": "2026-03-19T16:45:00"
},
"meta": {}
}

Rate Limit Headers​

Every response includes rate limit information in the headers:

HeaderDescription
X-RateLimit-LimitMaximum number of requests allowed in the current window
X-RateLimit-RemainingNumber of requests remaining in the current window
X-RateLimit-ResetUnix timestamp (seconds) when the current window resets
Retry-AfterSeconds to wait before retrying (only present on 429 responses)
X-Request-IdUnique request identifier for debugging and support tickets

Errors​

CodeHTTPDescription
VALIDATION_ERROR400Invalid parameters
STATE_CHANGE_FAILED400Invalid state transition (e.g. FIN to SA)
UNAUTHORIZED401Missing, invalid, or expired tenant / Authorization / X-API-Key
FORBIDDEN403User lacks required permission
NOT_FOUND404Resource not found
RATE_LIMITED429Exceeded rate limit
INTERNAL_ERROR500Unexpected server error