Authorization

What this step is for

After Canvas has signed in, it must know how to sign every request it makes to the application later (in workflows, blocks and scripts): which address to use and which headers to add, for example Authorization: Bearer <token>.

In this step you write a short script that builds exactly that from the values saved by the previous steps. Canvas keeps the result safely and adds it to every request to this application, so your workflow authors never have to deal with tokens.

Triggered by: Application registration and after each successful authentication or token refresh.

The script

The script returns the authorization data:

Field	Required	Meaning
baseUrl	Yes	The address of the application's API. A trailing / is removed.
headers	No	Headers added to every request, for example Authorization.
params	No	Query parameters added to every request.

What you can use in the script:

Name	What it is
appVault	The settings saved by the previous steps (for example the base URL, the chosen workspace).
appVaultSecret	The secrets saved by the previous steps (for example the access token).

config, configOauth and response are not available here: they exist only in the Authentication step. If you need one of those values, save it in the Post Handler to appVault or appVaultSecret first.

Example: a bearer token.

return {
  baseUrl: appVault.baseUrl,
  headers: {
    'Authorization': `Bearer ${appVaultSecret.access_token}`
  }
};

Example: an API key in a header, and the chosen workspace as a parameter.

return {
  baseUrl: appVault.baseUrl,
  headers: { 'X-Api-Key': appVaultSecret.api_key },
  params: { workspace: appVault.workspaceId }
};

Take tokens, passwords and keys from appVaultSecret, not from appVault. Settings in appVault can be read from workflow scripts.

When it runs

When	What happens
A user connects the application	Right after the sign-in, and again after the user answers the Context questions.
A token is renewed (scheduled or with Test)	After each successful renewal, so the new token is used straight away.
After an OAuth approval	After the sign-in that follows the approval.

Each time, the previous authorization data is replaced by the new one. The connected application is shown as "authorization configured" once the script has run successfully.

Testing

Use the Test tab to run the step and check the result. Make sure that:

• baseUrl is the real address of the API;
• the headers contain the real token, not undefined.

Common problems

Problem	What to check
"Your script doesn't produce a JSON object with obligatory 'baseUrl' field"	The script must return an object with baseUrl.
The header contains Bearer undefined	The Post Handler did not save the token. Check the name you used there (appVaultSecret.access_token).
Calls fail with "unauthorized" right after the token is renewed	The Post Handler must save the new token on every renewal.
A value from config is undefined	config is not available here. Save it in the Post Handler to appVault or appVaultSecret.