Skip to main content
A hosted macOS session is a macOS user account on a Mac that iSnap hosts. It is meant to run the bridge app of your own BYOD iMessage line, under your own Apple ID: see BYOD lines. This page covers what the API does with a session: rent it, read it, cancel it, and learn when it is released. Read it if you are a wholesale partner and rent sessions through the API.

What a session is

  • A session is a macOS user account on a Mac that iSnap hosts. It is signed in to no Apple ID when you receive it.
  • A session is not a line: it has no number and sends nothing.
  • A session has its own resource, under /v1/macos-sessions, and its own id: mcs_ followed by 25 letters or digits.

Who can rent through the API

Wholesale partners only. POST /v1/macos-sessions/rent returns 403 not_a_wholesale_partner to any other account. See Accounts. A direct account cannot rent a session through the API: it buys hosted macOS sessions in the iSnap dashboard, by card. See Accounts. Only the account that rents a session, by a rent call or by an attach from iSnap, can read, update, cancel or uncancel it. Every other account receives 404 macos_session_not_found on those four operations, never 403.

Renting a session

One call to POST /v1/macos-sessions/rent rents one session. iSnap hands over a free session from its stock: one that is signed in to no Apple ID, hosts no line, and sits on a Mac that is delivered. The session is yours immediately, and anniversary_at is set to the time of the call. The response is 201 with the session. The body is optional. Its only field is metadata: any other field returns 400 validation_failed. The API sets no maximum number of sessions for a wholesale partner, and no rule ties that number to your BYOD lines. To rent three sessions, make three calls.
Send an Idempotency-Key with every rent. Without a key, every call rents one more billable session, a retry after a lost response included.An isnap_test_ account key is not a separate test environment: it acts on the same account, lines and billing as an isnap_live_ key. A rent sent with a test key rents a billable session.
POST /v1/macos-sessions/rent is the only operation of this page that honors Idempotency-Key. Use one key per session that you want, and reuse it only to retry the same request with the same body. The API remembers the key for 24 hours: after that, the same request with the same key rents another session. The rules are in Lines and hosted macOS sessions.
Response

When no session is in stock

With no free session, rent returns 409 no_macos_session_in_stock and records nothing: a retry with the same key runs again. After that refusal, iSnap can attach a session to your account later, without a new call from you, and then sends macos_session.rented. A session attached this way is not linked to the call that was refused. If you also call rent again and that call succeeds, you have two sessions. Choose one path: wait for macos_session.rented, or call rent again. Cancel a session that you do not need.

The session object

There is no operation that lists sessions. Store the id from the response of rent, and the macos_session_id of each macos_session.rented event.

Anniversary

The anniversary of a session is the UTC day of the month and time of day of anniversary_at. In a month that does not have that day, the anniversary falls on the last day of the month, then returns to the original day: a session with anniversary_at on January 31 at 14:32 UTC has its anniversary on the last day of February, then on March 31, both at 14:32 UTC. A cancellation ends the rental at an anniversary: see Canceling and keeping a session.

Canceling and keeping a session

POST /v1/macos-sessions/{id}/cancel schedules the end of the rental. It sets cancel_at to the next occurrence of the anniversary day and time strictly after the call: a cancel sent on the anniversary day after the time of anniversary_at ends the rental one month later, and one sent earlier that day ends it the same day. The session works until cancel_at. A second cancel returns the same cancel_at. The release comes after cancel_at; the API does not bound the delay. At the release:
  • the session returns to iSnap’s stock, and its metadata is cleared;
  • iSnap sends macos_session.released with reason: cancelled;
  • every later call on the session returns 404 macos_session_not_found.
Treat a session as released when macos_session.released arrives, or when a read returns 404. POST /v1/macos-sessions/{id}/uncancel withdraws a cancel. It clears cancel_at and keeps anniversary_at, so the anniversary does not move. Its result depends on when you call it:

What iSnap can do on its own

Two changes can happen without a call from you:
  • iSnap ends a rental. It can do so at any time. iSnap sends macos_session.released with reason: detached_by_admin, and the session returns 404 afterward.
  • iSnap starts a rental. It attaches a session to your account and sends macos_session.rented. The anniversary_at of that session can be in the past.
Subscribe to both events, and store the macos_session_id that macos_session.rented carries.

The BYOD line of a released session

When a released session was running the bridge app of one of your BYOD lines, even one whose device has stopped reporting, iSnap stops that bridge app and sends line.disconnected for the line. reason is scheduled_cancellation when the release follows your cancel, and admin_revoked when iSnap took the session back. A bridge app that runs on a Mac of your own is not affected. When you terminate a line that a session runs, the session is taken off the line and stays rented: cancel it with POST /v1/macos-sessions/{id}/cancel.

Metadata

Set metadata when you rent, and change it with PATCH /v1/macos-sessions/{id}. The body of the PATCH is required and has one field, metadata. Send Content-Type: application/json with every body.
  • The PATCH merges: a key that you send replaces the stored value, a key sent as null is deleted, and the other keys stay.
  • The result contains at most 20 keys and 8,192 bytes once serialized. Beyond that, the call returns 400 metadata_too_large.
  • The PATCH sends no event.
  • The macos_session.* events carry the metadata of the session in data.metadata.
  • iSnap clears the metadata when the session is released.

Events

Both events carry no line id: a webhook subscription with a line filter never receives them, even when the session runs one of the listed lines. Receive them on a subscription without a line filter. Their data.line_metadata is the metadata of the line the session runs, or ran until the release, when that line is yours, and null otherwise. The session events announce the two changes above, and no other. Your own calls send no event: rent, cancel, uncancel and PATCH. The response of each call is its only signal. The full list is in What events do not announce. To know the state of a session, read it with GET /v1/macos-sessions/{id}. Deduplicate on event_id: see Duplicates.

Line-scoped keys

The list of lines of a line-scoped key is not applied to hosted macOS sessions: such a key can rent, read, update, cancel and uncancel a session.

Errors

The refusals of each operation are on its reference page: POST /v1/macos-sessions/rent, GET /v1/macos-sessions/{id}, PATCH /v1/macos-sessions/{id}, POST /v1/macos-sessions/{id}/cancel and POST /v1/macos-sessions/{id}/uncancel. The errors that every operation shares are in Errors.

Personal data

The session object and the macos_session.* events carry no Apple ID, no email address and no phone number.