What the API documents
As read from Aryeo’s public API reference in October 2026, the API is a REST API at version 1, authenticated with a bearer token. For order entry, the relevant parts are:
- Create order: links an address, a customer (or a customer team membership) and a list of product variants with quantities, with optional private notes, a fulfilment status and a switch for whether Aryeo notifies the customer.
- Appointments: create an appointment or a draft, read available dates and time slots, reschedule, cancel and postpone.
- Customers: list and create customers, which is how an agent would be found by email before an order is created.
- Orders: list and read orders, including the order number once it exists.
What an order form adds that the call does not
A concierge order carries more than an address, an agent and a package. Your order forms hold the rules for each office and region: which products are offered, which questions are asked, how access is recorded. Those are not fields on the create-order call.
- Which form: the call has no notion of the office or region form, so the mapping from office to products has to live in your code.
- The form’s questions: occupancy, lockbox or agent access, gate codes — on the API they become notes or separate updates, not the form’s own fields.
- IDs first: the address, the customer and each product variant have to be found or created before the order call, so a new agent or an unmapped product has to be handled explicitly.
- Scheduling is separate: the slot is booked with its own appointment call, after checking available time slots.
Form route or API route
The form route drives Aryeo’s order form through a team-member login, the way your admin does. The form’s own rules stay in Aryeo, so nothing is rebuilt. The cost is that a redesigned screen can stop it — which is why it has to detect a change and stop rather than guess.
The API route talks to a published contract, so a screen redesign does not affect it. The cost is that the form’s logic is rebuilt in code and maintained when your forms change, and API access has to be set up for your account.
Our order-entry module uses the form route today. We have not yet proven the API route end to end on a live account; until we have, we would rather tell you that than promise it.
What an API-based order entry would look like
For the technically curious, the flow is short. The hard part is the mapping, not the calls.
- Read the concierge email into fixed fields with a language model; leave anything missing empty.
- Find the customer by the agent’s email; if there is no match, kick the order out as an exception.
- Find or create the address, and map the package and selections to product variant IDs from a table per office.
- Create the order with notifications off, and put access details and free-text requests into the notes.
- Pick a slot from the available time slots nearest the request, converted from the agent’s time zone, and create the appointment.
- Read the order number back from the response and log the order as placed.