Request Inline User/Resource Access PRERELEASE

Description #

When authenticated for an Enterprise Connect account, tokens can be obtained for an account or resource inline, before their events have been synchronized.

The alternative is to make a Delegated Access Request which utilizes a callback once the calendar is fully synchronized.

URL format #

Example request #

POST /v1/service_account_authorizations HTTP/1.1
Content-Type: application/json; charset=utf-8

  "response_type": "inline",
  "scope" : "{SCOPES}"

Example Response #

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Pragma: no-cache

  "token_type": "bearer",
  "access_token": "P531x88i05Ld2yXHIQ7WjiEyqlmOHsgI",
  "expires_in": 3600,
  "refresh_token": "3gBYG1XamYDUEXUyybbummQWEe5YqPmf",
  "scope": "create_event delete_event",
  "account_id": "acc_567236000909002",
  "sub": "acc_567236000909002",
  "linking_profile": {
    "provider_name": "google",
    "profile_id": "pro_n23kjnwrw2",
    "profile_name": ""

Request parameters #

response_type required  #

A value of inline must be provided to indicate the inline variant should be used, otherwise the asynchronous Delegated Access Request variant will be used.

email required  #

The email address of the account or resource to receive delegated access to.

scope required  #

The scope of the privileges you want the eventual access_token to grant.

These must have previously been granted via the delegated_scope parameter of an Enterprise Connect authorization request.

Error responses #

401 Unauthorized #

The request was refused as the provided authentication credentials were not recognized.

When an OAuth refresh_token is available then it should be used to request a replacement Service Account access_token before the request is retried.

422 Unprocessable #

The request was unable to be processed due to it containing invalid parameters.

The response will contain a JSON object containing one or more errors relating to the invalid parameters.

For example, if you omitted the required email parameter, you would receive a response like:

  "errors": {
    "email": [
        "key": "errors.required",
        "description": "required"

The key field is intended for programmatic use and the description field is a human-readable equivalent.

When attribute-based validation passes, authorization failures are returned under an authorization attribute, including details of the type of failure in a similar form to how they are delivered for the asynchronous Delegated Access Request variant.

  "errors": {
    "authorization": [
        "key": "errors.service_account.unknown_email",
        "description": "Cannot find impersonated user"