3. Roles you need for this guide

Permissions in OpenApp are roles attached to your user inside each org (not globally on your account).

The org you selected in the previous step needs the admin role—or equivalent permissions—to manage integrations, devices, entities, and API keys for the rest of this guide. A personal workspace (from Create account) includes admin by default; in any other org you selected, you need the same level of access there. See Roles, Organizations, Users, and the API reference for the full model.

Empty roles in a sub-org?

If you created a sub-org and Roles (This Org) looks empty on your user profile, check Inherited from parent orgs. admin on the parent is enough—you do not need a second admin on every child.

Why learn organizations, users, and roles?

OpenApp is a security product: the core job is to let you decide which entity—a person, a group, or another actor—may access which resources, and to enforce that consistently. Organizations, users, and roles are the building blocks for that. They give you enough structure to stay flexible as your setup grows, stay ergonomic in the dashboard and API, and stay expressive enough that your access rules read clearly: you can form a solid mental model of who can do what, explain it to others, and maintain it as people and systems change. That vocabulary is there to help you reach your goals safely—it is not there to slow you down.

In this org your admin role is enough for every dashboard step that follows. Browsers use your normal login; programs need a separate credential—the next step creates an API key you will reuse for HTTP and SDK examples.

Roles grant; policies constrain

Roles decide what a user may do. Once you are managing real access, policies let owners layer limits on top of roles—invitation curfews, controls on who may share access, and owner-enforced limits on a shared physical device. Policies only ever restrict; they never widen what a role grants.

---

← Personal workspace · Create an API key →