CRM and CX Blogs by SAP
Stay up-to-date on the latest developments and product news about intelligent customer experience and CRM technologies through blog posts from SAP experts.
Showing results for 
Search instead for 
Did you mean: 
Active Participant


Welcome to the blog posts of the SAP CX Services Marketing Practice.

We are happy to share with you our experience around Marketing Business, Technology and Analytics.

You want to see more blogs from us? Click here.


Wearable tech, such as the Fitbit activity tracker, can help us to live a more healthy lifestyle or can just be fun to play around with.
We have used activity trackers for various use cases, such as triggering a campaign when a specific target group runs a specified minimum amount of miles within a defined timeframe. With the information provided by most activity tracker, we can run better, more personalized campaigns for specific target groups.

ALso, this was the most physically demanding blog post we've did so far.

Leverage Fitbit data to run SAP Hybris Marketing Cloud Campaigns

  • Part 1: Connecting Fitbit with Hybris Marketing

  • Part 2: Running campaigns with Fitbit data (Blog Post will follow soon, title tbd)

In this Blog Post,
we will walk through the technical setup on how to integrate Fitbit activity and profile information with SAP Hybris Marketing Cloud.

With this blog post, we have used Fitbit Activity Trackers to generate activities.

The general approach and setup is described.

  • SAP Hybris Marketing Cloud (MKC)

    • Basic Communication Setup only

  • SAP Cloud Platform Integration (CPI)

  • SAP Cloud Platform API Management (APIM)

  • Fitbit

Technical Configuration Overview

The following picture illustrates the scenarios covered with this blog post.
This becomes more clear in the description for each scenario, followed in the blog post.

Fitbit Configuration

Create a Fitbit App

First, you need to create a Fitbit account.

Go to and create a new account.

Next, register a new App. You'll need to enter a callback URL. Since we have not configured anything yet, just enter a dummy URL first. You can change this later or already enter the APIM proxy url your planning to use.
In our example, we've used OAuth 2.0 Application Type = Server and Default Access Type = Read-Write.

When you have configured an API on API Management, change the callback URL of your app on
To do that on the Fitbit Dev Website, go to Manage my Apps and edit you application setting.
We have also configured a subscriber to the Fitbit App to receive notification from Fitbit on user activities.

API Management

Manage new subscribers with SAP Cloud Platform API Management

When a user registers with our App, the user will be redirected to the Fitbit Authorization Page. With our Fitbit App, we have configured a callback URL to redirect the request when the user allows access to the user's data.

To manage Authorization with Fitbit, we have created an API with SAP Cloud Platform API Management to manage access quotas, access restrictions, as well as message transformation for further processing.

First, you need a SAP Cloud Platform API Management account.

You can use the trial version for testing the capabilities and setting up your first scenarios.

How to get the trial version is described in this Blog Post:

Once your account is set up follow the documentation on SAP Help to set up API Management and assign users.

API Portal Home Screen

Create an API to pass through the message to the endpoint you have configured on SAP Cloud Platform Integration (you can create a very basic Iflow first only to receive the message for testing).

An API Proxy URL is created for the sending system, to send messages to. This URL must be added as the Callback URL in the Fitbit App.

Once the API Management service is set up, open the API Portal and start creating your API.

Create a New API what refers to the endpoint of you Iflow on SAP Cloud Platform Integration. If you have not created an Iflow yet, just create a basic Iflow or enter anything. This can be changed later.

Go to the resources tab and add a new resource. Define a title and path prefix for the new resource and select GET and POST as methods.

Once you have created the API and defined at least one resource, we are going to define a couple policies.

For this Blog Post we just describe the basic setup, mandatory to configure this API policy.

Assign Message - define basic authentication

Since the Fitbit App pushed messages without an Authorization Header (or certificate), what is needed for the Cloud Platform Integration Iflow, we need to make sure to authenticate against CPI.
To achieve this, we have defined the Authorization header on API Management. This is not the recommended approach, but was the quickest for a demo use case. API Management provides several Security Policies to enable a secure connection.
For productive systems it is recommended to use certificate-based authentication.

Here we have restricted access through Access Control and Quota.
Restricting access to specific IP-Addresses or IP-range must be used carefully. Service provides, such as Fitbit, scale dynamically depending on demand. This might result that notification are send from different servers with different IP addresses.

To set a header with the Assign Message Policy, you can do this as follows.
<AssignMessage async="false" continueOnError="false" enabled="true" xmlns=''>
<Header name="Authorization">Basic XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</Header>
<AssignTo createNew="false" transport="http" type="request"/>

Service Callout - get Fitbit Token

Define a Service Callout policy to call the Fitbit API.
From the message we receive from the Fitbit authorization page, we need to extract the authorization code and define this among other parameter as query parameter for the following Service Callout.

Define a variable to save the response.
<ServiceCallout async="true" continueOnError="false" enabled="true" xmlns="">
<Header name="Authorization">Basic clientid:clientsecret Base64 encoded</Header>
<Header name="Content-Type">application/x-www-form-urlencoded</Header>
<QueryParam name="client_id">123ABC</QueryParam>
<QueryParam name="redirect_uri">API Proxy URL</QueryParam>
<QueryParam name="code">{request.queryparam.code}</QueryParam>
<QueryParam name="grant_type">authorization_code</QueryParam>

Extract Variables - extract values from JSON response

From the Fitbit API response, we extract the values from the content and assign them to variables on API Management
<ExtractVariables async="true" continueOnError="false" enabled="true" xmlns=''>
<Variable name="sapapim.fitbitlogin.token" type="string">
<Variable name="sapapim.fitbitlogin.expires_in" type="string">
<Variable name="sapapim.fitbitlogin.refresh_token" type="string">
<Variable name="sapapim.fitbitlogin.scope" type="string">
<Variable name="sapapim.fitbitlogin.token_type" type="string">
<Variable name="sapapim.fitbitlogin.user_id" type="string">

Assign Message - set values for the message send to SAP Cloud Platform Integration

Now, we define a message payload to be send to Cloud Integration.
<!-- This policy can be used to create or modify the standard HTTP request and response messages -->
<AssignMessage async="false" continueOnError="false" enabled="true" xmlns=''>
<!-- Sets a new value to the existing parameter -->
<Payload contentType="text/xml">
<AssignTo createNew="false" transport="http" type="request"></AssignTo>

This completes the basic setup with API Management. Of course, you can extend and refine this as needed when setting up your own scenario.

Test you Fitbit Authorization process

To test this, you have created a Fitbit App, an API on API Management, and a basic Iflow to receive messages.

On you'll find all resources to test your authorization process.
Open your application and go to the Oauth 2.0 tutorial page.

Follow the instructions and trigger the authorization process with opening the generated authorization URL.

The authorization URL triggers the same action as when a user submits the Fitbis Authorization page.
When a user registers with us, he/she will be redirected to the Fitbit Authorization page.
For the demo, minimum requiremnt is to select profile and activity and exercises.

For debugging on API Management, open the created API and open the Debug screen.

Start debugging and hit refresh when you have triggered the authorization process from the Fitbit App.
When triggered in debug mode, API Management gives you details on the process followed with the defined policy. Here you can identify errors and do analysis on what went wrong.
In our case the API call was successful and a message send out to Cloud Integration.

Next, logon to SAP Cloud Platform Integration and open the Monitor tab.
You should see one processed message in the Message monitoring.
Review the processes message.
Since we haven't defined any processing steps, receiving the message here completes our first test.
With this, you have successfully created an API on API Management to receive messages from Fitbit, generate an access and refresh token, and forward this to Cloud Platform Integration.

You should have received a message with the following structure.
<?xml version='1.0' encoding='UTF-8'?>
<scope>weight settings activity nutrition heartrate location social profile sleep</scope>

The Fitbit token we retrieve is specific to the Fitbit user.

Manage subscriber notification from Fitbit with SAP Cloud Platform API Management

To receive notification from user interactions with Fitbit, we have added a new subscriber to our Fitbit App. When adding a new subscriber to your Fitbit App, you need to verify the subscriber URL before it can be used.

Fitbit verifies the subscriber by sending two request to the specified endpoint, expecting specified responses. This needs to be configured with API Management.

  1. Add a new subscriber to your Fitbit App

  2. Verify the new subscriber
    To do so, you need to configure the API you have created on API Management to respond to the Fitbit request as defined in the Fitbit Subscription documentation.

  3. Delete Subscriber when needed

Fitbit Subscription Documentation:

Create a new API and add the API Proxy URL as the subscriber URL in your Fitbit App. Add a new resource and enable GET and POST method for the added resource. Make sure to add the full path, including the resource path, as the subscriber URL in your Fitbit App.

Once created, open the policies and configure Basic Authentication against the CPI endpoint like in the API we have created before. You can add access restrictions, Quotas and other policies to protect your endpoint. For this demo scenario, we have only added the  mandatory to get this scenario working.

Add an Extract variables policy and extract the value from the query parameter verify. The value from the query parameter is saved in a variable. Configure a Condition String to ensure that the policy is only processed when the HTTP method is GET.

Open the process flow for the subscriber resource and define two raise fault policies.

For both you need to configure a condition string to ensure the policies are only executed when mandatory.

Respond with 204 No Content when the verification code is correct.

queryinfo.verificationcode = "verification code from Fitbit App"

Respond with 404 Not Found when the verification code is incorrect.

queryinfo.verificationcode != "verification code from Fitbit App"

With this setup, the verification of the subscriber should be successful and notification can received from Fitbit.

With notification from the Fitbit Subscription API, we just forward any POST request to Cloud Platform Integration and do further processing and transformation there.

SAP Cloud Platform Integration Configuration

With the message payload send from API Management we have all the information to identify the Fitbit User who allowed access to his/her Fitbit data.

We have set up and published the APIs to receive messages from Fitbit and protect the API endpoints from unauthorized access.
Next, we'll configure the Iflows on CPI to mediate the message to the Hybris Marketing Cloud.

Scenario Overview:

Create a basic Iflow on Cloud Platform Integration

We start with a simple, basic Iflow to test the authorization process.
For testing, you can create an Iflow just to make sure to receive the message and extend the same Iflow later.
When we have tested this successfully we can extend this Iflow to process and enrich the message send from API Management.

Configure an HTTP Endpoint to be used as the Target URL in your API Management API. We have also added a small script to read the inbound payload, only to review the inbound payload if all data is received.

Example payload:
<?xml version='1.0' encoding='UTF-8'?>
<access_token> Fitbit Access Token</access_token>
<refresh_token>Fitbit refresh token</refresh_token>
<scope>weight settings activity nutrition heartrate location social profile sleep</scope>

Once you get this running,  we can start transforming and enriching the message.

Extend the basic Iflow on Cloud Platform Integration to import a contact to Marketing Cloud

When the authorization tests were successful, we start extending the basic Iflow.

Our goal for this Iflow is to create a contact in SAP Hybris Marketing Cloud. The contact we create here is used in the following scenarios (collect daily activities, and subscription notifications) to assign the interactions (Fitbit activities) to this contact.

  • This scenario is triggered from you Website or app, where you have placed the redirect link to the Fitbit Authorization page. On the Fitbit Authorization Page, the user grants our Fitbit App to access his/hers user information. For our scenario minimum requirement is to allow the activity and profile scope.

  • The Fitbit Authorization Page redirects to the redirect URL (API Management proxy URL).

  • The API we have created on SAP Cloud Platform API Management receives the message from the Fitbit Authorization Page and generates a Fitbit Access and Refresh Token.

  • This information is persisted with the Fitbit User ID in the Cloud Platform Integration Data Store.
    On CPI we retrieve the user profile data from Fitbit and create an new consumer contact on Marketing Cloud.

Iflow configuration:


1) Configure a HTTP Endpoint and verify if the mandatory scope items are selected.

Mandatory scope to be selected are: profile and activity
You can build a routing condition to only process subscriptions with the minimal scope.
Routing Condition: /root/scope[text()[contains(.,'activity')]] and /root/scope[text()[contains(.,'profile')]]

2) Prepare Fitbit API request and persist payload

Persist the inbound message, containing the current access and refresh token from Fitbit in the CPI Data Store.

For this demo use case, we have used the CPI Data Store to persist active user information who authorized us extract Fitbit user data.

The information is saved as an XML file with the Fitbit user ID as the Data Store entry ID. Expression: ${xpath.//user_id}

The information needed for the following calls are saved in Exchange Properties, to be available in the Message Exchange.

3) Request data from the Fitbit API

With the information available, we can request the Fitbit profile data for that specific user.

GET /1/user/-/profile.json HTTP/1.1
Authorization: Bearer <access token>
Content-Type: application/x-www-form-urlencoded

The result from the response can be used for creating a contact in MKC.

4) Map Fitbit API response to Hybris Marketing target message

To use the Fitbit response message for the message mapping, the JSON payload needs to be converted to an XML formatted payload.
A simple way to do that is to use the JSON to XML converter available on CPI. Just make sure the has a root entity before converting the payload to XML.
In the message mapping, map the Fitbit response against the message structure expected from Hybris Marketing.

5) Import data to Hybris Marketing

With the message payload available in the correct format, you can import the contact to Hybris Marketing using the Master Data Import OData service.

6) With the contact imported to Marketing Cloud successfully, we can now subscribe to notifications from Fitbit and import interaction to Marketing Cloud.

Therefore, we first replace the message body with the one we have originally received. Next, we need to assess the availability of each scope item and assign them to the Fitbit collection types. When enabled on the Fitbit Authorization Page, we add a validity parameter to indicate if the user allowed us to call information for a specific collectionType.

	<?xml version="1.0" encoding="UTF-8"?>

7) Route the message depending on the selected scope

Depending to the selection done on the Fitbit Authorization Page the router directs the message to one of the branches.
Here, we have just differentiated between subscribe to all or activities only.

8) Subscribe (or unsubscribe) to all Fitbit notifications.

When all collection types are enabled, we can subscribe to all notifications Fitbit provides.
Set a router condition to verify if either all collection types are true and another one to check of all collection types are false  (for unsubscribe).

9) Subscribe or unsubscribe to activity Fitbit notifications.

Depending on the validity for the activities collection type, we need to subscribe or unsubscribe to the Fitbit notifications.
Subscribe: HTTP POST
Unsubscribe: HTTP DELETE${property.collectionType}/apiSubscriptions/${property.subscriptionI...

We have built subscription/unsubscribe only for the activities collection type. This must be also done when subscribing/unsubscribing to all collection types.
Logic is same as for activities.

Create an Iflow to collect daily activities

When you need to collect data from Fitbit which are not covered with the notifications through the subscription API, to can run ad-hoc or scheduled jobs to collect data from the Fitbit Web API. Routine jobs can be triggered on CPI using the Timer Event. From CPI, the Fitbit Web API is called, requesting data such as profile data or activities. The response received from the Fitbit Web API is transformed and imported to Marketing Cloud.


This approach is not recommended for load of mass data from Fitbit. Fitbit restricts access to the API by the number of calls to the Web API, you're allowed to do within one hour.
This example is to prove technical feasibility but is not meant to be implemented for retrieving larger amounts of data from the Fitbit Web API within a short timeframe.

Iflow configuration:

1) Define a Timer Event and set the date for what you like to retrieve the data

We have defined a Timer Event to schedule when this scenario should run.
As the second step we have added a simple script to determine yesterday's date.

import java.text.SimpleDateFormat

def Message processData(Message message){
def date = new Date()
today = new SimpleDateFormat("yyyy-MM-dd").format(date)
def yesterday = today.previous()
return message

2) Get Users stored in the CPI Data Store

To get the Users stored in the CPI Data Store, add a Select Data Store Operation and call all entries available in the Data Store.

When pulling the data from the CPI Data Store an envelope is added to separate the individual entries.


Split the message on the //message and add a filter to eliminate the left <message> element with text().

This will leave you with the message you have originally stored in the Data Store.

3) Refresh the Fitbit Access Token

Since we run this scenario occasionally, we have configured to get a new token every time we run this Iflow.
You'll need the refresh token to get a new access token, this is saved with the user ID in the CPI Data Store.

POST /oauth2/token?grant_type=refresh_token&amp;refresh_token=<refresh token>
Authorization: Basic <Base64 encoded AppID:AppSecret>
Content-Type: application/x-www-form-urlencoded

Fitbit Responds with a new access and refresh token. Convert this message to xml and overwrite the existing entry with the old access and refresh token.
Before leaving the local integration process, set the request parameter for the GET activities Fitbit Web API request.

Keep in mind, that the access token are user specific, this needs to be done for each user individually.

4) Retrieve user-specific data from the Fitbit API

With all the information available, you can finally retrieve the data from the Fitbit Web API.
Prepare the request and send the request to the Fitbit Web API.

GET /1/user/-/activities.json
Authorization: Bearer <access token>
Content-Type: application/x-www-form-urlencoded

Convert the message to XML and create an XML Schema file to be used in the Mapping.
Map the Fitbit Web API response to the target structure expected by SAP Hybris Marketing Cloud.
Here we have requested activity data which is mapped to an interaction on Marketing Cloud.
With this example, we have only mapped the number of steps from the last day.


5) Import the retrieved data to SAP Hybris Marketing Cloud

With the message mapping done, the new message can be imported to SAP Hybris Marketing Cloud with the Master Data OData Service.

Create an Iflow to process Fitbit notifications

When you have enabled  subscription notification with Fitbit, Fitbit will send notification on data changes or new data to the configured subscriber.

When there is a change of data, such as a new activity has been recorded, Fitbit sends a notification with all data change to the configured subscriber.

The subscriber verifies the message and forwards the message to our CPI Iflow. There, we collect the actual datasets and transform the data to fit the target message structure expected by Marketing Cloud. With this demo case, we are collecting new activities for specific users.

1) Add a subscriber to your Fitbit Application

Add a Subscriber to your Fitbit app
When using subscriptions with Fitbit, you have to configure a subscriber with you Fitbit App.
With subscriptions you receive near real-time updates from Fitbit.

Verify subscriber

When adding a new subscriber to your Fitbit App, Fitbit requires to verfify the added subscriber endpoint.
To verify a subscriber, Fitbit will send two HTTP GET requests to your endpoint and expects the subscriber to respond accordingly.
Both requests contain the verification code as query parameter.

Respond with HTTP 204 No Content

Respond with 404 Not Found

2) Create an API on API Management to verify the subscriber

See 'Manage subscriber notification from Fitbit with SAP Cloud Platform API Management'

3) Configure an Iflow of SAP Cloud Platform Integration to process the notification and collect data from Fitbit

4) Configure Inbound Communication on SAP Hybris Marketing Cloud

Iflow configuration:


1) Receive Fitbit notification

With the Fitbit notification received through API Management, we convert the notification to XML for further processing.

2) Persist parameters from the notification

Once the notification is available in XML format, we can extract the ownerId, date, and collectionType and save them to properties, using a Content Modifier.

With the owner ID, we get the entry from the CPI Data Store what contains the access token. Save the access token in a new property.

Get access token

3) Call Fitbit API to retrieve data

With the information from the notification and the access token, we define a request message to be send to Fitbit to retrieve the data.

GET /1/user/<owner or user ID>/activities/date/<date>.json HTTP/1.1
Authorization: Bearer <access token>

Convert the JSON response to XML.

4) Message Mapping and import data to SAP Hybris Marketing Cloud

With the Fitbit response available in XML format, create a XML Schema file and use this as the source structure for the message mapping.
Create a XML Schema file for the message target structure from SAP Hybris Marketing Cloud.
Map the source message against the target message to be imported to Marketing Cloud.

When everything went well, the interaction is imported to Marketing Cloud. The interaction is assigned to the contact created with the authorization Iflow. To see all interactions, open the contact and navigate to the Interactions tab.

We didn't create a new communication medium for Fitbit Interactions and imported the interactions as website visits since Hybris Marketing Cloud configuration was not focus of this blog post.

5) Manage exception for non-delivered messages

In case the message can't be delivered to the Marketing Cloud system due to an expired access token, we need to capture this exception and resend the message with a new valid access token. We'll catch the exception message, refresh the access token and re-send the message.

6) Refresh access token

Since we catch all exception messages, we need to set a routing condition to only process the messages that have failed due to invalid/expired access tokens against the Fitbit API.
In our scenario we route all messages with a HTTP 401 status code and where the error did not occur when sending the message to Marketing Cloud.

Example: ${header.CamelHttpResponseCode} = '401' and ${header.CamelFailureEndpoint} != '/CUAN_IMPORT_SRV:ImportHeaders'

With the routing condition to be true, we retrieve the current refresh token from the data store and request a new access token from Fitbit.

7) Overwrite old access and refresh token and set new properties

With the response from Fitbit we get a new access token as well as a new refresh token.
This is saves in the same format as before in the CPI data Store and used for further calls to the Fitbit API.

Legal Compliance with Fitbit data

Whenever using personalized data you need to make sure that you stay compliant with your company. From technical perspective you can do lots of thing, but are you allowed to use that data legally? Before planning campaigns that use sensitive data, like we do here, read through the service provider terms and conditions. Make sure that the data you retrieve is allowed to be used where run the campaigns, and plan your systems so they are protected from unauthorized access.

It makes a difference if you retrieve data such as number of clicks or healthcare related data.

Wearable tech is still a relatively new area of technology and the rules and regulations are not the precise and mature than in other areas.

I can't and won't give any legal advice, but if you're planning a scenario where you use sensible data, always check in advance in the legal constraints of using the data from that service provider in your country.

Fitbit permission (scope)

  • activity                 The activity scope includes activity data and exercise log related features, such as steps, distance, calories burned, and active minutes

  • heartrate         The heartrate scope includes the continuous heart rate data and related analysis

  • location         The location scope includes the GPS and other location data

  • nutrition         The nutrition scope includes calorie consumption and nutrition related features, such as food/water logging, goals, and plans

  • profile                 The profile scope is the basic user information

  • settings         The settings scope includes user account and device settings, such as alarms

  • sleep                 The sleep scope includes sleep logs and related sleep analysis

  • social                 The social scope includes friend-related features, such as friend list, invitations, and leaderboard

  • weight                 The weight scope includes weight and related information, such as body mass index, body fat percentage, and goals

Fitbit documentation:

Fitbit subscription collection types

  • activities collection requires activity scope

  • body collection requires weight scope

  • foods collection requires nutrition

  • sleep collection requires sleep

  • If no collection specified, activity, nutrition, profile, settings, sleep, weight scope required.

Fitbit documentation:


This demo scenario should give you a basic understanding on how to use different services running on SAP Cloud Platform to process different types of requests and responses from 3rd party applications.  Major objective for this blog post was to create a contact from the Fitbit User and assign interactions to the created user.

It is recommended to outsource device management to a service, such as SAP Cloud Platform Internet  of Things, to manage connectivity and device management (
With this demo scenario we have imported near real-time contacts and interactions to SAP Hybris Marketing Cloud using SAP Cloud Platform Connectivity Services (SAP Cloud Platform API Management and SAP Cloud Platform Integration) for a limited number of active users.

Now, what it this good for?
Well, you are trying to create meaningful campaigns, right? With more data, you can better insight and better understand your customers.
This data could be used to run some analytics or rules to determine if a specific campaign should be triggered for the consumer. You could create a new engagement score that reflects the consumers activity level.
If you're a shoe company you obviously could use this data to run some fancy analytics in Marketing Cloud, understand running behaviors, preferred workout times and trigger a campaign when your customer has run 1.000.000 miles and determine the best sending time to be after he/she usually finished his/hers workout.


You want to see more articles from SAP Services? Click on the banner below.

Your SAP CX Services – Marketing Practice team.