Shutterfly Open API  |  Seamless Sign-in Setup

With Seamless Sign-in, if the user is using your application Web site and is signed in there, she won't normally need to provide Shutterfly password or do a separate Shutterfly sign-in when your app calls the Shutterfly Open API on her behalf.

For this to be secure, you must protect the shared secret that goes with your app ID, as explained here: Authentication and Authorization


Seamless Sign-in works as follows:

  1. You do some initial application-level setup with Shutterfly.
  2. The user uses your app or Web site, and eventually needs Shutterfly Open API functionality. Your app sends the user to a Shutterfly user setup page.
    • The user signs in to Shutterfly (or signs up for a new Shutterfly account if she does not already have one), and grants permission to your application.
    • Shutterfly then redirects the user's browser to your app, on a "callback URL" that you specified.
  3. On callback, Shutterfly gives your app a user token to store. Your app stores this token, and passes it on future Shutterfly Open API that may require user authorization. If your app stores the token correctly, your app should never again need the user to sign in to Shutterfly.
  4. If your app should ever lose the Shutterfly user token, no problem. Send the user to the Shutterfly user-setup page again.
    • The user will have to sign in, but will not need to explicitly grant permission to your application again. The page will immediately redirect to the callback URL you provided.
    • Store the Shutterfly user token.

Application setup

  1. Decide if you can secure your shared secret (i.e., truly keep it secret). If you can't, then your application is not eligible for Seamless Sign-in. Please use User Authentication instead.
  2. Configure your app to say secret is guarded, using My Applications.
  3. Optional: Configure your app with a default Callback URL, Logo URL, and About URL.
    • Callback URL: An URL that Shutterfly's permission-granting page will return control to after the user has granted (or denied) permission. Configuring this parameter is not absolutely required, because your app can specify the URL dynamically, as described below.
    • Logo URL: A public URL where Shutterfly can get your application's (or company's) logo image. If present, Shutterfly will display the image to the user when asking the user to grant permission.
    • About URL: A public URL where a user could find a description of your app or company. If present, Shutterfly will display it as a link when asking the user to grant permission.


Send the user's Web browser to this Shutterfly page:

You will need to attach certain URL parameters to the call:

Required: Yes
Example: 693228dc384ba239269fa6f80de8ce97
Description: Your application ID.
Required: No
Description: Your application's identifier for the user. Shutterfly may store this, but it is mainly so that your app can recognize the user, on callback.
Required: No
Description: Your application's desired callback URL. When provided, this parameter overrides your default callback URL (if any). This parameter is only required if you have not configured a default callback URL for this application.

You will also need to sign the call. A completed, fully-signed callback URL would look something like this, prior to URL-encoding (and all on one line):


When Shutterfly calls your callback URL, it will tell you whatever you had previously specified for oflyAppId and oflyRemoteUser, and add these parameters:

Example: 9BcNWjVs1g
Description: Shutterfly user identifier, which your app must store for future use. This value will not change, and may be used to build /userid/ URLs in the User Data API. Note: If the user declined to grant access, a special value will be returned, "no-grant".
Description: THIS SHOULD GENERALLY BE IGNORED, AND NOT STORED. It is returned only if the user granted access. It is the e-mail that the user actually told Shutterfly when she signed up / signed in. Shutterfly lets the user change it over time and you will NOT be informed of changes. If you have not pre-arranged with Shutterfly a special reason for keeping it, then please do ignore it.

Given the above example, Shutterfly might construct your callback URL something like this, prior to URL-encoding (and all on one line):

Finally, you store the returned oflyUserid in your application. All future calls must use this stored oflyUserid to gain permission seamlessly.

Pass the oflyUserid as a URL parameter on every Shutterfly Open API call that needs user authentication / authorization, as explained here: App Authentication.

© 1999–2018 Shutterfly, Inc. All rights reserved.