> ## Documentation Index
> Fetch the complete documentation index at: https://moengage-pm41-nat-ips.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Push Overview

> Create campaigns and send personalized push notifications to individual users or segments across Android, iOS, and Web.

The MoEngage Push API allows you to trigger push notifications. It is designed for high-throughput transactional and marketing use cases, supporting complex targeting logic and deep personalization for every recipient.

<Note>
  Ensure you select the API that corresponds to your specific use case:

  * **Transactional:** For system-triggered events (for example, OTPs, status updates), use the Push API.
  * **Non-Transactional:** For marketing, promotions, and broadcast messages, MoEngage highly recommends you use the [Push Campaigns API](/api/create-campaigns/create-campaign).
</Note>

Use this API to:

* **Target Segments:** Send notifications to all users or specific pre-defined segments.
* **Target Individuals:** Reach a single user using unique attributes like Email, Mobile Number, or Unique ID.
* **Personalize at Scale:** Use Jinja templating to dynamically inject user-specific data into the notification payload.

## API Versions

MoEngage introduced v2.1 of the Send Push Notification endpoint to strengthen security and provide more granular rate limiting, including support for IP whitelisting. Two versions of the endpoint are available:

| Version            | Endpoint                                       | Notes                                                                                                                                                                                                                                                                                   |
| :----------------- | :--------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **v2.1** (current) | [Push API](/api/push/push-api)                 | Sends `appId` and `signature` as request headers (`X-MOE-APPKEY` and `X-MOE-PushAPI-Signature`) instead of request-body fields, and adds an `X-MOE-Query-Type` header corresponding to the `targetAudience` field. All other request body and response structure are unchanged from v2. |
| **v2** (legacy)    | [Push API (Legacy)](/api/push/push-api-legacy) | The original version of this endpoint. `appId` and `signature` are sent as request-body fields. Fully supported for existing integrations.                                                                                                                                              |

<Note>
  To adapt v2.1, move `appId` and `signature` out of the request body and send them as the `X-MOE-APPKEY` and `X-MOE-PushAPI-Signature` headers. Every other request body field, and the response structure, stays the same. See [Push API](/api/push/push-api) for the full header reference, or [Push API (Legacy)](/api/push/push-api-legacy) for the v2 endpoint details.
</Note>

## FAQs

<AccordionGroup>
  <Accordion title="Does the Push API support silent notifications?">
    No, the MoEngage Push API currently does not support silent (data-only) notifications.
  </Accordion>

  <Accordion title="Can I use HTML to format notification text?">
    Yes, the basic template supports standard HTML tags for text formatting on supported platforms.
  </Accordion>

  <Accordion title="What happens if personalization fails for a specific user?">
    You can provide a `fallback` object within the payload. If the personalization logic fails (e.g., a missing user attribute), the system will automatically send the fallback content instead.
  </Accordion>

  <Accordion title="How do I target a user using their device token directly?">
    In the `targetUserAttributes` object, set the `attribute` field to `PUSH_ID` and provide the device token as the `attributeValue`.
  </Accordion>

  <Accordion title="What does v2.1 change compared to the legacy v2 endpoint?">
    v2.1 strengthens security and rate limiting, including support for IP whitelisting. It moves `appId` and `signature` from the request body to the `X-MOE-APPKEY` and `X-MOE-PushAPI-Signature` headers, and adds an `X-MOE-Query-Type` header. Every other request body field and the response structure are unchanged from v2. MoEngage recommends v2.1 for all new integrations. The legacy v2 endpoint remains fully supported for existing integrations.
  </Accordion>
</AccordionGroup>

## Postman Collection

We have made it easy for you to test the APIs:

* [v2.1 Postman collection](https://www.postman.com/moengage-dev/api-docs/collection/5ujszpd/moengage-transaction-push-api-v2-1?action=share\&source=copy-link\&creator=5883765)
* [Legacy v2 Postman collection](https://www.postman.com/moengage-dev/api-docs/collection/acmujor/moengage-transaction-push-api-v2?action=share\&source=copy-link\&creator=5883765)