Skip to content

Latest commit

 

History

History
105 lines (81 loc) · 4.32 KB

push.md

File metadata and controls

105 lines (81 loc) · 4.32 KB

Push — choosing an audience and a provider

← Back to the notifications reference

notifications.md lists every push method with its verb, path and scope. Two of them take a body whose shape the server picks from a discriminator inside that body, which the signature cannot show. This page covers those two.

Everything here is asserted in tests/hub/test_push.py.

Choosing who a campaign goes to

create_push_campaign reads the audience from campaign["source"]. Send that field plus the audience's own fields:

audience source own fields
everyone in the project allUsers rolesNames, userTags (both optional filters)
a named list of project users specifiedUsers userRecipients
a named list of account users accountUsers userRecipients
rows of a database collection collection schemaName, fields (the record fields that hold the recipient), fieldType (User or Email), optional roleNames, languages
raw device tokens devices devices: a list of { token, deliveryFamily }, deliveryFamily one of Ios, Android, Chrome, Safari, Expo

Every target also takes templateId and integrationId (both required — integrationId is the push provider, from get_push_integrations), and the optional language, notes, campaignTime (Unix seconds) and mappedTokens. Note the spelling: rolesNames on allUsers, but roleNames on collection — the gateway names them differently.

client.hub.notifications.create_push_campaign(
    campaign={
        "source": "allUsers",
        "templateId": "tpl_123",
        "integrationId": "int_push",
        "userTags": ["beta"],
    }
)

Send source as the name, not a number — the server reads it as a string.

Choosing a push provider

save_push_integration works the same way, with integration["provider"]:

provider provider value own fields
Fake (sandbox, never sends) Fake none
Android / Firebase AndroidFirebase projectId, clientEmail, serviceAccountJson
Apple APNs AppleApns teamId, appBundleId, keyId, privateKey, isProduction
Chrome extension ChromePush extensionId (a GUID), vapidPublicKey, vapidPrivateKey, optional subject
Chrome web ChromeWeb vapidPublicKey, vapidPrivateKey, optional subject
Edge web EdgeWeb vapidPublicKey, vapidPrivateKey, optional subject
Firefox web FirefoxWeb vapidPublicKey, vapidPrivateKey, optional subject
Safari SafariPush websitePushId, certificateP12Base64, certificatePassword

Every provider also takes integrationName and isEnabled; send integrationId to update an existing one. The Chrome extension value is ChromePush. The generated types also list CodeMashChromePlugin and other CodeMash* values — the server rejects those here with "Unsupported provider".

client.hub.notifications.save_push_integration(
    integration={"provider": "Fake", "integrationName": "sandbox", "isEnabled": True}
)

Use Fake in tests and local development. It accepts a send and contacts no push service, so nothing reaches a real device.

Registering a device

A device is registered for one user. Send the device under pushDeviceDto (deviceOs and token are required; deviceId, brand, manufacturer, modelName, deviceName, deviceType are optional) plus userId:

client.hub.notifications.register_device(
    userId="user_123",
    pushDeviceDto={"deviceOs": "iOS", "token": "<device token>"},
)

Listing registered devices

get_push_devices returns the devices registered in the project, each with the user it belongs to. Narrow it with userId, deviceKey (the provider token) or platform (ios, android, chrome, safari, expo); a word outside that list is refused rather than answered with an empty page.

devices = client.hub.notifications.get_push_devices(platform="ios")

Devices are stored inside their user, so a page is a page of users and carries every matching device those users hold. Follow hasMore rather than stopping at the first short page.

get_push_device takes one device id and answers with the device and its owner:

device = client.hub.notifications.get_push_device("pnd_123")