> For the complete documentation index, see [llms.txt](https://docs.360dialog.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.360dialog.com/docs/inbox/inbox-api.md). # Inbox API Put WhatsApp inside your own product or service, and let the Inbox keep the conversations. The Inbox API is a REST API over the same backend as the hosted Inbox. Your software reads conversations, sends messages and gets told when something new arrives. The Inbox keeps the history, tracks the conversation windows, hosts the media, and fans the single WhatsApp webhook out to every service that needs it. You keep your interface and your workflow. You do not build the conversation layer. {% hint style="info" %} The Inbox is available to 360dialog direct clients on the Premium plan, at no extra charge. {% endhint %} ## When to use it | You want to… | Use | | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Show and answer WhatsApp conversations inside your CRM, helpdesk or product | **Inbox API** | | Connect several services to one number — a bot, a CRM, a data pipeline — without them fighting over one webhook | **Inbox API** | | Let a bot answer first and a person take over when needed | **Inbox API** together with the [Hosted Inbox](/docs/inbox/hosted-inbox.md) | | Let an AI agent send and receive WhatsApp messages | **Inbox MCP** | | Only send messages and handle raw WhatsApp webhooks yourself, with no stored history | The WhatsApp API directly. [See Messaging API](https://docs.360dialog.com/docs/messaging) | ## How it fits together A customer writes to your number. The Inbox stores the message, updates the chat, and calls the webhook of every service you connected. Your service replies through the API, the Inbox sends it through your channel, and reports back when it is sent, delivered and read. Everything is shared. A reply your service sends shows up in the hosted Inbox, and a reply your team types in the hosted Inbox shows up in the API. That is what makes a bot-plus-human setup work without extra glue. ## What the Inbox does for you, and what it leaves to you | The Inbox handles | You decide | | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | | Storing chats, contacts and full message history | Which service or person handles which chat — the API gives you assignment, not routing rules | | When each conversation window expires, per chat | What to send, and when a template is needed | | Media upload and hosting | Where your master customer data lives — your CRM or product stays the source of truth | | One webhook per service, from the single WhatsApp webhook | How your service reacts to each event | | Assignment, tags and resolved status, shared with the hosted Inbox | How your team and your automations split the work | Each number has its own Inbox, its own URL and its own storage. Up to 1.5 million messages are kept per Inbox; beyond that, the oldest are removed first. ## In this section | Page | What it covers | | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | [**Quickstart**](/docs/inbox/inbox-api/quickstart.md) | Connect, start a conversation from your phone, and reply through the API | | [**Authentication**](/docs/inbox/inbox-api/authentication.md) | Create a user for each service and get its token | | [**Receiving messages**](/docs/inbox/inbox-api/receiving-messages.md) | Get new messages delivered to your endpoint | | [**Sending messages**](/docs/inbox/inbox-api/sending-messages.md) | Replies when the window is open, templates when it is closed | | [**Reading conversations**](/docs/inbox/inbox-api/reading-conversations.md) | Your chats and their message history | | [**Managing conversations**](/docs/inbox/inbox-api/managing-conversations.md) | Assignment, tags and resolved status | | [**Contacts**](/docs/inbox/inbox-api/contacts.md) | Who you are talking to, and how to identify them | | [**Playbooks**](/docs/inbox/inbox-api/playbooks.md) | Complete setups for the most common integrations | | [**Reference**](/docs/inbox/inbox-api/reference.md) | Request basics and every endpoint | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.360dialog.com/docs/inbox/inbox-api.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.