Superchat

List the workspace's webhook subscriptions, via GET /webhooks. Each subscription carries its `id` (`wh_...`), its HTTPS `target_url`, a `delivery` block whose `status` says whether Superchat is still delivering to it and whose `reason` says why it stopped, the `events` it is subscribed to with their filters, and its timestamps. THE SIGNING SECRET IS REMOVED BEFORE YOU SEE IT, and that is this integration's doing rather than Superchat's: the provider's own schema marks `secret` required on every subscription, and that value is what a receiver checks a delivery signature against -- so returning it would hand out the ability to forge Superchat webhook deliveries to the customer's endpoint. The key is kept with a marker in place of the value, so a subscription that genuinely has no secret is still distinguishable. Paged with a CURSOR, not a page number: read `pagination.next_cursor` and pass it as `after`. THIS IS ALSO THE CONNECTION'S HEALTH CHECK -- it is the route this provider's probe declares, chosen because it is free, side-effect-free, and returns an empty list rather than the workspace's messages or contacts on an account that has no webhooks.

Replace a contact's name, gender, handles and custom attributes, via PATCH /contacts/{contact_id}. IT IS A PATCH IN NAME ONLY, AND THAT IS THE WHOLE RISK. Superchat REQUIRES `first_name`, `last_name` and `gender` on every call -- omitting one is a 400 -- and all three are nullable, so a body that sends null to satisfy the requirement CLEARS the name it was meant to leave alone. `handles` and `custom_attributes` are worse: the provider documents each as 'the full list ... that should remain on this contact', so an entry left out of the array is DELETED from the contact. Sending one handle to a contact that has three removes the other two, and the reply looks like an ordinary success. READ THE CONTACT FIRST AND RESEND ITS CURRENT VALUES -- and note that this integration ships no contact read (the research ledger recorded three operations and `GET /contacts/{id}` is not among them), so those values have to come from Superchat's own API or UI before this tool is called. A handle entry needs `id` and `value` even when you are only keeping it; `id: null` creates a new one. Only `mail` and `phone` handles can be written -- the platform-created kinds (instagram, telegram, facebook_messenger, live_chat, google_business_messaging, whats_app_username) are reported on reads and are not writable here. Custom attributes are named by their `cat_...` id and their `value` is typed by the attribute. It is filed as a WRITE rather than a destruction because the contact itself survives every call; the confirm gate is for tools that remove a resource, and putting one here would sit in front of the ordinary case as well.

Send a message to one recipient on a Superchat channel, via POST /messages. THIS REACHES A REAL PERSON and cannot be recalled: there is no unsend on this API, and on WhatsApp or SMS the message is delivered by a carrier the moment Superchat accepts it. `from.channel_id` decides the PLATFORM -- WhatsApp, SMS, Instagram, Facebook Messenger, Telegram or e-mail -- and therefore how `to[0].identifier` must be spelled and which `content` shapes are legal; this integration ships no channel listing, so that id comes from Superchat's own API or its Settings UI. `to` IS CAPPED AT ONE RECIPIENT by the provider: there is no broadcast here, and reaching several people means several calls. A `content` whose `type` does not match its shape is Superchat's own 400 'Message type must match content'. ON WHATSAPP THE 24-HOUR WINDOW DECIDES WHAT IS ACCEPTED: outside it, only an approved template (`whats_app_template`) goes through, and a free-form `text` is refused. AN UNKNOWN `identifier` CREATES A CONTACT rather than failing, so a typo in a phone number makes a new contact and messages a stranger. The 200 reply carries the message's `id` (`msg_...`), its `conversation_id` and a `status` that is only the SUBMISSION state -- `processed` or `sent`, later `received` or `read`, or `sending_failed` if the channel rejects it afterwards. This surface ships no message read, so a later status is not observable from here.