How the GroWrk API behaves.

Requests are standard HTTPS calls with JSON bodies. Reads use GET, operations that start work use POST. Every request carries your API key and, for bodies, a JSON content type.

curl https://ai.growrk.com/v4/orders \
  -X POST \
  -H "X-API-KEY: $GROWRK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "deployment",
    "employee_id": "emp_23981",
    "country": "SG"
  }'

• A 2xx on an operational endpoint means the operation was accepted, not that it is finished.
• Timestamps are UTC in ISO 8601 form.
• Unknown fields should be ignored by your client so additive changes never break you.

Single-object responses return the resource. List endpoints return a data array. Store the returned identifier — it is how every later event is correlated back to the operation you started.

{
  "id": "ord_78219",
  "type": "deployment",
  "status": "processing",
  "employee_id": "emp_23981",
  "country": "SG",
  "created_at": "2026-08-26T16:42:11Z"
}

Example payloads are illustrative. Refer to your production API specification for finalized fields and schemas.

Errors return a non-2xx status with a structured body. The request_id is the value to quote when contacting GroWrk support about a specific call.

{
  "error": {
    "type": "validation_error",
    "message": "The request could not be processed.",
    "request_id": "req_82HD91"
  }
}

This error shape is illustrative and may differ from the production implementation for your partner configuration.

Error categories

Physical operations are expensive to duplicate. A retried deployment must not become two laptops shipped to the same person, and a retried retrieval must not dispatch two couriers.

• Treat every operational POST as something that must be safe to retry after a timeout or network failure.
• Keep a stable client-side key for each operation you initiate, derived from your own record — for example the hire or ticket ID.
• Before retrying, re-read the resource: if the operation already exists, reconcile instead of creating a second one.
• Never retry blindly in a loop; back off and surface the failure to your own operations team if it persists.

The exact retry-safety mechanism — including whether a dedicated idempotency header is used — is confirmed with your team during onboarding, because it depends on partner configuration.

List endpoints return results in pages rather than the entire collection. A response indicates whether more results exist, and your client requests the next page until it does not.

{
  "data": [
    { "id": "dev_90441", "status": "available" },
    { "id": "dev_90442", "status": "available" }
  ],
  "has_more": true
}

• Iterate until the response signals there are no further results, rather than assuming a fixed page count.
• Do not rely on ordering to detect completeness; use the pagination signal.
• For large syncs, prefer webhooks to keep state fresh and use list endpoints for reconciliation.

Parameter names and page-size limits are confirmed in the API specification issued to partners.

The API is versioned so an integration keeps working as the platform evolves. The current version used across GroWrk tooling is v4, and it is expressed in the request path.

https://ai.growrk.com/v4

• Additive changes — new fields, new event types — can ship within a version, so clients must tolerate unknown fields.
• Changes that would break an existing integration belong to a new version.
• Pin to the version you built against and migrate deliberately.