Order Created

Fires when a patient order is created. targetEntity is the Order. The eventType is order_created.

Field guarantees

Field	Guarantee
`eventData.orderId`	✅ Always present (v1)
`order_id` in v2	✅ Always present
`eventData.orderLink` / `order_link`	⚠️ Present only while the order's intake is still outstanding

v1 payload (legacy)

{
  "_id": "event::8d367e3b-xxxx-xxxx-xxxx-3c6b7dfb804a",
  "ownerEntityModel": "Patient",
  "targetEntityModel": "Order",
  "deleted": false,
  "ownerEntity": "pat::117eb3b9-xxxx-xxxx-xxxx-9424274b5425",
  "targetEntity": "order::e5576e92-xxxx-xxxx-xxxx-3c3173a3fb82",
  "eventTitle": "Order Created.",
  "eventType": "order_created",
  "eventData": {
    "orderId": "order::e5576e92-xxxx-xxxx-xxxx-3c3173a3fb82",
    "orderLink": "https://visit.example.com/shortUrl/a1b2c3d4e5f6a7b8"
  },
  "createdAt": { "$date": "2024-08-16T12:28:38.044Z" },
  "updatedAt": { "$date": "2024-08-16T12:28:38.044Z" },
  "__v": 0
}

`eventData` field	Type	Always?	Notes
`orderId`	string	✅	The created order's id
`orderLink`	string	⚠️	The patient's intake link. Sent only when the order's intake questionnaires are still incomplete — omitted when the intake is already complete, since the order submits on its own moments later. Expires 7 days after it is issued.

v2 payload

Sanitized envelope. orderId aliases to order_id (on the ORDER allowlist); order_status, subscription_status, and product_variation_ids are resolved from the order.

{
  "event_type": "order_created",
  "event_id": "event::8d367e3b-xxxx-xxxx-xxxx-3c6b7dfb804a",
  "api_version": "2026-08-17",
  "timestamp": "2026-05-30T14:00:00.000Z",
  "timestamp_epoch": 1780149600,
  "affiliate_id": "aff::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "patient_id": "pat::117eb3b9-xxxx-xxxx-xxxx-9424274b5425",
  "patient_external_id": "ext-patient-123",
  "patient_marketing_consent": false,
  "is_returning_patient": false,
  "order_id": "order::e5576e92-xxxx-xxxx-xxxx-3c3173a3fb82",
  "order_status": "started",
  "order_link": "https://visit.example.com/shortUrl/a1b2c3d4e5f6a7b8"
}

Field	Delivered in v2	Notes
Envelope + patient identity	✅	Includes `timestamp_epoch`
`order_id`	✅
`order_link`	⚠️	The patient's intake link, present only while the intake is outstanding. See Using the intake link
`order_status`, `subscription_status`, `product_variation_ids`	✅	Resolved from the order when present
`first_purchase`, `plan_type`	⚠️	Added at dispatch when an ecommerce order can be resolved
`attribution`, `journey_id`	⚠️	See Attribution Passthrough

Using the intake link

order_link is the same link Telegra sends the patient in its own "complete your order" email/SMS, so you can drive follow-up from your own CRM instead of relying on Telegra's reminder schedule.

Two things to build around:

This is a t=0 signal, not an "abandoned" signal. order_created fires the moment the order exists — while the patient is still being handed off into the intake, and most of them will finish normally. Treat the event as enrollment into a follow-up sequence, and cancel that sequence when the intake completes, which arrives as order_submitted (or journey_completed on the journey side). Without that suppression you will message patients who have already finished.
The link expires 7 days after it is issued. A sequence that runs past a week should stop rather than send a dead link. order_reminder_sent carries the link again with its 7-day window reset. One fires at order creation, and one fires whenever an affiliate triggers a resend through the API — neither depends on any project setting. Only Telegra's scheduled repeat reminders do: those go out only where the order's project has a reminder frequency configured. So a refresh may well arrive, but don't build your timing around one arriving on its own.