Skip to main content

Documentation

Getting started with GroWrk Embedded.

Your application sends instructions. GroWrk executes physical device operations across 150+ countries and returns lifecycle state back to your application.

The integration model

GroWrk Embedded is an API over a physical operating network. Your product stays the system your customers use; GroWrk performs the procurement, configuration, shipping, retrieval, repair, storage, redeployment, and disposal behind it.

  1. Your product
  2. GroWrk API
  3. GroWrk physical execution
  4. Lifecycle events / webhooks
  5. Your product

The loop always closes. A request that starts a real-world operation does not return a finished outcome — it returns an accepted operation, and the outcome arrives later as lifecycle state your product can store and display.

Authentication

Requests are authenticated with an API key issued to your partner account. Keys are scoped to an environment and to the operations enabled for that account.

Request header
X-API-KEY: $GROWRK_API_KEY

Key types

  • Sandbox keys — used against the sandbox environment. They never trigger a real device operation.
  • Production keys — used against live operations. Every request can result in physical activity and real cost.

Scoped permissions

Keys carry the scope agreed for your integration: which lifecycle operations you can trigger, which customer tenants you can act for, and whether the key is read-only.

Rotation and secret handling

  • Treat keys as server-side secrets. Never ship a key in a browser bundle or mobile app.
  • Store keys in a secret manager, not in source control or environment files committed to a repo.
  • Rotate on a schedule and immediately after any suspected exposure.
  • Use separate keys per environment so a sandbox mistake can never reach production.

Production details may vary by partner configuration. The exact credential format, scopes, and rotation process for your account are confirmed during onboarding.

Environments

Sandbox

For development and testing. The sandbox lets you model employees, orders, and lifecycle progression without sourcing hardware, dispatching couriers, or incurring cost. Data in the sandbox is test data and is not connected to any physical operation.

Production

For live customer operations. A successful production request commits GroWrk to real physical work — a device is purchased or pulled from stock, configured, and shipped to a real person.

  • Never point a production key at test data, and never point a sandbox key at a real employee record.
  • Mirror both environments in your own system so you can replay an integration before going live.
  • Sandbox credentials are issued after a short integration review — they are not self-service.

Core resources

These are the objects an integration works with. Each one maps to something physical in the GroWrk network.

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

Employees

A person in your customer's workforce who can receive, hold, and return devices. Employees are the anchor for every physical operation.

Typical use cases

  • Create the person when your product records a hire
  • Reference an existing person when starting a retrieval
  • Read which devices a person currently holds

In the lifecycle: Every deployment, retrieval, and repair references an employee, and delivery location and customs paperwork are derived from their country.

POST /v4/employees
curl https://ai.growrk.com/v4/employees \
  -X POST \
  -H "X-API-KEY: $GROWRK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "Ana",
    "last_name": "Duarte",
    "email": "ana@example.com",
    "country": "SG"
  }'
Response
{
  "id": "emp_23981",
  "first_name": "Ana",
  "last_name": "Duarte",
  "country": "SG",
  "status": "active"
}

Assets & devices

A physical device tracked through its whole life: sourcing, configuration, assignment, retrieval, storage, repair, redeployment, and disposition.

Typical use cases

  • Show a customer which laptop an employee holds
  • Read device condition after a retrieval
  • Reconcile your asset register against physical reality

In the lifecycle: An asset moves between states as operations execute. Each transition emits a lifecycle event your product can persist.

GET /v4/employees/{id}/devices
curl https://ai.growrk.com/v4/employees/emp_23981/devices \
  -H "X-API-KEY: $GROWRK_API_KEY"
Response
{
  "data": [
    {
      "id": "dev_82117",
      "model": "MacBook Pro 14",
      "serial": "C02XXXXXXXXX",
      "status": "assigned",
      "employee_id": "emp_23981"
    }
  ]
}

Catalog

The device options and configurations available to a given customer in a given market, including the policies that constrain what can be ordered.

Typical use cases

  • Render an in-product device picker
  • Restrict choices to an approved hardware policy
  • Check availability before promising a delivery date

In the lifecycle: Catalog selection happens before an order exists. The chosen option becomes the specification GroWrk sources against.

GET /v4/devices/options
curl "https://ai.growrk.com/v4/devices/options?country=SG" \
  -H "X-API-KEY: $GROWRK_API_KEY"
Response
{
  "data": [
    {
      "id": "opt_mbp14_m3",
      "model": "MacBook Pro 14",
      "configuration": "M3 / 16GB / 512GB",
      "country": "SG",
      "available": true
    }
  ]
}

Orders

The instruction that starts a physical operation. An order carries a type — deployment, offboarding, collection, maintenance, or swap — and the employee it applies to.

Typical use cases

  • Turn a product event into a real-world operation
  • Read status and full event history for an operation
  • Track shipment progress and SLA position

In the lifecycle: Orders are the entry point to the lifecycle. Everything downstream — sourcing, configuration, shipment, delivery — is reported against the order.

POST /v4/orders
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"
  }'
Response
{
  "id": "ord_78219",
  "type": "deployment",
  "status": "processing",
  "employee_id": "emp_23981",
  "country": "SG"
}

Deployments

A deployment order in flight: sourcing the device, configuring it, enrolling it in MDM where applicable, and delivering it to the employee.

Typical use cases

  • Ship a laptop when your product records a new hire
  • Deliver a hardware refresh on a scheduled date
  • Expose delivery progress inside your own UI

In the lifecycle: A deployment progresses through sourcing, configuration, shipment, and delivery, ending with the asset assigned to the employee.

GET /v4/orders/{id}
curl https://ai.growrk.com/v4/orders/ord_78219 \
  -H "X-API-KEY: $GROWRK_API_KEY"
Response
{
  "id": "ord_78219",
  "type": "deployment",
  "status": "in_transit",
  "device_id": "dev_82117",
  "tracking": { "carrier": "DHL", "eta": "2026-09-04" }
}

Inventory

Devices held in the GroWrk network on behalf of a customer — available, reserved, in repair, or in storage.

Typical use cases

  • Fulfil a deployment from existing stock instead of buying new
  • Show a customer what they already own and where it sits
  • Plan refresh cycles against real availability

In the lifecycle: Inventory is the pool that retrievals feed and deployments draw from. It is what makes redeployment possible.

GET /v4/inventory
curl "https://ai.growrk.com/v4/inventory?status=available" \
  -H "X-API-KEY: $GROWRK_API_KEY"
Response
{
  "data": [
    {
      "id": "dev_90441",
      "model": "MacBook Air 13",
      "status": "available",
      "location": "SG"
    }
  ]
}

Retrievals

Collecting a device back from an employee — offboarding, refresh, or repair return — including employee coordination, courier, and customs.

Typical use cases

  • Recover hardware when your product records a termination
  • Collect a device before shipping a replacement
  • Report recovery status back to a customer

In the lifecycle: A retrieval ends with the device received and graded at a warehouse, which returns it to inventory for storage, redeployment, or ITAD.

POST /v4/orders
curl https://ai.growrk.com/v4/orders \
  -X POST \
  -H "X-API-KEY: $GROWRK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "offboarding",
    "employee_id": "emp_23981",
    "device_id": "dev_82117"
  }'
Response
{
  "id": "ord_91002",
  "type": "offboarding",
  "status": "scheduled",
  "device_id": "dev_82117"
}

Repairs

A maintenance or swap operation against a device already in the field, including diagnostics, parts, and replacement logistics.

Typical use cases

  • Turn an IT support ticket into a repair operation
  • Ship a replacement while the original is in service
  • Track repair progress inside your product

In the lifecycle: A repair usually pairs a retrieval with a deployment: the broken unit comes back while a working unit goes out.

POST /v4/orders
curl https://ai.growrk.com/v4/orders \
  -X POST \
  -H "X-API-KEY: $GROWRK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "maintenance",
    "employee_id": "emp_23981",
    "device_id": "dev_82117",
    "issue": "keyboard_failure"
  }'
Response
{
  "id": "ord_93310",
  "type": "maintenance",
  "status": "processing",
  "device_id": "dev_82117"
}

Storage & redeployment

Devices held in a GroWrk warehouse between assignments, and the operation that sends a stored device back out to a new employee.

Typical use cases

  • Hold hardware between a leaver and a joiner
  • Redeploy stock instead of purchasing again
  • Report storage position and stock age to a customer

In the lifecycle: Storage sits between a retrieval and the next deployment. Redeployment reuses an existing asset rather than sourcing a new one.

POST /v4/orders
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_40122",
    "device_id": "dev_90441"
  }'
Response
{
  "id": "ord_95120",
  "type": "deployment",
  "source": "inventory",
  "status": "processing",
  "device_id": "dev_90441"
}

ITAD

End-of-life disposition: secure data handling, certified disposal or remarketing, and the documentation a customer needs as evidence.

Typical use cases

  • Retire hardware at the end of a refresh cycle
  • Provide customers with disposition records
  • Close out an asset in your own register

In the lifecycle: ITAD is the terminal state of an asset. Once disposition completes, the asset leaves active inventory.

POST /v4/orders
curl https://ai.growrk.com/v4/orders \
  -X POST \
  -H "X-API-KEY: $GROWRK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "disposition",
    "device_id": "dev_90441"
  }'
Response
{
  "id": "ord_98001",
  "type": "disposition",
  "status": "processing",
  "device_id": "dev_90441"
}

Ready to build against the GroWrk lifecycle?

Sandbox credentials are issued by the GroWrk team after a short integration review.