Overview
Push sends are asynchronous. PulseGrid accepts a notification into the server-side queue and workers perform the device deliveries.
SDK 0.2.0 automatically supplies an idempotency key for Push sends unless you provide one. For important business events, provide your own stable key such as order-1042-shipped so an application retry cannot create a duplicate campaign.
Supported SDK targeting includes device, AppUser ID, multiple AppUser IDs, topic and project roles.
Setup
1. Choose the smallest correct audience.
2. Use a stable business idempotency key when the send represents a business event.
3. Send title, optional body, application data and metadata.
4. Treat the API response as queued/accepted, not proof every device displayed the message.
5. Read notification history for final state.
6. Use topics for opt-in groups and AppUser targeting for known PulseGrid AppUser IDs.
7. Do not include passwords, payment-card data or private secrets in notification data.
Code example
await pg.push.sendToTopic("order-updates", {
title: "Order shipped",
body: "Order 1042 is on its way.",
data: { order_id: "1042" },
idempotencyKey: "order-1042-shipped",
});await pg.push.sendToDevice(deviceId, {
title: "Driver assigned",
body: "A driver has been assigned.",
});pg.push.send_to_topic(
"order-updates",
title="Order shipped",
body="Order 1042 is on its way.",
data={"order_id": "1042"},
idempotency_key="order-1042-shipped",
)pg.push.send_to_app_user_id(
app_user_id,
title="Account update",
body="Your account changed.",
)Notes
sendToUser/send_to_user is preserved for compatibility and currently maps to the internal PulseGrid AppUser UUID targeting helper.
If your business user IDs are different from PulseGrid AppUser UUIDs, store the mapping explicitly instead of assuming they are the same identifier.