Recipe — Order lookup capability
A capability that lets an AI specialist answer “where’s my order?” by looking it up in your store’s API. This is the simplest, highest-value capability most teams build first.
What you’ll get
When a customer asks about an order, the AI:
- Asks for the order number (if it doesn’t already have it from the conversation)
- Calls your API with that number
- Replies with the status, expected delivery date, and tracking link if available
If the order doesn’t exist, the AI explains that politely and suggests the customer double-check the number.
Configuration
The connection
The auth type and auth mode live on the connection, not on the capability, and every capability built on that connection inherits them. Set the connection up first, from the systems strip on Settings → Capabilities:
- Base URL —
https://api.your-store.example.com/v1 - Auth type — API Key
- Auth mode (How do we connect to your system?) — Shared credentials
- Header name —
X-API-Key - Credential — Your store’s API key (paste; Atender encrypts it)
Capability basics
Press Add capabilities and pick that connection, then in the editor:
- Capability name — Look up order
- Description — Retrieves the current status, expected delivery date, and tracking link for a customer order.
- What do you want to do? — The
GET /orders/{orderNumber}endpoint - When should the Agent Stack use this? — Use whenever the customer asks about an order they’ve placed.
Inputs
You don’t author inputs by hand. The capability’s inputs are derived from the endpoint you picked — its path, query and body parameters — so orderNumber becomes an input because it is the path parameter of GET /orders/{orderNumber}. If a parameter is bound to a customer field on the connection, it is filled from the verified sign-in instead of by the model.
Response filter
There is no output-name mapping. The Response filter card takes a sample response and lets you allow-list which fields the Agent Stack may see, path by path, with a live “Preview: what the AI will see”. For this capability, include:
status— One ofpending,shipped,delivered,cancelledplaced_at— Order dateshipping.estimated_delivery— Expected delivery dateshipping.tracking_url— Carrier tracking link (may be empty for pending orders)
Everything else in the response stays out of the model’s context.
Action tier
- Action tier — Read — it reads one person’s data, so it needs a verified caller (a code to a channel already on the account, or a sign-in)
- Redaction rules — None needed for read-only lookup
Because Read is a gated tier, the publish checklist will also ask for the customer field on the connection and an ownership check — the thing that stops the capability from answering one customer’s question with another customer’s order.
Test it
Press Run test with orderNumber: "ORD-1001" (or a real order number from your store). You should see the order’s current status returned. If the API returns 404 for a missing order, that’s correct — the AI will explain that to the customer.
Assign to a specialist
Once published, attach this capability to your Order & Shipping specialist (or whatever you’ve named the agent that handles delivery questions). See Add a capability to a specialist. Don’t attach it to specialists that handle other topics — keeping each agent’s capabilities scoped to its area is what makes the AI accurate. Until you do, the capabilities list shows the row as Not assigned: published but reachable by nobody.
Variations
- By customer + order: pass both
customerIdandorderNumberfor tighter scoping. Useful if your API allows order numbers to repeat across customers. - With cancellation: build a separate Cancel order capability at the Transact tier so the specialist can offer to cancel after the lookup. Transact requires a signed-in customer on chat and is never bound on a voice call — the call reports it as human-only and hands the caller to a person. Don’t combine lookup and cancel into one capability — read and write should be separate.