> This page is for API, version 2026-01-01 (Stable) (default). > For other versions, use one of these documentation indexes: > - 2026-01-01 (Stable) (default): https://developer.deel.com/api/stable/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://developer.deel.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developer.deel.com/_mcp/server. # Equipping a worker > Ship a laptop to a worker from your own inventory or by reassigning a stored rental. When a new hire joins your organization, or an existing worker wants a device refresh, IT needs to get them a laptop. This is one of the most common workflows to build on the Deel IT Public API. The API supports two paths to the same outcome — a laptop in the worker's hands — and the right choice depends on the state of your inventory and the rental agreements Deel manages for you. This guide covers both paths on one page so you can implement the decision logic in your own service and route each request to whichever option fits your policy and current stock. > **Some endpoints in this guide are in Beta** > > The `GET /rest/it/assets` and `GET /rest/it/assets/{asset_id}` endpoints are stable. Other Deel IT endpoints in this guide are in Beta and may have changes to their request and response shapes. See [API versioning](/api/api-versioning) for details on endpoint lifecycle states. ## Choosing an approach Every path starts the same way: resolve the worker to an HRIS profile. Then check whether you can equip them from stock you already own, or from a rental Deel is holding for reuse. Shipping from your own inventory sends a device your organization already owns from a warehouse to the worker, using Deel logistics. Reassigning a stored rental continues an existing rental agreement by sending a returned device on to the next holder. Which one to prefer, and in what order, depends on your existing agreements, stock levels, and internal policy — this guide describes both mechanisms and leaves the choice to you. ## Prerequisites #### A Deel account with Deel IT enabled Your organization must be onboarded to Deel IT and have at least one warehouse or rental agreement to draw from. See [Getting Started with Deel IT](https://help.letsdeel.com/hc/en-gb/articles/28400594460305-Getting-Started-with-Deel-IT) for the account setup steps, and [How Deel IT Device Lifecycle Management Works](https://help.letsdeel.com/hc/en-gb/articles/33447725851153-How-Deel-IT-Device-Lifecycle-Management-Works) for background on what the API automates. #### An API token with the required scopes Four scopes cover both paths and the HRIS profile lookup: * `it-assets:read` to search your inventory for available devices. * `it-agreements:read` to search Deel-held rentals available for reuse. * `it-service-requests:write` to trigger delivery or reassignment. * `people:read` to resolve a worker to an `hris_profile_id`. #### A shipping address for the worker Every path ends in a shipment. Collect the worker's shipping address if it is not already recorded in Deel. See [Delivery Coverage, Delivery Times, and Express Shipping](https://help.letsdeel.com/hc/en-gb/articles/28246305093393-Delivery-Coverage-Delivery-Times-and-Express-Shipping-Deel-IT) for the countries Deel logistics operates in and available service tiers. ## Step 1: Resolve the worker's HRIS profile The Deel IT Public API identifies people by `hris_profile_id`. If your event does not carry it, look it up via the [List people](/api/reference/endpoints/people/get-people) endpoint on the Deel core Public API. ```bash curl --request GET 'https://api.letsdeel.com/rest/people?email=nina.roth@example.com' \ --header 'Authorization: Bearer YOUR_API_TOKEN' ``` **Example response:** ```json focus={4} { "data": [ { "id": "9b9fc43a-a90c-4615-ac50-baf1e314b53e", "first_name": "Nina", "last_name": "Roth", "full_name": "Nina Roth", "emails": [ { "type": "work", "value": "nina.roth@example.com" } ], "job_title": "Product Manager", "department": { "id": "5f8a2c1e-3b47-4e89-9f2c-8d1e3a4b5c6f", "name": "Product" }, "hiring_status": "onboarding" } ] } ``` The `id` field is the person's `hris_profile_id`. The rest of the workflow uses it as the `hris_profile_id` in every request body. ## Step 2: Ship the device The API supports two paths. Pick one based on your policy and current stock; the API does not prescribe an order. #### Ship from your inventory Use this path to send a device your organization already owns from a warehouse to the worker. Deel arranges the shipment. Requires `it-assets:read` and `it-service-requests:write` scopes. First, list assets at a warehouse, filtered by the category the worker needs. `status=ACTIVE` excludes archived devices; `location=AT_WAREHOUSE` scopes to stock available for shipment. See the [List IT assets](/api/deel-it/endpoints/assets/list-it-assets) reference. ```bash curl --request GET 'https://api.letsdeel.com/rest/it/assets?location=AT_WAREHOUSE&category=LAPTOP&status=ACTIVE' \ --header 'Authorization: Bearer YOUR_API_TOKEN' ``` **Example response:** ```json focus={4,9,11-14,18,23,25-28,32-34} { "data": [ { "id": "550e8400-e29b-41d4-a716-446655440000", "public_id": "ITM-550E8400", "grade": "A", "status": "ACTIVE", "location": "AT_WAREHOUSE", "product": { "id": "6ba7b810-9dad-11d1-80b4-00c04fd430c8", "name": "MacBook Pro 14", "brand": "Apple", "category": "LAPTOP" }, "assigned_user": null }, { "id": "3f8b1c0d-6a4e-4c99-8b7d-2f9e3a1b4c5d", "public_id": "ITM-3F8B1C0D", "grade": "A", "status": "ACTIVE", "location": "AT_WAREHOUSE", "product": { "id": "8ac7b820-9dad-11d1-80b4-00c04fd430c8", "name": "ThinkPad X1 Carbon", "brand": "Lenovo", "category": "LAPTOP" }, "assigned_user": null } ], "has_more": true, "next_cursor": "eyJvZmZzZXQiOjIsImxpbWl0IjoyMH0", "total_count": 47 } ``` Each asset carries an `id` — this is the `asset_id` you pass to `/deliver` in the next step. The `product` block describes what the hardware actually is. Pick an asset from the response. If you need to filter further on specifications, see the [Retrieve an IT asset](/api/deel-it/endpoints/assets/get-it-asset-by-id) reference. When `has_more` is `true`, pass the `next_cursor` value as the `cursor` query parameter on the next request to page through the rest of the inventory. Then, submit a delivery service request. Deel schedules and arranges the shipment. See the [Create a delivery request for an IT asset](/api/deel-it/endpoints/assets/deliver-it-asset) reference. ```bash curl --request POST 'https://api.letsdeel.com/rest/it/assets/{asset_id}/deliver' \ --header 'Authorization: Bearer YOUR_API_TOKEN' \ --header 'Content-Type: application/json' \ --data '{ "hris_profile_id": "prof_9f2c", "delivery_address": { "country": "GB", "city": "London", "postal_code": "EC1A 1BB", "address_line_1": "10 Onboarding Street" }, "is_express_delivery": false }' ``` Once the shipment is delivered, the asset's `location` transitions to `WITH_USER` and `assigned_user` reflects the worker. #### Reassign a stored rental Use this path when Deel is holding a returned rental that is ready to be reused. The existing rental agreement continues under a new holder, and Deel arranges the shipment from storage to the worker. Requires `it-agreements:read` and `it-service-requests:write` scopes. For background on the states a rental moves through before it becomes available for reassignment, see [Storing and Reusing Devices with Deel IT](https://help.letsdeel.com/hc/en-gb/articles/28397372249361-Storing-and-Reusing-Devices-with-Deel-IT). First, list rental agreements whose store-and-reuse lifecycle has completed processing and is available for reassignment. See the [List agreements](/api/deel-it/endpoints/agreements/list-it-agreements) reference. ```bash curl --request GET 'https://api.letsdeel.com/rest/it/agreements?type=RENTAL&store_and_reuse_status=READY' \ --header 'Authorization: Bearer YOUR_API_TOKEN' ``` Then, fetch the agreement to see which product variants it can be reassigned as. See the [Retrieve an agreement](/api/deel-it/endpoints/agreements/get-it-agreement-by-id) reference. A returned laptop may be reusable as its original variant, or as a downgraded configuration if it was graded lower on return. ```bash curl --request GET 'https://api.letsdeel.com/rest/it/agreements/{agreement_id}' \ --header 'Authorization: Bearer YOUR_API_TOKEN' ``` In the response, look at `actions.reuse.details.reusable_variants` and choose one whose specifications match what the worker needs. Finally, reassign the rental to the worker. Deel creates a new store-and-reuse assignment, which in turn ships the device. See the [Assign agreement to a new worker](/api/deel-it/endpoints/agreements/reassign-it-agreement) reference. ```bash curl --request POST 'https://api.letsdeel.com/rest/it/agreements/{agreement_id}/reassign' \ --header 'Authorization: Bearer YOUR_API_TOKEN' \ --header 'Content-Type: application/json' \ --data '{ "hris_profile_id": "prof_9f2c", "variant_id": "2f4e7ab1-9d3c-4b1f-9e34-6dfb0d6a12ab", "delivery_address": { "country": "GB", "city": "London", "postal_code": "EC1A 1BB", "address_line_1": "10 Onboarding Street" }, "is_express_delivery_requested": false }' ``` The agreement's `store_and_reuse.status` moves to `IN_PROGRESS`, then to `COMPLETED` once the shipment is delivered. ## Step 3: Track the shipment to delivery Both paths result in a shipment that Deel logistics fulfils asynchronously. `POST /rest/it/assets/{asset_id}/deliver` and `POST /rest/it/agreements/{agreement_id}/reassign` return `200 OK` with the current asset state. That response confirms the delivery service request was created, not that the device is on the worker's desk. Immediately after the call, the asset is still at the warehouse: `location` is `AT_WAREHOUSE` and `assigned_user` is `null`. As Deel logistics processes the shipment, the asset moves through two more location states: * `WITH_COURIER` — the courier has picked up the device and it is in transit. `assigned_user` is still `null` at this stage. * `WITH_USER` — the shipment has been delivered. `assigned_user` is now populated with the worker's HRIS profile. ### Polling for the terminal state Poll [`GET /rest/it/assets/{asset_id}`](/api/deel-it/endpoints/assets/get-it-asset-by-id) and watch for `location` to become `WITH_USER` and `assigned_user` to be populated. ```bash curl --request GET 'https://api.letsdeel.com/rest/it/assets/{asset_id}' \ --header 'Authorization: Bearer YOUR_API_TOKEN' ``` **Example response after delivery:** ```json focus={10,15-29} { "data": { "id": "550e8400-e29b-41d4-a716-446655440000", "public_id": "ITM-550E8400", "created_at": "2025-01-15T10:30:00.000Z", "updated_at": "2025-02-01T14:22:00.000Z", "serial_number": "C02XL0AAAAAA", "grade": "A", "status": "ACTIVE", "location": "WITH_USER", "ownership": { "type": "ORGANIZATION", "name": "Acme Corporation" }, "assigned_user": { "hris_profile_id": "9b9fc43a-a90c-4615-ac50-baf1e314b53e", "first_name": "Nina", "last_name": "Roth", "emails": ["nina.roth@example.com"], "address": { "id": "aabbccdd-eeff-0011-2233-445566778899", "type": "DELIVERY", "line1": "10 Onboarding Street", "city": "London", "post_code": "EC1A 1BB", "country": "GB", "is_valid": true } }, "assigned_warehouse": null, "product": { "id": "6ba7b810-9dad-11d1-80b4-00c04fd430c8", "name": "MacBook Pro 14", "brand": "Apple", "category": "LAPTOP" } } } ``` The example above shows the terminal state: `location` is `WITH_USER` and `assigned_user` is populated with the worker's HRIS profile. That is the signal to close out the onboarding or refresh task in your internal system. ### React to a webhook instead If you would rather not poll, subscribe to the `it-asset.location-updated` event to receive a callback whenever an asset's location changes. Deel delivers a webhook when the asset moves to `WITH_COURIER` and again when it moves to `WITH_USER`. Filter incoming events on the asset ID you started the delivery with, and check the `location` field to detect the terminal state. See [Webhooks](/api/webhooks/introduction) for how to register an endpoint and verify signatures, and [Discovering available events](/api/webhooks/events) for the full event catalogue. > **Info** > > When you reassign a rental, the previous asset record is archived and a new asset is created for the worker. Track continuity through the `agreement_id`, not the `asset_id`. ## Example automated flow If you are building this as an automated service, here is one example of how the steps can be sequenced end to end. This is illustrative — the API does not prescribe any particular order, and you can adapt or reorder these steps to fit your own policy. #### Resolve the HRIS profile Look up or receive the worker's `hris_profile_id`. #### Check your inventory Call `GET /rest/it/assets?location=AT_WAREHOUSE&status=ACTIVE&category={category}` to see which owned devices are available in your warehouses. #### Check for stored rentals Call `GET /rest/it/agreements?type=RENTAL&store_and_reuse_status=READY` to see which rented devices are available for reassignment. #### Pick a candidate and ship it Apply your own selection logic across the two result sets. Call `POST /rest/it/assets/{asset_id}/deliver` for an owned device or `POST /rest/it/agreements/{agreement_id}/reassign` for a rental, and stop. #### Confirm delivery Watch for `location=WITH_USER` on the resulting asset — either by polling `GET /rest/it/assets/{asset_id}` or by subscribing to `it-asset.location-updated` — then close out the task in your internal system.