Get one community bot
One bot the caller owns. A missing id, a deleted id, and another user's id all return the same 404 with the same message. A route that could tell them apart would be an id oracle for other users' bots.
One bot the caller owns. A missing id, a deleted id, and another user's id all return the same 404 with the same message. A route that could tell them apart would be an id oracle for other users' bots.
Authorization
bearerAuth A bearer token. The Account routes accept a Privy access token; the MCP transport accepts an sk- API key issued by POST /account/api-keys.
In: header
Path Parameters
The bot's id.
Response Body
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/community/bots/string"{ "id": "string", "ownerId": "string", "platform": "telegram", "chatId": "string", "displayName": "string", "chainSlug": "ethereum", "tokenAddress": "string", "tokenSymbol": "string", "autoPostReceipts": true, "postCountdowns": true, "createdAt": "string", "updatedAt": "string"}Register a community bot POST
Registers a bot that gates a chat on holdings of one token. The bot's own platform token is **not** accepted here and putty never stores one: the bot runs on the user's own host, which holds the credential. What this registers is the gate — the chain, the token, and the chat — which is the part putty can prove and the host cannot. Both auto-post switches default to false. A bot that posts every Receipts update and every countdown on its own spends the community's attention, so turning them on is a separate, deliberate call.
Turn the bot's auto-posting on or off PATCH
Flips the two auto-post switches. A field that is omitted keeps its current value, so a caller turning on countdowns does not also have to repeat the Receipts setting. This is the only way either switch changes after registration: nothing else in the Kit writes them, so the value here is the value the bot acts on.