Hub Chatt2.me API

Hub Chatt2.me is a unified messaging API that lets you send and receive messages across multiple channels — WhatsApp, Instagram, Facebook Messenger, Telegram, SMS, and Web Chatt — through a single, consistent interface.

Instead of integrating each platform separately, you connect your channels once and use the same request structure across all of them. Hub Chatt2.me handles the provider-specific complexity, authentication quirks, and delivery routing so you can focus on your product.

Self-service onboarding

Account creation does not require contacting sales or entering payment details. API usage may require balance or provider setup, depending on the channel and operation.

1. Create your Hub account.
2. Verify the email address used during signup.
3. Create an Application in Hub.
4. Open Settings → API Key, generate a key, and copy it when shown.
5. Configure a WhatsApp, Instagram, or Messenger sandbox.
6. Send an HTTP request from the chatt2.me Hub API Reference with the key in x-api-key.
7. Register/verify a webhook and subscribe the channel to receive messages and delivery updates.

See Authentication for key handling and examples.

What you can do

• Send messages across all supported channels with a unified API
• Receive messages in real time via webhooks
• Track delivery status (sent, delivered, read) via message_status events
• Use rich content — interactive buttons, templates, location sharing, file attachments, and more
• Send payment requests (PIX, Boleto, payment link) and order status updates via WhatsApp
• Keep unwanted senders out of your workflow with channel-specific ignored contacts
• Review conversations with Session Assist and CX Score

Base URL

Environment	URL
Production	https://app.chatt2.me

All API routes are prefixed with /v1.

Authentication

Management and messaging requests identify the Application using its API Key. The six Public Calendar operations explicitly declare anonymous access; see Calendar booking.

Scheme	How to send
API Key	Header x-api-key: <your-api-key>

See more details in Authentication.

Conventions

• Request/response bodies are JSON by default. Successful DELETE operations can return 204 with no body; Public Calendar avatar reads can redirect to an image URL. Check the HTTP status/content type before parsing JSON.
• IDs use the UUID v4 string format (e.g. eba8d8ef-ec4d-41ad-825f-9a60ccda49bf).
• The from field accepts the channel UUID registered in your Application or the documented provider-specific identifier. Web Chatt requires the UUID; see Sending messages.
• The to field is the recipient identifier in the specific channel (phone number, chat ID, PSID, etc.).

Errors

HTTP errors use the common response shape:

{
  "statusCode": 400,
  "code": "INVALID_EVENTS",
  "message": "INVALID_EVENTS",
  "hint": "Review the request fields and retry.",
  "errors": [{"field": "events", "code": "INVALID_EVENTS"}]
}

statusCode, code, message and hint provide the HTTP status, stable machine code and recovery guidance. errors is an optional array of field errors; entries may contain details. Certain operations add safe details such as an appointment currentVersion, current snapshot or available alternatives. Handle unknown extra fields without discarding the common fields.

HTTP	Meaning / operation-specific guidance
400	Invalid fields, combinations or query values; follow errors / hint
401	Missing/invalid/revoked/expired key or unavailable application/access; Authentication
402	Insufficient funds where the operation charges usage; sending messages
404	Resource absent or outside this key's application
409	Concurrent change/retry conflict; appointments or webhook retry
429	Operation rate limit; follow its retry guidance/headers
503	Service/delivery temporarily unavailable; inspect the operation's reference before retrying

The API reference lists statuses/codes supported by each operation; these are not universal promises for every endpoint. A send result with status: "error", errorMessage, errorCode, or a message_status event describes provider delivery, not this HTTP error envelope. An accepted send can fail later; subscribe to status events.

Next steps

• Authentication — how to obtain and use your API Key
• Concepts & Architecture — understand Applications, Channels, and Webhooks
• Sending messages — content types and request structure
• Conversation tools — ignored contacts and session analysis

Assistant onboarding

Hub MCP actions explains browser OAuth, team contexts and human approval. Application API keys authenticate HTTP API calls; they do not authenticate the MCP connection. Additional API key issuance requires MFA in the Hub.