Create or update member push notification token and app bundle ID
PUT /api/members/{memberID}/push-notification-token
Success: 201 Created
- Products: Operator (
FOH), Consumer (CONSUMER) (any one of these products, not all) - Features: Online Bookings (
ONLINEBOOK), Online Joining (ONLINEJOIN), Front of House Generic Access (FOHGENERIC) (any one of these features, not all)
Overview
Records the push notification token of a member's device so the platform can send notifications to it. Call it after your app obtains or refreshes a device token, and after the member signs in.
This is an upsert, and the key is the pair member plus app bundle id — not the token. If the member already has a registration whose appBundleId matches the one you send (case-insensitively, with blank treated as null), its token is overwritten; otherwise a new registration is created. So calling again with the same appBundleId replaces the token for that app, whereas calling with a different appBundleId — including omitting it when you sent one before — adds a second registration and leaves the first in place. That is how one member can be reachable on several apps at once.
Two clean-up rules run on every call. A push token belongs to one member: any registration on any other member carrying the same pushToken is deleted, so registering a token that a previous user of the device left behind moves the device to the calling member and silently stops notifications reaching the old one. And within the calling member, any registration carrying the same token under a different bundle is deleted, keeping one token to one bundle per member.
The status code tells you what happened. A created registration returns 201 Created with its id; an updated registration, or a call whose token and bundle already match what is stored, returns 204 No Content with no body. Handle both — the endpoint is safe to repeat, and repeating it does not create duplicates for the same bundle.
Unlike most member endpoints this one does not accept linked members. The memberID in the path must be the member in your access token; a parent's token cannot register a token against a child's record, and the attempt is rejected with 403.
Endpoint
PUT {base_url}/api/members/{memberID}/push-notification-token
{base_url} is the environment URL issued to your integration. See Authenticating with Gladstone APIs.
Path parameters
| Name | Type | Required | Description |
|---|---|---|---|
memberID | integer (int32) | Yes | The member the device belongs to. Must be the member in your access token — linked members are not accepted here and are rejected with 403 — and must match the memberID in the body. |
Request body
| Field | Type | Required | Description |
|---|---|---|---|
memberID | integer (int32) | Yes | Must repeat the memberID from the path. The two are compared and the call is rejected with 400 if they differ; the path value is then used. Required: omitting it fails validation with MemberID must be specified. |
pushToken | string | Yes | The device registration token your app received from the push provider — the address notifications are sent to. Required: omitting it fails validation with PushToken must be specified. Maximum 255 characters. It is the value being written, not what identifies the registration, so sending a refreshed token for a bundle already registered updates that registration rather than adding one. Tokens are treated as belonging to a single member: any registration of this token against another member is deleted as part of the call. |
appBundleId | string | No | Identifies which mobile app the token came from — the app's bundle identifier as registered in the platform's multi-app configuration, where it is paired with the push provider credentials used to send. Together with the member it identifies the registration, so send the same value each time you refresh that app's token. Saved lower-cased, compared case-insensitively, and treated as absent when blank or whitespace. Which way to go is decided by the operator's configuration, not by you: when the platform is configured for multiple mobile apps, only registrations that carry a bundle id matching a registered app are used at send time, and when it is not, only registrations with no bundle id are used — get this wrong and the token is stored successfully but never receives anything. |
Sample request
curl -X PUT '{base_url}/api/members/{memberID}/push-notification-token' \
-H 'Authorization: Bearer {accessToken}' \
-H 'X-Use-SSO: true' \
-H 'Content-Type: application/json' \
-d '{
"memberID": 12345,
"pushToken": "string",
"appBundleId": "string"
}'Response fields
| Field | Type | Description |
|---|---|---|
id | integer (int32) | The identifier of the newly created token registration. Returned only with 201 Created. When the call updated an existing registration for this member and bundle, or found the token already stored unchanged, the response is 204 No Content with no body and no id. |
Sample response
{
"id": 12345
}Errors
| Status | Meaning | When |
|---|---|---|
400 | Bad request | The memberID in the body differs from the one in the path: The memberIDs do not match. Also returned when the body fails validation — MemberID must be specified. or PushToken must be specified. |
404 | Not found | No member exists with that id: The member does not exist. Checked before anything is written. |
500 | Internal server error | An unexpected server-side failure while reading or saving the member's tokens. The response has no body. |