Zernio
Zernio
API Reference

Messages

Conversations

List conversationsGETSearch conversationsGETCreate conversationPOSTGet conversationGETUpdate conversation statusPUTMark a conversation as readPOSTChange who answers a conversation (handover)POST

Messages

List messagesGETSend messagePOSTEdit messagePATCHDelete messageDELETEUpload media filePOSTResolve message attachmentGET

Reactions & Typing

Add reactionPOSTRemove reactionDELETESend typing indicatorPOST

Other

Accept a message requestPOSTDelete conversationDELETE
Dashboard
llms.txtOpenAPI
OverviewPlatformsAPI ReferenceResources
Messages

Delete conversation

Permanently deletes Zernio's stored copy of one conversation and every message in it, in one transaction, and unlinks the contact channel that pointed at it. Nothing is deleted on the platform (the thread stays in WhatsApp, Messenger or Instagram), and the contact record is kept: call DELETE /v1/contacts/{contactId} to erase the person's name and number as well. A platform re-sync can import the thread again: WhatsApp coexistence numbers receive their messaging history from Meta repeatedly, and a Facebook or Instagram account whose DM history walk has not finished imports it on that walk. Inbound media copies Zernio stored are removed on a best-effort basis.


DELETE
/v1/inbox/conversations/{conversationId}

Authorization

bearerAuth
AuthorizationBearer <token>

API key authentication: send your Zernio API key in the Authorization header, prefixed with Bearer.

In: header

Path Parameters

conversationId*string

Opaque conversation identifier, accepted verbatim from the list endpoint or from the conversationId on inbox webhooks. Format not to be assumed.

Query Parameters

accountId*string

Account ID

Response Body

application/json

application/json

application/json

import Zernio from '@zernio/node';const zernio = new Zernio({ apiKey: process.env.ZERNIO_API_KEY });const { data } = await zernio.messages.deleteInboxConversation({  path: {    conversationId: 'conversation_abc123',  },  query: {    accountId: 'account_abc123',  },});console.log(data);
{  "success": true,  "data": {    "id": "string",    "accountId": "string",    "platform": "string",    "deletedMessages": 0  }}
Was this page helpful?

Accept a message request

Accept a Facebook or Instagram Message Request (listed with `GET /v1/inbox/conversations?folder=requests`) by replying to it. Meta has no separate accept call: the first reply is what moves the thread into the inbox, so this sends `message` through the same path, checks and webhooks as `POST /v1/inbox/conversations/{conversationId}/messages`, and answers the same way. Supports the `Idempotency-Key` header.

List commented posts

Returns posts with comment counts from all connected accounts. Aggregates data across multiple accounts. Responses are cached for up to 10 minutes, so the feed may lag new comments by that window. Do not poll this endpoint for real-time updates: subscribe to the `comment.received` webhook, which fires for every new comment across your posts and carries the post reference needed to keep this list current. For users with the Ads add-on (accounts on usage-based billing always qualify), the user's Meta ads (boosted/dark posts) are included too. There's one row per (ad, placement-with-comments): an ad that runs on both Facebook feed and Instagram feed produces up to two rows (the Page dark post and the IG media have separate comment threads), each flagged `isAd: true` with `adId` and `placement` (`id` is `{adId}:{placement}`). Use `?platform=metaads` to return *only* ad rows; passing `facebook`/`instagram` returns *organic* posts only (no ads); omitting `platform` returns both. Fetch a row's thread from GET /v1/ads/{adId}/comments?placement={placement}. Ad comment counts are read with the Marketing API token (Facebook side) or the connected Instagram account's token (Instagram side); a row whose count can't be read is omitted. Pagination walks each account's platform listing. Following `nextCursor` reaches past the first page on Facebook, Instagram, Threads, LinkedIn and YouTube, since they are the platforms that support a server-side date window; on the others the listing stops at its first page. Cursor pagination is only coherent for the default sort (`sortBy=date`, `sortOrder=desc`): with `sortOrder=asc`, or with `sortBy=comments`, the cursor filter does not match the sort order and the second page is unreliable. `minComments` is applied to each page after pagination: a page can hold fewer than `limit` posts, even none, while `hasMore` is true; keep following `nextCursor`. `nextCursor` is opaque: pass it back verbatim, never construct or parse it, its composition may change without notice. Because each page re-queries a live window, results can still shift between requests, so dedupe by `id` on the client. `commentCount` semantics differ by platform: YouTube's includes replies, Facebook's counts top-level comments only.