Site Setup

Skip to end of metadata
Go to start of metadata


The following guide walks you through Gigya's setup and serves as a reference document for the configuration options.

If you are already a registered user, please sign in to your Gigya account at To register as a new Gigya user, please contact Gigya at If you already have an account, please contact your Account Manager.


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.  

Add Your Site

Once you sign in to Gigya, you will be able to view your Dashboard. The first thing you must do to get your Gigya implementation up and running is add your site domain name to the sites table in the Dashboard.

Press the "Add site" button:

Fill in the site domain, select the Data Center where your sites' data should be stored (options are US, AU or EU) and optionally enter a description, then press "Add Site".


  • A valid domain should be entered in the form of "" (there is no need to include the "http://" prefix). If you are using Gigya 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. The selection of the Data Center is the Client's.  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.

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


This API key will be used in every page in which Gigya plugins or API calls are integrated. 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 entry indicates the location of the server holding your user data. 
  • It cannot be changed once the site has been created. 
  • To verify site location contact your implementation manager.

Partner ID

The partner ID is displayed at the bottom of the table.

Secret Key

The "Secret Key" is provided at the bottom of the table. 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.

Site Settings

When you press the "Site settings" of your domain, you will be redirected to the Site Settings page, where you will configure social network application keys.


When you press the "Reports" link, you will be redirected to the site's reports page. Read more in our Reports guide.


When you press the "Plugins" link, you will be redirected to the site's plugins page. Read more in our Engagement Add-Ons guide.

Technically you are now ready to use Gigya in your application. 

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

Trusted URLs

Trusted Site URLs

The configuration form provides instructions for setting up trusted site URLs. Please follow them to setup any URLs you wish to include in this configuration. If the Gigya 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 to:

  • Apply the configuration to specific subdomains only (i.e. "").
  • Apply the configuration to specific paths (i.e. **)


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


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:

  • The Trusted 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. 


When sharing URLs via any Gigya Add-ons, the URL being shared 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 share 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 Gigya . We highly recommend specifying a subdomain in your site and defining a CNAME entry in your DNS server that maps that subdomain to client-proxy.<DC> 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.


Note: The <DC> placeholder in the subdomain mapping represents your site's Data center.
Mapping of Data Center to placeholder value is as follows:
US data center - us1
European data center - eu1
Australian data center - au1
Russian data center - ru1

For example, customers on the European Data Storage Center need to point their CNAME to
If you are not sure of your DC location or you are using a different DC not listed here, see Finding Your Data Center.


To apply this with Gigya:

  1. There are two methods you can use to define a CNAME entry in your DNS server:

    1. Contact your provider and request a CNAME entry. Specify a new subdomain in your site and point it to client-proxy.<DC> .

    2. Define a CNAME entry in your DNS server. Specify a new subdomain in your site and point it to  client-proxy .<DC>

For example:   CNAME 

Note that the CNAME must be a subdomain of your site. In other words the CNAME must end with your site name.

  1. Return to Gigya settings and enter your CNAME value in the corresponding text-field (see screenshot below).
    Note: only a subdomain of the domain which you have configured in Step 1 will be accepted.

  2. You can choose to enable CNAME for all OpenID providers - this will enable sites that use Social Login via OpenID to display their own domain name in the Social Login dialogs instead of "Gigya socialize":


    Note: This option will not work with CDN acceleration (DSA). URL Shortening

Gigya supports the Bitly shortening service for customers who use Bitly tracking capabilities in addition to Gigya reporting capabilities.

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

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

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

Custom URL Shortening

Gigya includes a URL shortening service for URLs that you publish to social networks using Gigya's API. If Gigya'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 Gigya settings and enter your CNAME value in the corresponding text field (see screenshot below).

Note: Gigya'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.


Gigya encrypts all a user's PII, as well as all usernames, emails, friends' names and friends' emails. Encrypted fields are stored and transmitted encrypted. Gigya 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 Global Configuration. In socialize.showLoginUI the parameters  autoDetectUserProviders and  facepilePosition (allowing use of Facepile) require 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 Global 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.

Gigya Support

We will be glad to assist you with implementation, configuration, or any other issues. You can contact us by creating a New Case via the Gigya Support Portal. You can also access the support page by clicking Support on the upper menu of Gigya's site. Once at the Support Portal you will be able to view and follow up with any open cases you have, as well as create a New Case


Once you create a New Case, fill out the required information, being sure to select the correct API Key from the drop-down, and press Submit. 



If you have Admin permissions on your site, you can access the Admin link that will be visible in the upper menu:

As administrator, you can:

  • Manage Users - you can add, edit, and delete users, and change their account permissions.


Social Network Geographical Limitations

For internal use only

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.

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