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.
- 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: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 for the full header reference, or Push API (Legacy) for the v2 endpoint details.FAQs
Does the Push API support silent notifications?
Does the Push API support silent notifications?
No, the MoEngage Push API currently does not support silent (data-only) notifications.
Can I use HTML to format notification text?
Can I use HTML to format notification text?
Yes, the basic template supports standard HTML tags for text formatting on supported platforms.
What happens if personalization fails for a specific user?
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.How do I target a user using their device token directly?
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.What does v2.1 change compared to the legacy v2 endpoint?
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.