You must be an Administrator of an Optimizely account to register an application. Registering an application requires the following inputs:
- An application name that identifies your application to Optimizely Web Experimentation customers.
- One or more redirect URIs that users will be redirected to after authorizing access to your application.
- A client type (either public or confidential) according to the grant type you wish to use in your application.
Upon registering an application, you will receive a client ID that uniquely identifies your application and is required in the authorization flow described below. You will also receive a client secret, which is required for an authorization code exchange.
To enable users to authorize your application, you must link to Optimizely's authorization endpoint on
app.optimizely.com using the client ID and a redirect URI provided during registration. For example, in the Example URL below, the link shown on the right will send the user to an authorization flow for client ID
123 with a redirect to
http://myapplication.com. See Definitions below for a full list of required parameters in the authorization endpoint.
We recommend you use the Connect with Optimizely button below, which you may resize as needed:
After clicking this link, users will be prompted to log in to Optimizely. They'll then be given the option to accept or deny authorization for your application. Users can revoke your application's access to their data at any time in their API Access settings.
- client_id – The client ID for your application (see app settings).
- redirect_uri – A URL-encoded redirect URI to which the user will be redirected after successful (or failed) authorization. This must match one of the URIs provided during registration. If you're using an authorization code grant, insecure URLs such as those starting with
http://will be rejected. You can always add more redirect URIs to your application on the registration page.
- response_type – The grant type your application requests for authorization. As of August 2015, the supported types are
token(for implicit grant) and
code(for authorization code grant).
- scopes – A string denoting the access scope(s) your application requires after authorization. As of March 2015, the only supported value is
all, meaning the generated token will have permissions that match the user role of the authorizing user.
- state – value you provide that will be relayed back to you in the response to protect against CSRF attacks. For more information, see the CSRF section of the OAuth 2.0 spec.
- account_id – (Optional) Specify the account ID you want to authorize against.
Updated 17 days ago