Blooio n8n integrationAutomate Blooio with n8n.

This operation reports on the API key the credential carries: the organization behind it, the devices attached to it, and the usage statistics recorded against it. It takes no parameters at all, which makes it the cheapest call in the node.

One conversation, one response: the node returns the details of the chat you point it at, without the message history.

• Chat: the conversation identifier, either a phone number in E.164 format, an email, a group ID like grp_abc123, or several recipients separated by commas. Usually {{ $json.chatId }} from an earlier node.

Conversations can carry a background image. This call returns the metadata for the one currently set, so a workflow can tell whether a chat has been branded or left plain.

• Chat: the same conversation identifier used everywhere in the node, a phone number, an email, a group ID, or a comma-separated list of recipients.

Every conversation comes back in one array, most recent first by default. This is the entry point when a workflow has to work across threads rather than inside one.

• Limit: the maximum number of results returned in the call.
• Offset: how many items to skip, which is how you reach the second page.
• Search Query: matches on a phone number, an email, or a contact name.
• Sort: recent or oldest.

Every message in the conversation is marked read, and a read receipt goes back to the other side. It changes what the recipient sees, so it is not a silent bookkeeping call.

• Chat: the conversation to clear, given as a phone number, an email, a group ID, or a comma-separated set of recipients.

The background image is stripped from the conversation and it returns to its default look. There is no replacement step here, only removal.

• Chat: the identifier of the conversation to reset, phone number, email, group ID, or several recipients separated by commas.

Your contact card, meaning the Name and Photo identity, gets staged so that it travels with the next outgoing message. Nothing is sent by this call on its own. Dedicated Commercial and Enterprise plans only.

• Chat: where the card should be staged, as a phone number, an email, a group ID, or a comma-separated recipient list.

The contact book comes back as items, with search and paging available on the same call.

• Limit: caps how many contacts a single execution returns.
• Offset: skips the items already processed, for a second or third pass.
• Search Query: matches on the identifier or the name.
• Sort: recent, oldest, name_asc or name_desc.

A new contact is created from a single identifier. The display name is optional, so a workflow can register a number first and enrich it later.

• Identifier: a phone number in E.164 format, for example +15551234567, or an email address. Required.
• Name: the display name shown for the contact.

Point the node at one person and it returns that contact record on its own.

• Contact: the contact identifier, a phone number in E.164 format or an email address. Note that the field takes the identifier, not an internal ID you might have stored elsewhere.

Only one thing changes here, the display name of an existing contact. Leaving the name empty clears it rather than keeping the old value.

• Contact: the phone number in E.164 format or the email that identifies the record.
• Name: the new display name, empty to clear it.

The contact record is removed. Run it from a branch you control, since nothing in the node asks for a second confirmation.

• Contact: the identifier of the record to drop, a phone number in E.164 format or an email address.

Blooio answers whether that person can be reached over iMessage, over SMS, over FaceTime, or some combination of the three. The answer drives what you are allowed to send.

• Contact: the phone number in E.164 format or the email to test.

Reading side of the tagging system: the call returns the tags currently attached to one contact, nothing more.

• Contact: the contact identifier, in E.164 phone format or as an email address.

Tags are free-form here, so the vocabulary is yours to define and yours to keep consistent. Several can be attached in one call.

• Contact: the phone number in E.164 format or email address of the person being tagged.
• Tags: the free-form tags to add, entered with the Add Tag control.

One tag comes off, the others stay. The operation is deliberately narrower than adding, which accepts several at once.

• Contact: the identifier of the person, a phone number in E.164 format or an email.
• Tag: the single tag to remove.

All groups known to the account are returned, with the same search and paging controls the other list operations use.

• Limit: the maximum number of groups per execution.
• Offset: the number of groups to skip before reading.
• Search Query: matches on the group name.
• Sort: recent, oldest, name_asc or name_desc.

A group is created from a name, and can either stand alone or be attached to an iMessage conversation that already exists.

• Name: the group name, up to 255 characters. Required.
• Chat GUID: a BlueBubbles chat GUID such as iMessage;+;chat123, to link the group to an existing iMessage chat.
• Members: the phone numbers or emails of the contacts to include.

Details of a single group come back, keyed on its ID rather than on its name, since names are not unique.

• Group ID: the identifier in the grp_abc123 form, typically {{ $json.id }} carried over from the creation step.

Renaming is what this operation does. Members are handled elsewhere, so nothing about the roster moves here.

• Group ID: the grp_abc123 identifier of the group to rename.
• Name: the new group name. Required alongside the ID.

The group is removed from the account. Nothing else in the call, which makes it easy to run by mistake on the wrong ID.

• Group ID: the grp_abc123 identifier of the group to delete.

The roster of one group is returned, and it pages like the other collections rather than dumping everything at once.

• Group ID: the grp_abc123 identifier of the group to inspect.
• Limit: how many members come back per call.
• Offset: how many members to skip, to read the next page.

FindMy positions that Blooio has already cached for your contacts come back as one list. The call reads the cache rather than waking the devices, so it stays cheap to run on a schedule, and it asks for no parameters at all.

A single contact's cached position is returned, keyed by the handle rather than by an internal identifier.

• Handle: the contact's phone number in E.164 format or their email address.

Nothing comes back here: the call asks Blooio to refresh the cached FindMy positions. It takes no parameters at all, and it chains naturally with the read operations placed after it in the same branch.

The workhorse of the node: a text body, an attachment, or both, delivered into a conversation.

• Chat: a phone number such as +15551234567, an email, a group ID, or a comma-separated list of recipients.
• Text: the text body of the message.
• Attachments: publicly reachable URLs for images, videos or files.
• Idempotency Key: re-using the same key returns the original result instead of sending twice.
• Effect: an iMessage send-with-effect, ignored on SMS and RCS.

Details for one message are returned, which saves listing a whole thread just to recover what was sent or received.

• Chat: the conversation the message belongs to.
• Message ID: the msg_abc123 identifier of the message itself.

Sent is not the same thing as delivered. This call answers the second question and reports where a given message got to.

• Chat: the conversation holding the message.
• Message ID: the msg_abc123 whose status you want.

A conversation's messages come back as a filtered, paged collection, where the Get operation returns only one.

• Chat: the conversation to read.
• Limit and Offset: page size, and how many items to skip.
• Direction: inbound or outbound.
• Since (Ms Timestamp) and Until (Ms Timestamp): Unix timestamps in milliseconds that bound the window.
• Sort: desc for newest first, asc for oldest first.

Every phone number bound to the API key comes back in one array, with nothing to set on the node. It is the inventory call as soon as you send from more than one line.

Calls reaching one of your numbers can be pushed towards another line. The operation opens the request, it does not switch forwarding on by itself.

• Number: the source phone number in E.164 format.
• Forward To: the destination US number that should receive the calls, E.164 recommended.

The Name and Photo identity a number presents is set here, and only Dedicated plans get it.

• Number: the source number in E.164 format whose card changes.
• First Name and Last Name: the identity recipients see.
• Avatar (Base64): the profile photo as a base64-encoded JPEG or PNG string.
• Sharing Enabled: whether that identity is shared at all.

Validation and formatting for one number, with geocoding, taken one entry at a time. A Dedicated Enterprise plan is required.

• Number: the number to look up, in E.164, national, or already formatted notation.

The same check in bulk: up to 100 numbers travel in a single request, which keeps an import from turning into a long loop.

• Numbers: the list of numbers to look up, 100 at most per call. A Dedicated Enterprise plan is required.

A native iMessage poll is posted into a conversation, so answers arrive as votes rather than as free text somebody has to read.

• Chat: the conversation, given as a phone number, an email, or a group ID.
• Options: between 2 and 10 answers.
• Title: the question shown above the options.

The definition of a poll and its aggregated vote counts come back together.

• Chat: the conversation the poll was posted in.
• Poll ID: the identifier carried by the poll.created or poll.received webhook event.

Tapbacks and emoji go through the same operation, which removes as readily as it adds.

• Message ID: a msg_abc123, or a relative index where -1 is the last message.
• Reaction: prefixed with + to add or - to remove, using a classic tapback such as love or laugh, or any emoji.
• Chat: the conversation holding that message.
• Direction: inbound or outbound, useful only when the index is relative.

The typing indicator appears in the thread and buys a bot the beat a human would take before answering, and it works on iMessage only.

• Chat: the conversation where the indicator shows, given as a phone number, an email, or a group ID.

The twin call hides the indicator again, and it matters most when the branch that started it ends badly.

• Chat: the same conversation identifier the start operation was given.

Every webhook registered on the account comes back in one array, with no parameters to fill in. It is the starting point of any workflow that maintains subscriptions instead of creating them by hand.

A subscription is registered: Blooio starts posting its events to the URL you give it.

• Webhook URL: the endpoint that receives the events, often the production URL of an n8n Webhook node.
• Webhook Type: message, status, or all.
• Valid Until: an expiration timestamp in milliseconds, or -1 for no expiration.

One subscription is read back by its identifier, which is how a workflow checks what a given endpoint is actually configured for.

• Webhook ID: the wh_abc123 identifier of the subscription.

An existing subscription changes in place, without touching the identifier other systems already hold.

• Webhook ID: the wh_abc123 being modified.
• Webhook Type: switch the stream to message, status, or all.
• Valid Until: push the expiration timestamp in milliseconds further out, or set -1 to remove it.
• Deprecate: true marks the webhook deprecated, false brings it back.

The subscription is gone for good, and deliveries towards its URL stop as soon as the call returns.

• Webhook ID: the wh_abc123 to remove.

A fresh signing secret is generated for the subscription, and it is shown only once, in the response of this call.

• Webhook ID: the wh_abc123 whose secret is replaced.

Delivery attempts for a subscription are listed here, and this is where you look when an endpoint is suspected of dropping events.

• Webhook ID: the subscription whose deliveries you read.
• Limit and Offset: page size and how many entries to skip.
• Status, Min Status and Max Status: filter on an exact HTTP status code or on a range.
• Sort: desc for the newest, asc for the oldest.

An event already delivered once goes out again to the same endpoint, which saves reproducing the original conversation just to recover its payload.

• Webhook ID: the subscription that delivered the event.
• Event ID: the identifier of the event to replay.