Appearance
Guides
Task-shaped walkthroughs for the FluidTalk Characters API. Each one takes a job you actually have — answer a DM, open a conversation, comment in public, follow up on someone who went quiet, run one character on several accounts — and shows the calls end to end, with the traps named.
The reference is the field-by-field contract. These are the parts that are hard to work out from a schema: which endpoint belongs to which motion, what a 200 with nothing in it means, and which defaults will surprise you.
New here? Read the Quickstart first, then Authentication and Core concepts.
| Guide | What it covers |
|---|---|
| Sending & receiving DMs | The workhorse loop: push an inbound message, get the character's reply as bubbles, relay a photo the lead sent. |
| Triggers & openers | Starting a conversation rather than answering one — outreach, event triggers, and why testing outreach live works exactly once. |
| Comments, replies & engage | The three public-comment motions: comment on a post, reply to someone who answered you, and join a conversation between other people. Plus images and vision.seen. |
| Proactive follow-ups | The pull queue for leads who went quiet — sweeping, delivering, and acknowledging. |
| Multiple accounts (dedup) | Running one character across several accounts on the same platform without two of them answering the same person. |
The one rule that spans all of them
FluidTalk never touches the platform. Every endpoint here generates text and tracks the relationship; your connector does the reading and the posting. That is why a call can succeed and still hand you nothing to send — comments switched off, a stop rule, a character over its plan's cap, or a character that read a thread and decided none of it was its business.
So across every guide: branch on the field you were going to use being present, never on the HTTP status. 200 means we processed the request, not that there are words to post.