Read and send Bluesky direct messages through one integration, on one of only two networks where this is genuinely available.
List conversations, read one, and reply, through the same shapes you use everywhere else.
curl "https://api.postlake.dev/v1/conversations?limit=50" \
-H "Authorization: Bearer $POSTLAKE_API_KEY"Every list returns problems alongside the items, naming any network that could not be read. Without that an empty inbox is ambiguous: "nobody messaged" and "we could not look" are the same response, and an agent acting on the first when the second is true will conclude something false.
Post to /v1/conversations with a handle to open a thread, then send into it. Replies read back in the same shape, so a support loop is a poll of one endpoint rather than a per-network integration.
Bluesky exposes direct messages through its chat API, and access depends on how the app password was created: the box allowing access to direct messages must be ticked at the time. It cannot be added to an existing password, so a connection made without it needs a new one.
Yes, Bluesky is one of the two networks where this is genuinely available. Conversations and messages come back in the same shape as every other read.
Because most do not expose it. Meta requires a heavy app review and business accounts, LinkedIn is partner-only at enterprise pricing, and TikTok, YouTube and Pinterest offer nothing to applications. Any product implying a nine-network inbox is describing something that does not exist.
No, and you should not want to. Unsolicited automated messaging is what gets accounts restricted on every network that offers messaging at all. This is built for replying to people who contacted you.
Yes, with list_conversations, read_conversation and send_message over MCP. Restrict which brands and networks it may act on before you let it run.