canonical: https://jentic.com/apis/app.helloretriever.com/helloretriever

# Helloretriever Retriever API

The Retriever API lets HR and IT teams submit and track device return orders for laptops, cell phones, and monitors from US and Canada-based employees. Orders cover prepaid balance lookups, warehouse address management, and per-deployment status queries. The API is tied to a Retriever portal account, so submitted orders are billable unless cancelled within 30 minutes via the dashboard.

## For AI agents

Submit device return orders for offboarding employees, check return status, and look up prepaid balances so an agent can run end-to-end equipment retrieval workflows.

## Scope

Does not handle device provisioning, IT asset purchasing, or shipping label printing - use for submitting and tracking employee device returns only.

## Capabilities

- Create a device return order for a departing employee via `/api/v2/device_returns`/
- Retrieve the status of a specific device return by order ID
- List warehouse destinations the device can be shipped back to
- Check prepaid balance before submitting orders that incur charges
- Look up deployment records for a returning employee
- Cancel test orders within 30 minutes by combining order creation with portal cancellation

## Use cases

### Automated Offboarding Device Return

Trigger a device return order automatically when HRIS marks an employee as offboarding. The orchestration calls POST `/api/v2/device_returns`/ with the employee shipping address and device type, then polls GET `/api/v2/device_returns/{id}`/ until the order ships. Returns are limited to laptops, cell phones, and monitors for US employees and laptops and cell phones for Canada employees, with the return destination required to be a US address.

Example prompt: Read offboarding event from HRIS, call POST `/api/v2/device_returns`/ with the employee's home address and device_type=laptop, then confirm by polling GET `/api/v2/device_returns/{id}`/ for tracking number

### Prepaid Balance Monitoring

Avoid order failures by checking prepaid balance before initiating bulk returns at quarter-end or during a layoff event. GET `/api/v2/prepaid_balances`/ returns current credit, allowing finance to top up the account before submitting dozens of orders that would otherwise be rate-limited or rejected for insufficient funds.

Example prompt: Call GET `/api/v2/prepaid_balances`/ before any batch return submission and alert finance if balance is below the projected cost of pending returns

### Return Status Reporting

Build a status dashboard for IT asset managers showing every active device return, its courier tracking, and expected receipt date. The agent walks `/api/v2/device_returns`/ with pagination, joins each entry with `/api/v2/warehouse`/ to resolve the destination, and produces a single view across all open returns.

Example prompt: List all active device returns via GET `/api/v2/device_returns`/, enrich each with warehouse name from GET `/api/v2/warehouse/{id}`/, and output a CSV grouped by status

### Agent-Initiated Equipment Recovery

Let an internal IT helpdesk agent submit a Retriever return order in response to a Slack or ticket request. The agent searches Jentic for 'submit a device return', loads the operation schema, and executes with the employee's address and device type - without the agent ever holding the bearer token.

Example prompt: Search Jentic for 'submit a device return', load the schema, and call POST `/api/v2/device_returns`/ with the address and device type from the helpdesk ticket

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/api/v2/device_returns/` | Submit a device return order |
| GET | `/api/v2/device_returns/{id}/` | Get status of a specific device return |
| GET | `/api/v2/deployments/` | List deployments for returning employees |
| GET | `/api/v2/deployments/{id}/` | Get a specific deployment |
| GET | `/api/v2/prepaid_balances/` | Check prepaid account balance |
| GET | `/api/v2/warehouse/` | List warehouse destinations |

## Key resources

- **Deployment Orders** — List and inspect deployment orders for returning employees
- **Device Returns** — Create return orders and check status by order ID
- **Prepaid Balances** — Check account credit available for billable returns
- **Warehouse** — List warehouse destinations and resolve warehouse IDs

## Why Jentic

- **Setup:** Wiring Retriever by hand means learning its bearer auth and threading device-return and deployment ids through its v2 paths yourself. Through Jentic you install once, import the Retriever API from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** Retriever puts the record id in the URL path (`/api/v2/device_returns/{id}`/), so a rule can pin your agent to reading and tracking specific device returns. You choose the operations it may call, so submitting a new billable device return is not included unless you add it.
- **Credential handling:** Your Retriever bearer token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'submit a device return' or 'check return status', and Jentic returns the matching device-returns operation with its input schema so the agent calls the right endpoint without reading Retriever docs.

## Related APIs

- **BambooHR API** — BambooHR is the typical HRIS source-of-truth that triggers a Retriever return when an employee is marked as offboarding
- **Workable API** — Workable manages the hiring side; Retriever closes the loop on equipment when employees leave
- **SmartRecruiters API** — SmartRecruiters covers ATS workflows and can trigger downstream device retrieval through Retriever

## FAQ

### What authentication does the Retriever API use?

Bearer token authentication. Tokens are issued from the Retriever portal and passed in the Authorization header. Through Jentic the bearer token is stored encrypted in the vault (your Jentic One instance) and never enters agent context.

### Can I submit a device return order without using the portal UI?

Yes. POST `/api/v2/device_returns`/ creates an order programmatically. Note that submitted orders are real and billable - to test, submit and then cancel via the portal dashboard within 30 minutes, after which orders are final.

### What are the rate limits for the Retriever API?

Read requests are limited to 60 per minute and 500 per day. Write requests (submitting returns) are limited to 600 per minute and 5000 per day. A 429 response is returned when limits are exceeded - contact Retriever support for higher limits.

### How do I trigger a device return through Jentic?

Run pip install jentic, then search 'submit a device return order'. Jentic returns POST `/api/v2/device_returns`/ with its input schema - load the schema, populate the employee address and device type, and execute. The agent never sees the bearer token.

### Which countries and devices are supported?

Returns are supported for laptops, cell phones, and monitors from US-based employees, and laptops and cell phones from Canada-based employees. For Canada-based returns the destination warehouse must be a US address.

### Can I cancel a return after submitting?

Yes, but only within 30 minutes of submission and only via the Retriever portal dashboard. The API does not expose a programmatic cancel endpoint - orders are final after the 30-minute window.

### Can I limit what my agent is allowed to do with the Retriever API?

Yes. Because Jentic One is self-hosted, you set the rules that decide which Retriever operations your agent can call, and it runs under your own instance. Since Retriever puts the record id in the URL path, such as GET `/api/v2/device_returns/{id}`/, you can pin the agent to reading and tracking specific device returns while leaving out the billable POST `/api/v2/device_returns`/ that submits a new order. The bearer token stays with your instance and is injected only at execution, so the agent acts strictly within the operations you have allowed.