SAP Customer Data Cloud Positions

Site Setup

Skip to end of metadata
Go to start of metadata


The following guide walks you through setting up your site configurations in the SAP Customer Data Cloud Console.

Start setting up your site by signing in to the Console.



Note: Use separate site definitions for every environment required by the development process.  For example, if you use three environments: Development, Staging and Production, you will need separate site definitions for each environment (3 unique API keys).

Watch an Instructional Video

If you have an SAP logon, you can watch an instructional video about site setup here.

Add Your Site

This guide assumes you are creating a site on a single data center. If you wish to create a global site (that uses more than one data center), please read the Global Access guide.

After signing in to the Console, start creating your sites in the Dashboard.

  1. Select Create Site:
  2. Fill in the site domain, and select the Local Data Center residency. 
  3. Select the Data Center where your site's data will be stored (options are US, AU or EU) and optionally enter a description, then select OK.



  • A valid domain should be entered in the form of "" (there is no need to include the "http://" prefix). If you are using SAP Customer Data Cloud in Flash applications, please enter the URL of the location from where your SWF files are stored and downloaded.
  • The Data Center entry cannot be changed once the site has been created and indicates the location of the server holding your user data. Selecting the correct Data Center is not trivial and is dependent on your site's location. To verify a site's data center location, see Finding Your Data Center.

Unable to render {include} The included page could not be found.

Your domain name should now be listed in the Sites table:

Search for Sites

Use the search bar to quickly locate sites. The term you enter in the search bar will search for sites by site domain, ID, data center, description, API key and tags. 

Add Tags and Filter Sites 

Use tags to organize your sites, so a group of sites that share an attribute may be found easily using the search bar. You can add up to 10 tags to any site. To add a tag to a site, press the 'plus' symbol next to the corresponding site's API key, and start typing. 

Tags should be a single contiguous string up to 30 characters long. You can add a number of tags by using spaces as separators between tags.

You can filter the site list by entering tag names in the search bar.



API keys are unique site identifiers that are assigned automatically to a site upon its creation. Use the API key in every page of your site that uses SAP Customer Data Cloud functionalities. The key is in charge of identifying the calling site and assessing the permissions available for that site.
The API key that is associated with each domain is listed next to the domain name in the table. 


Note: Production environment API keys should not be used for testing. Use separate site definitions and API keys for test and production sites.


Data Center

  • The data center is the location or locations of the server holding your user data. 
  • Data centers cannot be changed once the site has been created. .

Partner ID

The partner ID is displayed under your partner name.

Secret Key

The "Secret Key" is available next to your partner name. This key may be used to generate and check Cryptographic Signatures to verify the authenticity of Gigya processes and prevent fraud. Read more about the subject in the Security page of our Developer's Guide.


Selecting Settings opens the Settings page. For more information, see below.


Selecting Reports opens the site's reports page. Read more in our Reports guide.

Note: If you have not yet obtained Social Network keys for your application, and are still using temporary SAP Customer Data Cloud keys, continue to the next "Site Settings" step.


Trusted Site URLs

If the SAP Customer Data Cloud service configuration applies to all parts of your site, you will not need to change the default configuration. However, if you wish to configure specific parts of your site to work under these settings, you can use the URL settings in the following cases:

  • Apply the configuration to specific subdomains only (i.e. "").
  • Apply the configuration to specific paths (i.e. **)
  • If your implementation includes social login on mobile devices, make sure that all the URLs that participate in the redirect social login flow are added to the list of Trusted Site URLs. For example: 

    • Android: 


      • gigya://gsapi/

    • iOS: 
      • Swift: gsapi://*
      • For Objective-C, enter both gsapi://* and the bundle ID of your project (e.g.,*). 




Domains with port numbers are not supported in "Trusted Site URLs". (e.g.,

Any time you add any entries to the Trusted site URLs you must have any SSL Certificates re-issued for your site, including for the apiDomainPrefix, if your site is using one. You can see if your site is using a customAPIDomainPrefix by checking the value of gigya.partnerSettings.customAPIDomainPrefix from one of your sites that has the SAP Customer Data Cloud Web SDK loaded.


Additional Share URLs

The Trusted Share URLs table is an additional list of URLs that are approved for sharing purposes as part of the domain's whitelist.
When a link is shared via Gigya's service, Gigya will validate the link by following the redirect chain and assuring that all URLs on the chain are trusted. Links that redirect through a non-trusted domain will be blocked.
A URL is trusted if it is whitelisted as one of the following:

  • TheTrusted Site URLs list
  • The Additional Share URLs list
  • Custom short URLs for the site
  • It is configured as a CNAME for the site
  • Listed in Gigya's global whitelist.

Additionally, all share URLs must also be:

  • An absolute URL.
  • Publicly accessible (i.e., not behind a firewall or on localhost) and must respond without errors to a HEAD request sent by Gigya.

When sharing or shortening URLs via any Gigya Add-ons, APIs, or methods, the URL being used must be a publicly accessible URI. If the URI is behind a firewall, an HTTP Auth, or does not respond within 5 seconds of a request to retrieve the URL of the page, even if the URL is within a whitelisted domain, Gigya will respond with errorCode 400120 - Invalid Site Domain, and the request will fail.

Configure Domain Alias (CNAME)

For general information about configuring providers, see Setting Up External Applications.

Some social networks require that callbacks go to a subdomain of your site and not directly to SAP Customer Data Cloud . We highly recommend specifying a subdomain in your site and defining a CNAME entry in your DNS server that maps that subdomain to an alias you can receive from SAP Customer Data Cloud support. CNAMEs provide the following benefits:
  • Featuring your site in the OpenID authentication flow. Users will be prompted to allow your site (instead of allowing to access the user’s OpenID data.
  • A better user experience on platforms such as iPhone, Android, Windows Mobile.



In order to use a custom CNAME and avoid browser warnings related to 3rd party cookies, Gigya can act as a client proxy for your site, thus eliminating browser security warnings. In order to do so, Gigya uses an SSL certificate issued to your subdomain to encrypt your user's information transmitted during social login.  A general overview of the process can be found in our 3rd Party Cookies documentation. The following is a more detailed explanation. Note that this process is relevant to sites in the CN and RU data centers; The US, EU and AU data centers support an automated process for issuing an SSL certificate. For more information regarding this process, contact your Customer Engagement Executive. 

If you are using the CN data center, you must first obtain a valid ICP License for your domain before requesting a CNAME Alias from Gigya/CDC.

Why an SSL Certificate?

There are a number of reasons:

  1. Using a CNAME (and certificate) instead of allows you to preserve the site branding and user experience that you've invested so much time and effort in.
  2. Because without one, every time your user is redirected from to Gigya's servers, their browser will warn them with a security message. Using an SSL certificate verifies that the redirect to Gigya's servers is a trusted process, thus eliminating this security popup for your site visitors experience.
  3. Using an SSL certificate also ensures that data transmitted to and from the browser is encrypted, reinforcing trust between you and your visitors and helping to prevent Man-in-the-middle attacks. 

A Few Notes About Certificates

  1. Gigya can obtain a certificate on your behalf as part of your subscription. When we do, we use Comodo.
  2. For the best user experience possible, we require a SAN certificate.
  3. For security reasons, Gigya will not install wildcard SSL certificates.
  4. Gigya does offer Multi-Domain certificates under certain circumstances.

What Is A Multi-Domain Certificate

multi-domain certificate is an SSL certificate that can be used for multiple (pre-defined) domains, i.e., and and Multi-Domain certificates differ from wildcard certificates in that a wildcard certificate can be used for all sub-domains of a single FQDN without defining what those URLs may be beforehand (e.g., * ), whereas a multi-domain certificate can be used for multiple FQDNs (up to 100 unique URLs per certificate). Gigya does not support wildcard certificates due to security issues that can arise from not pre-defining the authorized URLs.

A multi-domain certificate would be best used if your company has multiple TLDs, i.e., .net, .com,, etc.

When provisioning an SSL certificate for a site, make sure the trusted domain is unique for this site. Provisioning will fail if any of the trusted domains are already associated with another site.


Before You Set Up Your Certificate

For this solution to work effectively, every site connected to the API Key needs to use a Domain Prefix with an SSL Certificate connected to it. Whenever a new site or subdomain is added to the API key's list of Trusted Site URLs on the Site Settings page of the Gigya Console, this certificate must be re-generated and domain ownership re-verified for all listed subdomains.

  1. Ensure that all domains and subdomains needed for the API key are listed correctly in the Trusted Site URLs section of the Site Settings page in the Gigya Console.
  2. Determine the Prefix (alias) that will be used for all the Trusted URLs of your site (e.g., or as the CNAME. Note that you must have a CNAME for every unique 2nd-level domain name you are using.
  3. Locate the Site ID of the API key that you are creating the CNAME for. For help determining your Site ID, see Certificate Provisioning - Important First Steps.
  4. Create a CNAME alias in your DNS records for each of the listed sites using the pre-defined Prefix and point them to <siteID> . (Where siteID is the ID you received in Step 3, above).  


Obtaining and Installing the Certificate

There are several steps required in order to obtain an SSL certificate.

Gigya will purchase and host your certificate, once you have completed the steps listed in Before You Set Up Your Certificate, above, follow the instructions listed at Certificate Provisioning to start the process of provisioning your site's SSL certificate. After initiating the Certificate Provisioning process, you will need to verify the emails that are sent to each of the Official email addresses associated with each of the trusted domains. Once verification is complete for all domains, your SSL certificate will be automatically installed for the listed domains.

  1. Domain verification is performed by the Certificate Authority to ensure that you own the domain listed in the certificate. Gigya only supports verification via email, which requires the official contact emails listed in Whois for the domains to validate a verification email.


    Gigya only supports domain verification by email via pointing your new CNAME to <siteID> (Where siteID is received from Gigya Support during Step 3 of section Before You Set Up Your Certificate.

  2. The CA signs your certificate with their intermediate certificate(s), and sends the intermediate certificate(s) and your certificate for installation.


This recommended best practice that Gigya supports, is illustrated below.


Domain Verification

Once the Certificate has been requested, the domain verification process takes place. If you correctly pointed your new CNAME to <siteID> (you can receive your siteID from your Implementation Consultant) you will be asked to verify domain ownership of all listed sites via email. Once domain ownership has been verified (Gigya only supports domain verification via email to the domain's registered contact addresses), the Certificate Authority will sign your SSL certificate and provide the certificate bundle.

Gigya now has everything we need to install the certificate and your SSL should be active within one business day.


Detailed flow chart


The Custom Endpoint

Gigya will create a custom proxy endpoint dedicated to your CNAME in the form <siteID> You can receive the Site ID when you contact your Gigya Support or your Implementation Consultant to discuss the Prefix you will be using as an alias so that you can update the CNAME in your DNS record correctly.

As always, please contact your Gigya Support or your Implementation Consultant with any questions you may have.



Additional Information

If it is necessary for you to purchase your own certificate(s), contact Gigya Support for more information.

To perform Certificate Provisioning for your site, see Certificate Provisioning.

Unable to render {include} The included page could not be found.





Custom API Domain

You can enter a custom API domain to route SAP Customer Data Cloud traffic through your domain, instead of through the various "" domains (e.g. calls will go through instead of URL Shortening

SAP Customer Data Cloud supports the Bitly shortening service for customers who use Bitly tracking capabilities in addition to SAP Customer Data Cloud reporting capabilities.

When shortening is enabled all shortened URLs will go through, including URLs that have been shortened using SAP Customer Data Cloud's custom shortening service.  

When you enable this option, you will be presented with a pop-up asking you to authorize SAP Customer Data Cloud to use your Bitly account. You must have a Bitly account in order for SAP Customer Data Cloud to use it as a url shortening service.

Bitly premium account holders using a branded short domain: After authorizing SAP Customer Data Cloud to use your Bitly account, add your short domain in the Additional Share URLs section.

Custom URL Shortening

SAP Customer Data Cloud includes a URL shortening service for URLs that you publish to social networks using SAP Customer Data Cloud's API. If SAP Customer Data Cloud's URL shortening service is active, each of the distributed URLs will be shortened to a URL that corresponds with your Data Center.

  •  domain for customers using the US data center
  •  domain for customers using the European data center.
  •  domain for customers using the Australian data center.

If you wish to set up a custom short URL that will be used when publishing content to social networks: 

  1. Define a CNAME entry in your DNS server. There are two methods you can use to define a CNAME entry in your DNS server: either contact your provider and request a CNAME entry, or define a CNAME entry in your DNS server.  Specify your short domain and point it to your designated short URL . For example:    CNAME    
  2. Return to SAP Customer Data Cloud settings and enter your CNAME value in the corresponding text field (see screenshot below).

Note: SAP Customer Data Cloud's URL shortening service will only shorten trusted, accessible URLs (i.e., urls related to the API's base domain, included in the trusted site or trusted share URLs list or the global whitelist, and resolvable via DNS). Attempting to shorten any URL that does not meet these conditions will result in an error.

Redirect Method

You can select your short URL redirect method out of the following options:

  •  JavaScript redirect - Use JavaScript to do a client-side redirect, not adding anything to fragment or query string
  • Server redirect, replacing existing URL fragment - Use HTTP 302 redirect and append a new URL fragment or replace the existing fragment
  • Server redirect, append to existing URL fragment - Use HTTP 302 redirect and append a new URL fragment or concatenate to an existing fragment like a query string (with & separator)
  • Server redirect, append query string if URL fragment exists - Use HTTP 302 redirect and append a new URL fragment if one doesn't already exist and a query string if a URL fragment does exist on the target URL

 The default redirect method is JavaScript.


SAP Customer Data Cloud encrypts all a user's PII, as well as all usernames, emails, friends' names and friends' emails. Encrypted fields are stored and transmitted encrypted. SAP Customer Data Cloud manages this transparent decryption.  

PII includes:

  • In the Profile object:  "firstName", "lastName", "address",    "name",  "phones".
  • In the Identity object:   "firstName", "lastName", " address",  "phones".  

To set encryption for specific fields, including fields which are not covered by PII encryption, use accounts.setSchema or IDS.setSchema

Note that SQL-like queries such as and the Identity Query Tool cannot use comparison operators (>, >=, <, <=) or regex expressions on encrypted fields. SQL-like queries are case insensitive on encrypted fields but do not support searches for partial matches.

For more information see Encrypted Fields.



Configure Social Network Application Keys

Press the "Providers Configurations" tab under the "Site Settings".


You will be directed to the Providers Configurations page, where you must configure social network application keys.

The Gigya service uses external applications to deliver its services in social networks.  The external applications act as mediators, enabling the Gigya service to provide the various functions it offers – such as retrieving user info or sending notifications.
For the Gigya service to work in your site, a dedicated external application is required for each social network you wish to use.
The following tutorials will guide you through the process of opening and setting up external applications:

We will be glad to assist if you need help with this process. You can contact us by filling in a support form on our site.
This is a screenshot of the form in Gigya website Providers Configurations for setting up social networks external applications:


Considerations for SN Apps when SSO is Enabled

When SSO is enabled, sites have the option of only configuring apps at the parent level, which will then apply to all child sites. However, if the site defines an application that is not the default (group) application (at the parent level), then the child site's application will be used, overriding the group application. The implications of this are:

  • A user may not connect to different accounts of the same SN in different sites. So if the user connected to Facebook account #1 in site A he must connect to the same FB account in site B or he will get an error.
  • When a user is logged out and then logs in for the first time to a site that belongs to the group using a social identity that was already used in a different site in the group he should be connected to the same group account as he was before.
  • When disconnecting from a provider on one site, all the connections for that provider (on all other sites) should be removed.

Facebook and Google+ Configuration

When you click on the Facebook icon, the following dialog opens. A similar dialog opens for Google+, without the External Application Canvas page.


Enable CName

Check this box if you are using a CName.

Enable Native SDK Capabilities


Checking Native SDK Capabilities in Facebook app configuration enables automatic session renewal for users logged in through Facebook and automatic login when autoLogin is set to "true" in the WebSDK Configuration. In socialize.showLoginUI the parameter autoDetectUserProviders requires native SDK capabilities. Calling socialize.logout to log the user out of Facebook requires native SDK capabilities. 

Native SDK capabilities require that your site is using a valid CName and that the Facebook Client OAuth Settings have your domain specified in the Valid OAuth redirect URIs in the Facebook app Settings Tab (Advanced).

Enabling this option also causes calls to Facebook to be generated whenever the Gigya Web SDK is loaded on a page.


Checking Native SDK Capabilities in Google+ app Configuration enables automatic login when autoLogin is set to true in the WebSDK Configuration. This is required for Google+ cross device SSO (also known as cross platform single sign-on); Users who are already logged in on one platform (for example their mobile phone) can use their Google+ credentials to open the site on another platform (for example their laptop) without being asked to sign-in again. App permissions are automatically shared across the different devices.  

Calling socialize.logout to log the user out of Google+ requires native SDK capabilities .  

Facebook External Application Canvas Page

You have the option of providing the URL of a page that will be shown in an IFrame in Facebook's external application canvas page. For more information, see Canvas Overview in the Facebook Product Docs.

To use this feature, you must first open an external application in Facebook and enable the canvas page as described in the Optional - for advanced users only section.


We will be glad to assist you with implementation, configuration, or any other issues. For more information, please see Opening A Support Incident. 

Unable to render {include} The included page could not be found.

Social Network Geographical Limitations

Certain countries highly restrict social network accessibility. The complete list is outside the scope of this document, however, the following social networks are known to be accessible from China:

  • RenRen
  • Sina Weibo
  • WeChat

Any social network not explicitly listed above should be considered inaccessible. Here is an additional resource, though appears to not be up to date.

Unable to render {include} The included page could not be found.