Skip to main content
Use Remote Retrieval through Corsair: one client, typed API calls. The API key comes from the Enterprise Remote Retriever portal and goes in Authorization: Bearer. It is only available on an enterprise account, and every route lives under https://www.remoteretrieval.com/api/v1 — there is no separate API host. orders.create books a real, paid shipment. A box is sent to a named employee at a home address and collected from there, and every order is billed at the per-device price prices returns (an order stays in orders.pending until that payment completes). The API documents no test mode and no cancel route, so read this before calling it, and never call it in a loop:
  • Check prices first when the cost matters. It is the live per-device price, and it is the only place Monitor_27 is explained: it is a display of 24 to 27 inches, where plain Monitor means 17 to 23.
  • Two cross-field rules are enforced before the request. return_add_srv: 2 means data wipe and delivery to a new employee, so it needs new_employee_info; ins_active: 1 needs an ins_amount. The plugin rejects either omission rather than letting the API create an order it cannot fulfil. return_add_srv also only makes sense on a Return To Company order, not a recycle.
  • The request and response spellings differ. A create takes employee_info.address_city, address_state and address_zip; every list answers employee_info.city, state and zip. The models follow each side, so a value copied from a read will not fit a write without renaming.
  • One order ID comes back for a batch. orders.create accepts an array, but the response carries a single order reference, as a string.
Reading, in practice:
  • The four order lists do not share a shape. orders.pending, orders.new, orders.inprogress and orders.get answer a bare array (paged by page, up to 25); only orders.list answers {next, previous, results} and pages by the response’s own next link: pass that link back as cursor and the plugin reads the cursor out of it.
  • orders.get takes its ID as a query parameter, not a path segment. The route is device_returns and the id is ?oid=.
  • The three list routes are a pipeline, not a filter. pending is payment not yet completed (on hold), new is payment done and ready to process, and inprogress has the return leg started but the device not yet back. orders.list is the one place both payment_status and order_status appear together.
  • --- means “not started”. shipments.send_status and return_status carry that placeholder before a leg begins, so it is not a failure state to alert on.
  • A refusal can arrive as a 401 with Invalid Key!, which is the live answer for both a missing key and a wrong key — the message cannot tell them apart. A failure also carries status: "Fail" alongside its code, and the plugin checks for that, so a refusal reported inside a 200 still throws rather than being read as an order.
  • No rate limit is documented. Orders are created and billed at a real logistics company, so orders.create is never retried, not even after a 429 or a 5xx; the reads retry either twice.
What you get:
  • 9 typed API operations

Setup

1

Install

2

Add the plugin

corsair.ts
With multiTenancy: true, scope calls with corsair.withTenant(id). See Quick start for KEK + Hub keys, and Multi-tenancy for account isolation.
3

Choose authentication

4

Connect a tenant

Mint a connect link and send the tenant to it. Hub hosts the page and delivers the result to your app — see Connect / OAuth.

Example API calls

List orders awaiting payment
Create an equipment-return order
See the full list on the API page.

What’s next

API reference

Every remoteretrieval.api.* operation with input and output types.

Connect / OAuth

createLink, Hub delivery, and tenant connect flows.

Use with agents

Expose this plugin’s operations as MCP tools.