Membership
A user, which is a customer profile with customer-specific data, is not able to collect loyalty points by itself, since the loyalty system collects points on accounts only. A membership can link a customer profile to an account, enabling the user to collect points for his connected accountId. One account may have N user connected with N memberships (always connect 1 user per membership). In practise, the most common situation is the connection 1 account : 1 membership : 1 user on which we will mainly focus in the following.
Note that the membership is the object which contains optin-information as optins are typically set / activated when a registration is completed (= user connected with account).
Creating Memberships
A new membership for given accountId can be created to connect a user with an account.
curl --location --request POST '{{api_url}}/accounts/{{accountId}}/memberships' \
--header 'Authorization: {{jwt_token}}' \
--header 'interaction-id: {{interactionId}}' \
--header 'Content-Type: application/json' \
--data-raw '{{body}}'
with variables
Variable | Description |
---|---|
{{api_url}} | Endpoint of the api. (Staging) (Production) |
{{accountId}} | ID of the account that will get the membership connection. |
{{jwt_token}} | The JWT-token, which has been generated by authentication. |
{{interactionId}} | Unique Identifier of the cash machine (or virtual equivalent, e.g. online-shop), which produced the receipt. This ID has to be listed in the Convercus System as with this ID, the connection to the call origin is made. |
{{body}} | Body with membership data parameters, specified in the following. |
The body may look like this:
{
"memberRole": "OWNER",
"optins": [
{
"flag": true,
"type": "Post"
},
{
"flag": true,
"type": "Newsletter"
}
],
"partnerId": "550e8400-e29b-11d4-a716-446655440000",
"userId": "d22917e4-e764-4f12-8969-b834673f3acd"
}
with
Attribute | Description | Relevance |
---|---|---|
accountId | ID of the account that will receive the transaction. | Mandatory |
memberRole | Indicates the relation the user has to the account. Must be one of: OWNER COOWNER COLLECTOR Note that the first membership has to have the OWNER-role. There can be only one OWNER per membership. If not explicitly required otherwise, only one user should be connected via one membership to one account. | Mandatory |
optins | array with pairs of flag: boolean, type: string with set optins (type) and there value (flag). | Optional |
partnerId | Declares the Id for the loyalty partner the membership should be linked to. This can be used to grant bonuses, like welcome-bonus or seasonal bonuses. | Optional / Mandatory for multipartner programs |
The response will be similar to previous Creation-Requests, where the crucial information can be obtained from the Location row of the response header array.
The composition is:
Location | {{api_url}} /accounts/{{accountId}} /memberships/{{membershipId}} |
---|
Where {{accountId}}
and {{membershipId}}
are the values of given account and account-membership, respectively.
Getting Memberships of an Account
All memberships (and optins) of given account can be retrieved with the account identification:
curl --location --request GET '{{api_url}}/accounts/{{accountId}}/memberships' \
--header 'Authorization: {{jwt_token}}' \
--header 'interaction-id: {{interactionId}}' \
--header 'id-type: {{idType}}' \
--header 'Content-Type: application/json' \
with variables
Variable | Description |
---|---|
{{api_url}} | Endpoint of the api. (Staging) (Production) |
{{accountId}} | ID of the account that should be checked.. The ID has to be given in the format, that is dictated by the{{idType}} , |
{{jwt_token}} | The JWT-token, which has been generated by authentication. |
{{interactionId}} | Unique Identifier of the cash machine (or virtual equivalent, e.g. online-shop), which produced the receipt. This ID has to be listed in the Convercus System as with this ID, the connection to the call origin is made. |
{{idType}} | Identifier-Type (corresponding to the {{accountId}} ). Available values: APPCODE (e.g. A1B2C3D4E5) CARDCODE (e.g. V1W2X3Y4Z5) EXTERNALCODE (e.g. 123456780123) ID (account-identifier, e.g. 7d123457-bfa1-4a83-8213-123456789763 ) |
Note again, that you can use the identifier code directly (e.g.
{{idType}}
=CARDCODE,{{accountId}}
=V1W2X3Y4Z5) at this point.
The returned object looks like this:
[
{
"accountId": "550e8400-e29b-11d4-a716-446655440000",
"memberRole": "OWNER",
"membershipId": "550e8400-e29b-11d4-a716-446655440000",
"optins": [
{
"flag": true,
"type": "email"
}
],
"partnerId": "550e8400-e29b-11d4-a716-446655440000",
"userId": "550e8400-e29b-11d4-a716-446655440000"
}
]
where
Attribute | Description |
---|---|
accountId | Technical account-Id connected to this membership. |
memberRole | Role of the membership. In general, it is possible to have multiple memberships, one account owner ("memberRole": "OWNER") and several COOWNERs or COLLECTORs. In the standard setup however, there is only one membership (with "memberRole": "OWNER"), connecting one account to one user. |
membershipId | Technical ID of the membership. |
optins | List of optins that this membership has. Optin names are denoted by type, optin values are denoted by flag. |
partnerId | Technical ID of the partner, the membership is belonging to. |
userId | Technical ID of the user connected to an account via the membership. |
If no membership is returned, the returned array is empty []. Depending on the specific program setup, these users may not be allowed to do anything if there are not registered. This logic has to be adopted here if that’s the case.
Getting a specific Membership of an Account
To investigate a specific membership of given accountId closer, all enlisted information can be obtained at once by using:
curl --location --request GET '{{api_url}}/accounts/{{accountId}}/memberships/{{membershipId}}' \
--header 'Authorization: {{jwt_token}}' \
--header 'interaction-id: {{interactionId}}' \
--header 'id-type: {{idType}}' \
--header 'Content-Type: application/json' \
with
Variable | Description |
---|---|
{{api_url}} | Endpoint of the api. (Staging) (Production) |
{{accountId}} | ID of the account that should be checked.. The ID has to be given in the format, that is dictated by the{{idType}} , |
{{membershipId}} | Unique ID of the membership. |
{{jwt_token}} | The JWT-token, which has been generated by authentication. |
{{interactionId}} | Unique Identifier of the cash machine (or virtual equivalent, e.g. online-shop), which produced the receipt. This ID has to be listed in the Convercus System as with this ID, the connection to the call origin is made. |
{{idType}} | Identifier-Type (corresponding to the {{accountId}} ). Available values: APPCODE (e.g. A1B2C3D4E5) CARDCODE (e.g. V1W2X3Y4Z5) EXTERNALCODE (e.g. 123456780123) ID (account-identifier, e.g. 7d123457-bfa1-4a83-8213-123456789763 ) |
The response object looks like this:
{
"membershipId": "4670c014-45b4-4d3b-bafd-b4bd13b5d659",
"accountId": "fd313081-11ae-4e50-b429-5c1cc0bfb357",
"userId": "24632823-71ca-47d3-8e20-6f9c7d727ef5",
"memberRole": "OWNER",
"partnerId": null,
"terminated": null,
"createdAt": null,
"optins": [
{
"flag": true,
"type": "email"
}
]
}
where
Attribute | Description |
---|---|
membershipId | Technical ID of the membership. |
accountId | Technical account-Id connected to this membership. |
userId | Technical ID of the user connected to an account via the membership. |
memberRole | Role of the membership. In general, it is possible to have multiple memberships, one account owner ("memberRole": "OWNER") and several COOWNERs or COLLECTORs. In the standard setup however, there is only one membership (with "memberRole": "OWNER"), connecting one account to one user. |
partnerId | Technical ID of the partner, the membership is belonging to. |
optins | List of optins that this membership has. Optin names are denoted by type, optin values are denoted by flag. |
Update Membership Optins
The optins for a specific membership of given accountId can be updated by reassining them in the following request:
curl --location --request PATCH '{{api_url}}/accounts/{{accountId}}/memberships/{{membershipId}}' \
--header 'Authorization: {{jwt_token}}' \
--header 'interaction-id: {{interactionId}}' \
--header 'id-type: {{idType}}' \
--header 'Content-Type: application/json' \
--data-raw '{{body}}'
with
Variable | Description |
---|---|
{{api_url}} | Endpoint of the api. (Staging) (Production) |
{{accountId}} | ID of the account that should be checked.. The ID has to be given in the format, that is dictated by the{{idType}} , |
{{membershipId}} | Unique ID of the membership. |
{{jwt_token}} | The JWT-token, which has been generated by authentication. |
{{interactionId}} | Unique Identifier of the cash machine (or virtual equivalent, e.g. online-shop), which produced the receipt. This ID has to be listed in the Convercus System as with this ID, the connection to the call origin is made. |
{{idType}} | Identifier-Type (corresponding to the {{accountId}} ). Available values: APPCODE (e.g. A1B2C3D4E5) CARDCODE (e.g. V1W2X3Y4Z5) EXTERNALCODE (e.g. 123456780123) ID (account-identifier, e.g. 7d123457-bfa1-4a83-8213-123456789763 ) |
{{body}} | Body with Identifier-Information as explained in the following. |
The body may look like this:
[
{
"flag": true,
"type": "email"
}
]
where each updated optin must be paired with a true-false-flag.
Note: body musst contain all optins, even if they remain unchanged. Any optin not specified in body will be deleted.
Updated 2 months ago