Skip to main content
Every event iSnap sends has the same envelope and one of 37 event types. This page describes the envelope, lists the types with the moment each one is sent, explains the two metadata fields every event carries, and lists the changes that no event announces. Read the last section before you build a copy of iSnap data from events alone.

Envelope

An event is a JSON object with six fields. The same object is the body of a delivery and an item of the events feed.
Events carry personal data: message text, handles, contact names and attachment file names. Each event page lists the fields. Subscribe only to the event types you need. Do not copy personal data into logs, tickets or other tools, and refer to a contact by an id of your own. Read event_id and event_type: the envelope has no id and no type field. Ignore response fields, enum values and event types you do not know. Return 2xx for an event type you do not handle. See Versioning and compatibility.

Event types

Each “Sent when” cell is a summary. The event page states the exact cases, and the cases in which the event is not sent.

Line events by line kind

Not every line kind gets every line.* event. A shared line has no device of its own. Besides the rows above, it never gets message.sent with origin: "device" or a typing_indicator.* event, and its inbound message.received is sent only for a contact the line has an active binding with.

metadata and line_metadata

Every event carries both fields in data, whatever its type. They hold the metadata you attached to resources, so that you can route an event without a second call. data.metadata is the metadata of the main resource of the event: It is null when that resource has no metadata, and when the resource is not yours. On a line that another account owned before you, an event about a message of that account carries data.metadata: null. A message event still carries the metadata of that message in data.message.metadata: see Lines that change owner. data.line_metadata is the metadata of the line the event is tied to, when that line belongs to your account. It is null otherwise: the event is tied to no line, the line has no metadata, or the event belongs to a trial that runs on a line you do not own. The macos_session.* events are the exception: they carry no line id and a line filter never matches them, and their line_metadata is the metadata of the line the session runs, or ran until the release, when that line is yours. On line.* events it equals data.metadata. Both fields are read once, when the event is recorded. Retries and replays carry the same values, even if the metadata changed since. Never put personal data or secrets in line metadata: it is readable by anyone who holds the line id, and it stays on a line that returns to the marketplace. See Managing lines.

What events do not announce

The events announce the changes this catalog lists, and no other. Two rules apply before any list:
  • An event is recorded only if it matches an active subscription when it occurs. While a subscription is suspended or inactive, the events it would have matched are not recorded for it: they are not delivered later, cannot be replayed, and are absent from the events feed unless another active subscription of your account matched them.
  • An event can be lost. A change can stand without its event, which is then neither delivered nor listed in the events feed. Reconcile from the resource operations.
Events also do not announce the following. Webhook subscriptions
  • A subscription that is suspended, resumed or turned inactive, including after a 410 response.
  • A signing secret that is rotated.
  • A subscription that is created, changed or deleted.
Lines: ownership and status
  • A line that is reserved, activated, assigned or released, a reservation that expires, and a shared line that is created.
  • A line transferred to another account, for the earlier owner and for the next one. The device sessions a transfer ends produce no line.disconnected.
  • A line that leaves your account: the delivery statuses, read receipts and reactions that its device reports afterward about the messages you sent on it go to the account that owns the line at that time, or to no account when the line has no owner. Each message event carries the message it concerns, with its text, its handles, its attachment file names and its metadata; a reaction event carries the id of that message and the handle of the contact. You do not receive them. A mark-read by the next owner also marks read the inbound messages you had not marked read, and sends their content to that owner in message.read. Never put secrets in message metadata, and refer to a contact there by an id of your own. See Lines that change owner.
  • A line that iSnap suspends, and the end of that suspension. The device sessions a suspension ends produce no line.disconnected.
  • A rented line that returns to the marketplace because its per-line subscription ended: no line.terminated and no other event.
  • A BYOD line ended because the BYOD slots of the account no longer cover it: line.disconnected is sent, line.terminated is not.
  • A line that iSnap terminates: line.terminated is sent, line.disconnected is not.
  • A cancellation that is scheduled or withdrawn (POST /v1/lines/{id}/cancel, POST /v1/lines/{id}/uncancel). The events come when the cancellation is carried out.
  • An anniversary that is set, and a conversion to or from a test line.
  • A scheduled variant change that is dropped, when the line is released, transferred or turned into a test line, or at the billing anchor when the line is suspended or already has that variant: no line.variant_unscheduled.
Lines: settings, health and number
  • A change of a line’s configuration (PATCH /v1/lines/{id}/config) or metadata (PATCH /v1/lines/{id}).
  • A device session that is replaced by a new pairing on the same line, or revoked by iSnap. line.disconnected covers only the cases its section lists.
  • For a rented, shared or test line: an outage shorter than 15 minutes and its end, a line that stops receiving or recovers, and a capability change.
  • For a BYOD line: a capability that moves to or from disabled, and a change of a capability other than imessage, sms_fallback, send_text and send_attachment.
  • An Apple ID flag that is cleared. A device report that repeats an existing flag sends nothing either.
  • A sending-limit counter that falls back below a threshold or resets.
  • A phone number that changes or is corrected, and the number of a BYOD line when its device first reports it.
Messages, reactions and typing
  • A delivery status, a read receipt or a reaction that concerns a message that iSnap has deleted at the end of its retention.
  • A status the message already has, a second copy of an inbound message, and history that a device reports from before iSnap was watching the line.
  • A message typed on the device of a shared line or of a line that runs trials: no message.sent.
  • An inbound message that iSnap does not record: on a shared line, a message from a contact the line has no active binding with; on a line that runs trials, a message from a sender who is not paired.
  • A message deleted at the end of its retention. An edited or unsent message is not reported at all.
  • A canceled message of a trial: no message.cancelled.
  • A typing indicator you start or stop.
  • A reaction that the line’s device fails to place, and a reaction or a removal that never reaches a device.
Trials
  • A trial that is created or updated, and a pairing window that expires.
  • A text that matches no pairing code, and the confirmation and limit notices iSnap sends to the prospect.
Pre-orders
  • A pre-order that is created or confirmed, and a first month that is paid.
  • An order that iSnap cancels behind a pre-order whose build has started.
  • An estimated fulfillment time that passes.
Hosted macOS sessions
  • Your own rent, update, cancel and uncancel calls.
Other resources
  • A binding that is created: the first message.queued or message.scheduled to a new contact is the signal.
  • Chats, attachments (including an attachment that becomes ready, failed or expired), recipient lookups and their results, API keys, billing and invoices: no event family exists for them.

How to reconcile

Treat events as a signal to act fast, and the resource operations as the source of truth. Read the state again on a schedule, and after any period in which your endpoint was down or your subscription was suspended or inactive.