Please see below for detailed information about our upcoming release dates, as well as information on how to prepare for upcoming changes to the Gigya platform.
If you are maintaining a list of IP addresses for whitelisting purposes, see Whitelisting Gigya IP Addresses for an updated list.
Should you have any questions or concerns regarding your implementation and how it may be affected by these changes, please do not hesitate to reach out to your Implementation Consultant or open a support ticket.
Gigya Change Schedule
- Wednesday, November 15, 2017
- Monday, September 25, 2017
- Monday, June 26, 2017
- Monday, March 27, 2017
For an archive of older changes, see Past Changes Requiring Your Action.
Monday, November 11, 2019
Object Fields in Profile Object
Who Will Be Affected: Any implementation that uses data in the fields outlined below, may be affected.
Impact: On November 11, 2019, we are changing the way existing data is handled for the following JSON object fields in the profile object. Previously, any data written to a field in the object, would nullify data that was already saved to other fields in the object. For example, if the first call wrote a value to “likes.id” and a second call wrote a value to “likes.name”, the second call would also remove the existing “likes.id”. This changes fixes that behavior. The relevant fields:
Why: This behavior did not match the intended design and therefore is a bug fix.
Action Required: Check to see if your implementation relies on the old behavior. If it does, change your implementation to match the new behavior.
Monday, September 2, 2019
New IP Addresses
New load balancer IP addresses added to our Russia and China datacenters. For a full list of SAP Customer Data Cloud IPs, see Whitelisting Gigya IP Addresses:
Monday, May 27, 2019
Social Login Initiation Domain Validation
From 27 May 2019, all websites (domains) that initiate Social Login will need to be explicitly whitelisted in the Gigya Admin Console. Domain validation is already in place for redirects on social logins, so this change only applies to social logins which redirect to a different domain from where they were initiated. For example, if site A initiates Social Login, and redirects to site B for that purpose, the domains of both A and B need to be added to the list of trusted sites in Gigya’s Admin Console.
Who Will Be Affected: Customers with a live implementation of social login that is triggered from a domain that is not whitelisted on the API key.
Impact: Following this change, if a customer does not whitelist a domain that initiates social login, end users will not be able to use social login on that website.
Why: This change further enhances security for social logins.
Action Required: For all of your websites which initiate Social Login:
- Open Gigya’s Admin Console in the “Site Settings” page
- Make sure all domains that are related to your Social Login flow are listed under “Trusted Site URLs”:
- Repeat for any relevant sites (API keys)
The license could not be verified: License Certificate has expired!
Monday, April 8, 2019
Minor Change to Consent Enforcement in Registration
Previously, end-users could complete registration on a child site with a mandatory “other” consent statement without agreeing to that statement, if it was not required on the parent site. This change fixes that.
Who Will Be Affected: Customers with a live implementation of Customer Consent may be affected.
Impact: Following this change, end-users who have previously registered on a child site, may be required to grant consent to all the mandatory site terms, via the “Registration Completion” screen of your site.
Why: This change ensures that agreeing to the site mandatory “other” statements is a pre-condition for site registration.
Action Required: Review your implementation and make sure any mandatory consent statements checkboxes are visible in the “Registration Completion” screen. This ensures that users may grant consent and continue using your site services.
Monday, January 21, 2019
XML Format No Longer Returned in Socialize Responses
Previously, many socialize APIs allowed a value of 'xml' in the format parameter, and used this value as the default unless specified otherwise. Following this change, the 'xml' value will no longer be supported, and all responses will be returned in JSON or JSONP.
Who Will Be Affected: The following customer implementations may be affected:
- Implementations of the socialize REST APIs that do not pass any value for the format parameter
- Implementations of the socialize REST APIs that explicitly pass a value of xml for the format parameter
Impact: On January 21, 2019, we will no longer send a response in XML format from our APIs. All responses will be returned in JSON. This has an impact on REST APIs in our socialize namespace.
- The xml value of the format parameter in APIs will no longer be supported (e.g., in socialize.notifyLogin).
- The default value of the format parameter will now be json.
Following are the affected REST APIs. Note that for most of these methods, the xml value of the format parameter has already been documented as deprecated:
Why: We are changing the APIs in the socialize namespace to maintain consistency with all other namespaces, which do not return XML responses.
Action Required: Review your code that expects to receive a response from socialize REST APIs and make sure that it supports a JSON format.
Monday, November 19, 2018
1. Redirection in SSO Gateway
Gigya will now enforce redirection only to a URL that is part of the site's (or site group's) base domain.
Who Will Be Affected: Any sites that implement SSO may be affected.
Impact: Starting November 19, 2018, Gigya will no longer allow open redirects during an SSO flow, but will validate that the base domain of the redirect URL belongs to the site or site group initiating the redirect.
Why: To align with security best practices and require only explicitly authorized redirect URIs.
Action Required: Check the redirects configured in your SSO implementations, and make sure that all the base domains in those URLs are listed in the Settings page of Gigya's Console.
2. Changed Response Format of Preferences Object in accounts.login and accounts.verifyLogin
Who Will Be Affected: Any SAP Customer Consent customers may be affected.
Impact: On November 19, 2018, the format of the 'preferences' object returned in the response of accounts.login and accounts.verifyLogin will change from a flattened format, to a regular JSON.
Sample object before the change:
Sample object after the change:
Why: Standardization of API responses.
Action Required: Review your code to see if it expects to receive the 'preferences' object in a flattened format for these APIs. If it does, update the code to expect a JSON format.
3. OIDC JWT to Return Integers, not Strings
Who Will Be Affected : Implementations of OIDC.
Impact: On November 19, 2018, the value of "exp" in OIDC JWT will be returned as integers, not strings.
Why: Compliance with OIDC protocol.
Action Required: If your site implementation includes an OIDC login, review your implementation and update it to receive integers in the exp parameter of the JWT.
4. Changes to Response Messages
As part of the new capability to edit user-facing messages in the reset password flow, existing response codes have changed.
Who Will Be Affected: Implementations that rely on receiving a specific response in a defined flow for response codes 403025 and 401030.
Impact: On November 19, 2018, these response codes will have changed messages. 403025 has also changed its functionality. The new responses:
- 403025: "Uh-oh, your link is not valid. Restart the reset password flow to get a new link."
- 401030: "You've already used that password. Please create a new one."
Why: As part of the improvement to the reset password flow, that allows admins to customize user-facing messages, these messages have changed.
Action Required: Review your code and check the flows that involve these response codes.
Thursday, October 11, 2018
- StumbleUpon is no longer a supported social provider, as this network has ceased to exist.
Tuesday, September 4, 2018
The following sections outlines the details of the change to Gigya's US data center, including new IP addresses, impact on the day of the switch, and frequently asked questions.
Load Balancers (HTTP/HTTPS):
Staging (HTTP / HTTPS)
* NAT IPs:
* Used by Webhooks, IdentitySync, email share verification . (Social networks are also accessed through those IPs)
Mail servers (SMTP):
If you have explicitly whitelisted any of Gigya's US IP addresses, you should not delete them from the whitelist, as they may still be in use.
During the cut-over window we anticipate a period of up to 2 minutes where connectivity to Gigya may be impacted. Users of Gigya’s Console may be logged out during that window.
What action do I need to take?
Most likely, you will not need to take any action. However, if you have explicitly whitelisted any Gigya owned IP addresses for connections to or from the Gigya US1 datacenter, you must add the new Gigya IP addresses to your whitelisting settings before September 4th, 2018. The new IP addresses for whitelisting are provided above.
The following example scenarios would require your action:
- If you have whitelisted Gigya IP addresses on your SFTP server to receive incoming files from IdentitySync
- If you have whitelisted Gigya IP addresses to receive Webhooks notifications
- If you have whitelisted Gigya IP addresses on your SMTP server which is relaying Gigya Registration-as-a-Service emails
Please note that if you have intentionally bypassed our CDN or DNS servers when making connections to Gigya, you should get in touch with your Account Manager.
What is the rollback plan for the changes?
The migration is done by pointing the load balancers and DNS records (after lowering the TTL) to Amazon Web Services (AWS) instead of the current primary datacenter and making the databases the master nodes in AWS. At this stage, the data will still be replicated between the datacenters, but in the opposite direction. In case rollback is needed, we will switch the configuration back as it was before the migration.
What is the disaster recovery plan and how has it changed?
At stage 1 we will have our primary datacenter work from the AWS N.Virginia region which will have full redundancy for all components, and the Equinix datacenter (current US primary datacenter) will become the disaster recovery. This is planned for September 4th 2018. In summary, we will be switching sites between our current primary datacenter (Equinix) and the disaster recovery datacenter (AWS).
At stage 2, we will work from multi availability zones in AWS which will provide another level of redundancy and after it’s fully operational we will stop using the Equinix datacenter for disaster recovery. This is planned for Q1 2019.
What kind of cutover validation will there be? How will you be validating that everything is working as expected?
The environment is built in a similar way to other working datacenters that we already have in AWS and with the exact same components and versions as we have in the existing DC.
In preparation, we are running extensive tests to verify that all of the
components are working as expected before allowing customer traffic through. Those tests include: functionality, performance, resilience and redundancy.
Will long life sessions still be active after the AWS migration?
Existing sessions and tokens will not be affected by the move. There may be two minutes during which users will experience connectivity issues.
Users will remain logged into the following:
- Mobile sessions, including long-lived sessions
- Web sessions, including SSO
- Server side sessions
- Sessions generated using OAuth 2.0 tokens
- IoT sessions (e.g., Alexa OIDC)
Regarding NAT IPs, can we know which address is used for which service?
The new NAT IPs are a pool of IP addresses, and no address is specific for one service or application.
Which old IP addresses can be removed from whitelists?
Since the current datacenter will become the disaster recovery DC after the switch, you should keep existing IPs whitelisted as they are.
Wednesday, August 8, 2018
As previously detailed in our March Product Announcement, all Gigya Downloads are now only available via our official download site located at https://downloads.gigya.com.
If you are using any Gigya software (i.e., Mobile SDKs/Server SDKs/GConnectors) that are currently hosted on other services or repositories, be advised that all resources are now only available via the aforementioned site.
Wednesday, August 1, 2018
Facebook has deprecated the publish_actions scope. You should remove this scope from all of your Facebook apps to avoid warning messages and update any implementations that rely on it. This also means that certain Gigya features that use publishUserAction will cease to share to Facebook, to include:
- All Loyalty add-ons that rely on sharing
- 403023 - No_user_permission
- 403022 - Permission_not_requested
- 403017 - Unexpected_provider_user
- 403026 - Unauthorized_access_error
Monday, June 11, 2018
The integration with AOL is no longer supported as AOL has stopped supporting OpenID integrations.
Who Will Be Affected: Any customer who has a Gigya integration with AOL.
Impact: Any usage of AOL as an identity provider will not function.
Why: AOL has ceased to support any OpenID-based integrations. In addition, as this integration has no adoption, we prefer to focus on integrations that bring higher value to our customers.
Action Required: If your site uses AOL as an authentication option, you should remove that option, and encourage your users to use other identity providers instead.
2. OpenID-Based Integration with PayPal
The integration with PayPal that is based on OpenID has not been supported for a while, and was officially deprecated by PayPal on May 20th, 2018.
Who Will Be Affected: Any customer who has an OpenID based integration with PayPal.
Impact: This integration is no longer supported.
Why: In accordance with changes to PayPal’s platform, Gigya’s integration with PayPal is based on OAuth v.2.
Action Required: If you are still using the OpenID-based integration with PayPal, follow the steps in our Developer’s Guide to set up your OAuth integration with PayPal instead.
Wednesday, March 28, 2018
1. Verification email will be sent out only after registration is final
Who Will Be Affected: The impact of this change should be minor. Some implementations that require email verification in their policies may be affected.
Impact: A verification email will now be sent out only once a user is successfully registered (i.e., the finalizeRegistration parameter of accounts.register is set to true, or accounts.finalizeRegistration is called and returns “account pending verification”), and no data is missing from the required fields in the schema. Note that the email will not be sent if the account is pending registration.
Why: To prevent confusion and an erroneous delivery of multiple verification emails.
Action Required: A verification email will no longer be sent unless finalizeRegistration is set to “true” and all the required fields are supplied. You should review your code and make sure there is no dependency that says otherwise.
2. Two-factor authentication now requires setting up a Twilio account
Who Will Be Affected: Any customers using SMS for two-factor authentication.
Impact: As of April 30, 2018, in order to send SMS messages for TFA, you will be required to have a Twilio account and provide those credentials via the Console.
Why: In an effort to support those customers that require access to two-factor authentication logs about delivery and configuration, we have changed the platform to require Twilio account details to be configured within the Gigya console.
Action Required: In order to use the TFA service, you will need to obtain a Twilio account and enter those credentials in the Console. Gigya will use that account for sending TFA messages on your behalf.
3. When creating a new schema field, you are now required to set the type
Who Will Be Affected: Customers who have an automated process in place for schema field creation may be affected.
Impact: As of May 15th, when new schema fields are created, the type will need to be specified explicitly, rather than implicitly as was available before. If you do not set the type parameter, Gigya will respond with error code 400002 - Missing required parameter.
Why: To prevent errors and confusion when creating schema fields.
Action Required: Review your code and make sure that new schema fields are created with an explicit type, rather than relying on Gigya to infer the type the first time data is pushed to the field.
4. Custom Data and Data Store schema field limitation
Who Will Be Affected: Customers with a large amount of custom fields in their Data Store and ‘data’ schema may be affected.
Impact: A new limitation is in place. You can now have a maximum of 1500 custom fields in each of the ‘data’ namespace and the Data Store.
Why: This limitation is in place so as to provide better service and performance to our customers all around. The recently released ability to delete unused schema fields should minimize any negative impact this change might otherwise have.
Action Required: No action is required. If you are one of the few customers currently beyond the 1500 field maximum, your Account Manager will be reaching out to you directly to plan the next steps. In the interim there will be no disruption to your service.
Wednesday, November 15, 2017
UIDSignature and signatureTimestamp parameters no longer returned on server-side calls
Some of the most commonly used APIs that will be affected:
Who Will Be Affected: Anyone depending on receiving these parameters in server-side calls may be affected.
Impact: These parameters are no longer returned on server-side calls. Client-side calls will continue to return these fields as they do today.
Why: The parameters are not necessary in server-side calls, and those are made over a secure channel.
Action Required: Review any code that calls these APIs and ensure there is no dependency on these parameters.
Monday, September 25, 2017
1. Partial clauses no longer supported in accounts.search and ds.search
Who Will Be Affected: Anyone using the accounts.search and/or the ds.search APIs may be affected.
Impact: These APIs no longer support passing a partial field name. For example, if up until today you could send ‘SELECT email’ in your request, you will now have to specify ‘SELECT profile.email’.
Why: As Gigya’s data structure grows in complexity and flexibility, we can no longer support partial requests.
Action Required: Review any code that calls these APIs and ensure the requests are phrased properly.
2. Changed behavior of isLockedOut parameter in API Responses
Who Will Be Affected: Anyone who uses APIs that include user info in their response may be affected.
Impact: The isLockedOut status will be returned from API calls only when specified in the include parameter of methods that return a user object (such as accounts.getAccountInfo. Previously, it was always returned in the response of these APIs. In addition, the parameter is being wholly removed from the response of accounts.search, and cannot be included in the response.
Why: This change has been implemented as part of a performance update when getting or searching for the account.
Action Required: Review your code and make sure it does not depend on returning the isLockedOut parameter by default. When specifically expecting to receive back the parameter, make sure to specify it in the include parameter of the API call.
3. Changed status code and status reason in the response received for accounts.setProfilePhoto
Who Will Be Affected: Anyone using the accounts.setProfilePhoto API may be affected.
Impact: Instead of returning statusCode '0' and statusReason '0', the API will now return statusCode '200' and statusReason 'OK'.
Why: To maintain consistency with other API responses.
Action Required: Review your code and see whether it depends on receiving a specific statusCode and/or statusReason in the response from accounts.setProfilePhoto. If it does, anywhere that previously received statusCode '0' should now accept statusCode '200', and anywhere that previously received statusReason '0' should now accept statusReason 'OK'.
Monday, June 26, 2017
1. Parameters deprecated in socialize.getSessionInfo
Who Will Be Affected: Anyone using the socialize.getSessionInfo API and relies on receiving the tokenExpiration or sessionExpiration parameters in the response.
Impact: The tokenExpiration and sessionExpiration parameters will not be included in the response for socialize.getSessionInfo.
Why: The existing tokenExpirationUTC and sessionExpirationUTC parameters provide the same capabilities in a common (UTC) format.
Action Required : If your code depends on either tokenExpiration or sessionExpiration, use tokenExpirationUTC and sessionExpirationUTC, instead.
2. Changes to socialize.getToken API
Who Will Be Affected: Anyone using the socialize.getToken API may be affected.
- When grant_type=none and when passing the x_siteUID parameter (emulating the effect of socialize.notifyLogin), the providerSessions parameter will be ignored.
- When the code parameter is not passed, will return “Missing_required_parameter” (error code 400002) instead of “Invalid_parameter_value” (error code 400006).
- When grant_type=authorization_code, and an invalid code parameter value is passed, will return “Invalid_parameter_value” (error code 400006) instead of “Invalid_ApiKey_parameter” (error code 400093).
- When a user logs-in with this flow (with a site ID), the social identities are ignored.
- More informative, helpful error messages.
Action Required : If your code expects to receive providerSessions , or either of the specified error messages, update the code to match the new expected behavior.
3. Parameters deprecated in socialize.getFriendsInfo
Who Will Be Affected: Anyone using the socialize.getFriendsInfo API may be affected.
The following request parameters will be ignored: UIDs , requiredCapabilities , and signIDs when the value is set to true .
Note that when signIDs was set to true, the following response parameters were returned for every friend in the list. These will now be ignored:
Why: The UIDs , requiredCapabilities and signIDs parameters were not used.
Action Required : If your code depends on either the UIDs , requiredCapabilities , or signIDs parameters, remove these parameters from your code.
4. Error code changes to accounts.getConflictingAccount
Who Will Be Affected: Anyone using the accounts.getConflictingAccount API.
Impact: When the API is sent without a regToken , it will return error code 400002 instead of error code 400006.
Why: More informative, helpful error messages.
Action Required : Update your code to handle the 400002 error code.
5. Security requirements for socialize.addConnection
Who Will Be Affected: Anyone using the socialize.addConnection API.
Impact : You can pass the oauth_token parameter only over HTTPS. Requests over HTTP will return an “invalid_token” error (error code 403025).
Why: Enhanced security.
Action Required: Make sure calls to socialize.addConnection are made over HTTPS when passing the oauth_token parameter.
6. Error Code Change in accounts.login
Who Will Be Affected: Anyone using the accounts.login API.
Impact: When CAPTCHA verification fails, will return error code 400021, instead of the previous 400009.
Why: More informative message prompts the correct user action.
Action Required: Update your code to handle the 40021 error code.
7. Changed error code in accounts.registerCounters, accounts.unregisterCounters and accounts.incrementCounters
Who Will Be Affected: Anyone using these APIs.
Impact: When a request is sent without the counters parameter, the error code will now be 400002 - “Missing required parameter”, instead of the previous error code 400006 - “Invalid parameter value”.
Why: More informative message.
Action Required: Update your code to handle the 400002 error code.
8. Changed functionality of accountUpdated Webhooks event
Who Will Be Affected: Anyone tracking the accountUpdated Webhooks event.
Impact: You will no longer be able to track logins using the accountUpdated event. Instead, use the new accountLoggedIn event.
Why: To enable tracking events in a more nuanced way, the accountUpdated event was separated into two events:
- The existing accountUpdated event, which fires every time the account is updated, excluding login events.
- A new accountLoggedIn event, which fires every time the user logs in
Action Required: If you are using the accountUpdated event to track account logins, update your code to use accountLoggedIn for these events, instead. In addition, any notification URL currently subscribed to the accountUpdated event will be automatically subscribed to the accountLoggedIn event.
For more information, see Webhooks.
Monday, March 27, 2017
1. The OpenId Connect Relying Party (OIDC RP) redirectUri has been changed
Who Will Be Affected: All existing OIDC RP implementations.
Impact: Existing OIDC RP implementations were configured with a different redirectUri. Now that the redirectUri has been changed, users will not be properly redirected after login and the logins will fail.
Why: To aid in the reporting of OIDC logins.
Action Required: You must change the redirectUri registered with your OpenId Provider from? to ?, or if you’re using a CNAME, from https://<CName_alias>/GS/GSLogin.aspx? to https://<CName_alias>/socialize.finalizeOidcLogin? .
2. The socialize.exportUsers API is being deprecated
Who Will Be Affected: Anyone using the socialize.exportUsers API.
Impact: Starting April 10th, 2017, calls to this API will fail.
Why: To improve efficiency and de-duplicate API functionality.
Action Required: Locate any references to the above API and replace them with ids.search.
|Old Request - socialize.exportUsers||New Request - ids.search|
curl --request POST
curl --request POST
ids.search returns JSON and not csv. If your current workflow requires csv, you can convert the JSON response using any number of online tools.