Current User (Me)

me returns information about the account behind the current request. Use it to read identity details and to check what the current user is allowed to do before offering an action in your integration.

me is not a root query field — it lives under the user namespace:

query {
  user {
    me {
      permitted
      canCreateOrg
      hasOrganizations
      user {
        id
        name
        primaryEmail
      }
    }
  }
}

Fields

Field	Type	Description
permitted	Boolean!	Whether the account is allowed to use the application at all. false means the caller authenticated successfully but is not permitted access.
canCreateOrg	Boolean!	Whether the account may create a new organization right now. See below.
hasOrganizations	Boolean!	Whether the account belongs to at least one organization. Useful for hiding actions that require an organization to exist — creating a library, for example.
user	User	The caller's own user record, or null when no user record exists yet for the token.

Identity fields live on user, not on Me itself. Note that the User type exposes primaryEmail (a String!) and emails — there is no email field.

user is nullable by design. A token that authenticates successfully but has no corresponding Duro user yet — during first-time bootstrap, for example — returns user: null with the three booleans still populated. Always null-check it.

Checking whether a user can create an organization

Creating a new organization in Duro is gated: not every account is permitted to do so. Rather than attempting the mutation and handling a failure, query canCreateOrg first and use it to enable or hide a "New organization" affordance in your UI.

canCreateOrg: Boolean!

Returns true when the current user is allowed to create a new organization right now, and false otherwise.

In deployments where organization-creation gating is not enforced, the gate is a no-op and canCreateOrg is true for every authenticated caller. Do not read a true here as evidence that a grant exists.

Where gating is enforced, canCreateOrg is true for a non-archived caller who either:

• holds a live, unused organization-creation grant issued to their verified email address, or

• is the Site Admin of at least one active production organization, and so may create a sandbox organization beneath it.

It is false when neither holds — when the user has no grant, when their grant has already been used or was revoked, or when they administer no organization that can parent a sandbox. Those conditions surface as org-creation error codes if a create is attempted anyway.

{
  "data": {
    "user": {
      "me": {
        "permitted": true,
        "canCreateOrg": false,
        "hasOrganizations": true,
        "user": {
          "id": "b9f4b0f2-1c2a-4f7e-9a3c-2d5e8b1a7c40",
          "name": "Alex Rivera",
          "primaryEmail": "[e-mail]"
        }
      }
    }
  }
}

canCreateOrg reflects eligibility at the time of the query, and it deliberately skips the more expensive checks the create path performs. It does not verify that a prospective sandbox parent still has quota headroom, so it can report true when every organization you administer is already at its sandbox limit. Always treat the organization-creation mutation itself as the source of truth and handle its error codes — canCreateOrg is a hint for the UI, not a guarantee.