Console and Workspace

Overview

Canopy separates the people who build an integration from the people who run an organization, and gives each their own application. They are not two accounts: you sign in once, and a product switcher moves you between whichever you can reach.

Signing in does not always take you to the same place. Canopy asks what you administer and opens the application that matches.

The two applications

Each is deployed separately. The Console lives on a console. subdomain and the Workspace on a workspace. one, and both are signed in to with the same Canopy account:

Developer Console

Where an integration is built. Applications and environments, the hierarchy, roles and permissions, API keys, OAuth clients, webhooks, SSO and directory sync.

Admin Workspace

Where an organization is run. The people in it, invitations, who administers what, recent activity, and the account itself.

Where things live

Most things belong to exactly one application, and the name usually gives it away. One does not:

Identities are the same people in both

There is one set of end users. Both applications show them, and what differs is the job you are there to do rather than the records you are looking at:

In the Console, you work with identities to prove the integration behaves: sign one in, get a token, evaluate a permission at a node. That is development work, and it belongs in a non-production Environment.

In a production Environment, the Console closes its identity pages. Those are real people, and administering them is the Workspace's job. A developer who genuinely needs them, usually to reproduce a customer's report against the data it concerns, is granted production access by an account administrator.

In the Workspace, the same identities are the people you administer, listed with the actions your authority allows.

If a page in these docs tells you to open Identities, the surrounding section says which application it means.

Which one is yours

These docs are written for both audiences, in different language, because the two jobs are different.

Building an integration? Everything from Quick Start onward is yours. You will work in the Console and call the API.

Administering people? You will work in the Workspace, and the Administration section of these docs is written for you. Start with Your responsibility, because what you hold decides what the rest of the application shows you.

Do not be surprised if either application shows you less than these docs describe. Both render from what you have been granted: an action you cannot take is absent rather than disabled, and a page you cannot open is not offered.

Next Step

Building the integration? The Quick Start walks through a permission catalog, roles, a hierarchy, and a first permission check, end to end.

Environment

API version

v1.0

On this page

Was this page helpful?

Tell us how we can improve this guide.