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 everyline.* 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.
- A subscription that is suspended, resumed or turned inactive, including after a
410response. - A signing secret that is rotated.
- A subscription that is created, changed or deleted.
- 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 inmessage.read. Never put secrets in messagemetadata, 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.terminatedand no other event. - A BYOD line ended because the BYOD slots of the account no longer cover it:
line.disconnectedis sent,line.terminatedis not. - A line that iSnap terminates:
line.terminatedis sent,line.disconnectedis 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.
- A change of a line’s configuration (
PATCH /v1/lines/{id}/config) ormetadata(PATCH /v1/lines/{id}). - A device session that is replaced by a new pairing on the same line, or revoked by iSnap.
line.disconnectedcovers 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 thanimessage,sms_fallback,send_textandsend_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.
- 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.
- 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.
- 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.
- Your own rent, update, cancel and uncancel calls.
- A binding that is created: the first
message.queuedormessage.scheduledto a new contact is the signal. - Chats, attachments (including an attachment that becomes
ready,failedorexpired), recipient lookups and their results, API keys, billing and invoices: no event family exists for them.