Skip to main content
Objects shine when you sync a domain entity from an external system — a booking, a record, a job — and let the agent reach it via scan or follow-up.

Properties vs. metadata

Every example below uses both. The distinction matters:

properties (AI-visible)

Flat string key/values the chatbot can read when answering. These are your AI context. Stay readable — vin, next_service_due, customer_name. The agent references them as {{object.<type>.<key>}} in prompts and tool calls.

metadata (internal)

Free-form JSON for your integration — source-system IDs, raw payloads, audit fields. Stored, returned in API responses, but not surfaced to the agent.
Rule of thumb: if the chatbot needs to know it to do its job, it goes in properties. If it’s plumbing for your code, it goes in metadata. Set both in one call:
  • On create: pass properties: [...] and metadata: {...} to POST /v1/objects.
  • Updating: PUT /v1/objects/{id}/properties replaces the whole property set. PATCH /v1/objects/{id} updates metadata and other fields.

Industry patterns

A customer books service in Mitchell1, Tekmetric, or Shop-Ware. The integration creates a Vehicle Object so the agent can answer status questions, send reminders, and upsell maintenance based on mileage.
In the chatbot’s system prompt, reference fields with template syntax:
A pet owner books with Vetter or RxWorks. A Pet Object holds breed, age, vaccination status, and owner contact so the agent can send vaccination reminders, post-visit care tips, and annual-checkup prompts.
Attach the URL to the take-home pack. When the owner scans, the agent already knows Biscuit’s species, age, and which vaccinations are due.
A patient books with Jane App, Cliniko, or HotDoc. A Patient Object carries appointment context and care flags so the agent can send pre-appointment reminders, follow-up care instructions, and rebooking prompts.
cURL
Be deliberate about what goes in properties — anything in there is visible to the chatbot. For sensitive PHI, weigh whether the agent actually needs it to answer questions, or whether it’s better kept in your source system.
A reservation lands in SevenRooms or OpenTable. A Reservation Object captures party size, dietary requirements, and occasion so the agent can confirm bookings, answer parking questions, and follow up for reviews.
cURL
Drop the scan URL into the SMS reminder. Guests scan for menu questions, parking info, or to change the time — without holding the line.
A buyer enquires via REA Group, Zillow, or Follow Up Boss. A Property Enquiry Object pairs the listing with the buyer’s preferences so the agent can nurture, answer property questions, and prompt inspection bookings.
cURL
The buyer gets a personalised follow-up link. The agent answers spec questions, surfaces comparable listings from the linked KB, and offers an inspection slot — using the buyer’s stated budget and preferences as the lens.
A shipment is booked via Shippit, StarShipit, or a 3PL system. A Shipment Object tracks the delivery so the agent can proactively update on delays, answer ETA questions, and handle failed-delivery rebooking.
cURL
Add the URL to the dispatch SMS. When the courier ETA slips, push an updated status and eta via PUT /objects/{id}/properties — the agent surfaces the change before the customer has to ask.

More patterns

The same shape covers many other industries — pick the entity that matters in the source system and mirror it as an Object. Same recipe each time: pick a stable external_id from the source, pick a consistent type, put AI-relevant fields in properties as flat key/values, keep integration plumbing in metadata, and point destination at the chatbot or page the customer should land on.

Where to next

Object reference

Every field documented.

Idempotent upsert

Replay-safe writes by external_id.