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

VariableDescription
{{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

AttributeDescriptionRelevance
accountIdID of the account that will receive the transaction.Mandatory
memberRoleIndicates 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
optinsarray with pairs of flag: boolean, type: string with set optins (type) and there value (flag).Optional
partnerIdDeclares 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

VariableDescription
{{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

AttributeDescription
accountIdTechnical account-Id connected to this membership.
memberRoleRole 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.
membershipIdTechnical ID of the membership.
optinsList of optins that this membership has. Optin names are denoted by type, optin values are denoted by flag.
partnerIdTechnical ID of the partner, the membership is belonging to.
userIdTechnical 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

VariableDescription
{{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

AttributeDescription
membershipIdTechnical ID of the membership.
accountIdTechnical account-Id connected to this membership.
userIdTechnical ID of the user connected to an account via the membership.
memberRoleRole 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.
partnerIdTechnical ID of the partner, the membership is belonging to.
optinsList 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

VariableDescription
{{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.