Behaviors

Like any sales API, we have a catalog made up of products and a cart made up of items. On top of these classic notions are behaviors. They are responsible for the fitness business logic and the effects triggered by the purchase of various products (adding a membership, crediting sessions, etc.).

Among these behaviors, some require input from the buyer (e.g., purchasing a membership requires a start date), while others do not require any input (e.g., purchasing a water bottle or towel requires no additional information).

List of behaviors

Each product can have one or more of the following behaviors:

• /{clientToken}/behaviors/subscription : Adds a membership to the contact
• /{clientToken}/behaviors/subscription_option : Adds a membership option to the contact
• /{clientToken}/behaviors/badge : Automatically assigns a badge to the contact
• /{clientToken}/behaviors/counter_line : Automatically adds a session booklet
• /{clientToken}/behaviors/package : Automatically adds a set of products to the cart
• /{clientToken}/behaviors/contact_tag : Automatically adds a tag to the contact
• /{clientToken}/behaviors/countermark : Automatically adds a countermark campaign with a single code

These behaviors, except for the package one, are triggered as soon as a sale is completed—but they may require additional data to do so.

Retrieving product behaviors

No additional call is necessary. The catalog call already includes the list of products and the behaviors associated with each product. See the section Retrieve contact catalog

Catalog call response

{  
   "@context":"\/clientToken\/contexts\/Product",
   "@id":"\/clientToken\/products",
   "@type":"hydra:Collection",
   "hydra:member":[  
      {  
         "@id":"\/clientToken\/products\/2278",
         "@type":"http:\/\/schema.org\/Product",
         "description":"",
         "name":"My product",
         // ...
         "productBehaviors":[   // <-- List of product behaviors
            {  
               "@id":"\/clientToken\/product_behaviors\/2387",
               "@type":"ProductBehavior",
               // Behavior type
               "behavior":"\/clientToken\/behaviors\/subscription_option",
               // ...
            }
         ],
         // ...
      }
   ]
}

Product without behavior

These are typically shop items. No behavior means no additional input is required—this is the simplest cart addition scenario.

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/1"
}'

Membership

/{clientToken}/behaviors/subscription

The membership only requires a start date.

paramètre	description	exemple
implementation[startdate]	Start date of the membership	2019-01-01

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/1",
    "implementation": {
        "startDate": "2019-01-01"
    }
}'

For a direct debit membership, additional parameters can be passed:

paramètre	description	exemple
repaymentSchedule[debitDay]	Debit day	1
repaymentSchedule[specificDay]	Specific debit day	true
repaymentSchedule[startDate]	First debit date	2019-02-01

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/1",
    "implementation": {
        "startDate": "2019-01-01"
    },
    "repaymentSchedule": {
        "debitDay": 1,
        "specificDay": true,
        "startDate": "2019-02-01"
    }
}'

To retrieve the available configured debit days:

curl --location --globoff '/{clientToken}/allowed_debit_days?startDate=2019-01-01&isProrated=true&isWeeklyDebit=false'

parameter	description	example
startDate	Membership start date	2019-01-01
isProrated	Prorated membership	true
isWeeklyDebit	Weekly direct debit	false

This route returns the list of debit days (debitDay) and the corresponding debit date (date). These values should be passed to repaymentSchedule.debitDay and repaymentSchedule.startDate in the article creation.

Membership option

/{clientToken}/behaviors/subscription_option

The membership option is similar to the membership, except that it is linked to a membership, either being purchased at the same time or already existing.

parameter	description	example
parent	Parent article ID when purchasing membership and option together	/{clientToken}/articles/1234
implementation[startdate]	Start date of the membership option	2019-01-01
implementation[subscriptionId]	ID of the linked existing membership	/{clientToken}/subscriptions/1432
implementation[subscriptionArticleId]	Linked membership article ID for simultaneous purchase (same as parent)	/{clientToken}/articles/1234

INFO

when purchasing a membership with an option, the membership must be added to the cart before the option.

For a direct debit option, additional parameters can be passed:

|| parameter | description | example | | -------------------------------- | ------------------ | ------------ | | repaymentSchedule[debitDay] | Debit day | 1 | | repaymentSchedule[specificDay] | Specific debit day | true | | repaymentSchedule[startDate] | First debit date | 2019-02-01 |

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "repaymentSchedule": {
        "debitDay": 1,
        "specificDay": true,
        "startDate": "2019-02-01"
    }
}'

To retrieve available configured debit days:

curl --location --globoff '/{clientToken}/allowed_debit_days?startDate=2019-01-01&isProrated=true&isWeeklyDebit=false'

parameter	description	example
startDate	Membership start date	2019-01-01
isProrated	Prorated membership	true
isWeeklyDebit	Weekly direct debit	false

This route returns the list of debit days (debitDay) and the corresponding date (date). These values should be passed to repaymentSchedule.debitDay and repaymentSchedule.startDate during article creation.

Example: simultaneous purchase of membership and option

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/2",
    "parent": "/{clientToken}/articles/1",                    
    "implementation": {
        "startDate": "2019-01-01",
        "subscriptionArticleId": "/{clientToken}/articles/1"  
    }
}'

Example: purchase of an option on existing membership

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/2",
    "implementation": {
        "startDate": "2019-01-01",
        "subscriptionId": "/{clientToken}/subscriptions/1"
    }
}'

Badge

/{clientToken}/behaviors/badge

The badge behavior assigns a badge to a contact at the time of sale. It therefore requires the badge number.

parameter	description	example
implementation[number]	Unique badge number	ABC123GEF

Exemple

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/3",
    "implementation": {
        "number": "ABC123GEF"
    }
}'

Session booklet

/{clientToken}/behaviors/counter_line

Just like memberships and options, it requires a start date of validity.

parameter	description	example
implementation[startdate]	Validity start date of the booklet	2019-01-01

Example request

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/5",
    "implementation": {
        "startDate": "2019-01-01"
    }
}'

Countermark

/{clientToken}/behaviors/countermark

Although it has a behavior, no additional input is required at the time of sale. It behaves like a product with no behavior.

Example request

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/5"
}'

Packages

/{clientToken}/behaviors/package

Packages are products composed of other products. For example, a package might include a membership and its options bundled together under a single product with appropriate offers. Therefore, the required input for the sale of the package depends on what it contains. When retrieving the behaviors for the product, it is likely to list multiple behaviors.

If it contains a membership and an option, it will require implementation for both.

parameter	description	example
implementations	Object containing input for each behavior, indexed by behavior ID

Example: package with membership, option, and badge:

curl --location --globoff '/{clientToken}/sales/1/articles' \
--header 'Content-Type: application/json' \
--data '{
    "offerId": "/{clientToken}/offers/7",
    "implementations": {
        "/{clientToken}/product_behaviors/1": { 
            "startDate": "2019-01-01"
        },
        "/{clientToken}/product_behaviors/2": { 
            "startDate": "2019-01-01"
        },
        "/{clientToken}/product_behaviors/3": { 
            "number": "ABC123DEF"
        }
    }
}'

NOTE

In this case, it is not necessary to specify the linked subscription or parent—these will be automatically determined.