Request Authorization

In order to perform actions on behalf of a user, they must first authorize you to do so.

When requesting authorization from a user, the domain is app.cronofy.com and not api.cronofy.com that you make the API calls to.

Authorization is received by performing the “Authorization Code” version of authorization as specified in section 4.1 of RFC 6749.

This will issue you a short-lived, single-use code that you will be able to exchange for an access_token and refresh_token for the user.

Example request URL #

The parameters are encoded in the querystring as specified in appendix B of RFC 6749. Additional linebreaks are added to the request’s path for clarity.

https://app.cronofy.com/oauth/authorize
    ?response_type=code
    &client_id={CLIENT_ID}
    &redirect_uri={REDIRECT_URI}
    &scope={SCOPE}
    &state={STATE}

Request URL parameters #

response_type required #

Must always be code as that is the only grant type supported by Cronofy.

client_id required #

The client_id issued to you by Cronofy to authenticate your OAuth Client. Authenticates you as a trusted client.

redirect_uri required #

The HTTP or HTTPS URI you wish the user’s authorization request decision to be redirected to.

In development this can be any value, but in production this has to be a pre-registered value. This helps us guard against phishing attacks by controlling where we return authorization codes to for your application.

We can only support wildcards in the host name for subdomains of domains under your control, eg:
https://*.example.com/auth/cronofy/callback

Otherwise, the URL must be static and we can support multiple values.

If your URL is dynamic, you should utilize the state parameter to pass variables. See our FAQ on using this to support dynamic values in your OAuth flow.

scope required #

The scope of the privileges you want the eventual access_token to grant. Only one scope is currently supported:

organizational_unit_scheduler to allow access to the user’s Cronofy Organizational Unit configuration and to create Scheduling Requests.

The format of this value is specified in section 3.3 of RFC 6749 but is a space-separated String of named scopes.

state optional #

A value that will be returned to you unaltered along with the user’s authorization request decision.

The OAuth 2.0 RFC recommends using this to prevent cross-site request forgery.

locale optional #

A String value for the locale to use for display purposes. If not provided we will use the locale provided by their browser. In general you will not want to supply this and instead rely on the user’s browser to provide the correct locale.

Currently supported locales are:

ar Arabic
cs Czech
cy Welsh
de German
en US English (default)
es Spanish
fr French
fr-CA Canadian French
he Hebrew
it Italian
ja Japanese
nl Dutch
pl Polish
pt-BR Brazilian Portuguese
ru Russian
sv Swedish
tr Turkish
zh-CN Simplified Chinese

Response URL parameters #

You will not receive a direct response to your Authorization Request, instead the user will be redirected to the REDIRECT_URI with additional querystring parameters specified.

The responses are fully specified in section 4.1.2 of RFC 6749.

Successful response #

code #

A short-lived, single-use code to be used to make an Access Token Request.

Will always be 32 character String of ASCII characters.

state #

The value you passed for the state within the authorization request.

Error response #

error #

A single ASCII error code. The complete list is within section 4.1.2.1 of RFC 6749, these are the most commonly encountered:

access_denied the user declined your request
unsupported_response_type your request’s response_type was not code
invalid_scope no valid scopes were specified in your request’s scope