Skip to main content

​
Dashboard accounts and email addresses

The Turnkey dashboard uses your email address to look up your organization and registered credentials. You cannot create a second dashboard account with the same email address. For a separate test organization, use a different address or an email alias supported by your email provider, such as firstname+test@domain.com. This dashboard signup restriction is separate from how you organize end users in sub-organizations.

​
Test and production organizations

Use a dedicated test organization to experiment with the API, credentials, and policies, and a separate organization for production. Keep the organization IDs and credentials for each environment distinct, and check which organization your integration targets before submitting requests. See the production checklist before going live. If you need many test organizations, contact Support.

​
Data deletion

To request deletion of your parent organization from Turnkey’s records, email privacy@turnkey.com. See the Privacy Policy for how personal information is handled and retained. Sub-organization deletion is a separate API operation. See Delete sub-organization and backup and recovery when designing an end-user export and deletion flow.

​
Root quorum

All organizations are controlled by a Root Quorum which contains the root users and the required threshold of approvals to take any action. Only the root quorum can update the root quorum or feature set.

​
Features

Organization features are Turnkey product offerings that organizations can opt-in to or opt-out of. Note that these features can be set and updated using the activities ACTIVITY_TYPE_SET_ORGANIZATION_FEATURE and ACTIVITY_TYPE_REMOVE_ORGANIZATION_FEATURE. The following is a list of such features:

​
Permissions

All activity requests are subject to enforcement by Turnkey’s policy engine. The policy engine determines if a request is allowed by checking the following:
  • Does this request violate our feature set?
    • Email auth cannot be initiated if disabled
  • Should this request be denied by default?
    • All import requests must target your own user
  • Does this request meet the root quorum threshold?
  • What is the outcome of evaluating this request against all organization policies? Outcomes include:
    • OUTCOME_ALLOW: the request is allowed to process
    • OUTCOME_REQUIRES_CONSENSUS: the request needs additional approvals
    • OUTCOME_REJECTED: the request should be rejected
    • OUTCOME_DENY_EXPLICIT: the request has been explicitly denied via policies
    • OUTCOME_DENY_IMPLICIT: the request has been implicitly denied as no policies grant the required permissions
  • Should this request be allowed by default?
    • Users can manage their own credentials unless policies explicitly deny this

​
Resource limits

Organizations have resource limits for performance and security considerations. If you’re bumping into these limits, check out sub-organizations below.

​
Sub-organizations

A sub-organization is an isolated organization that has a pointer to a parent organization. The parent organization has read access to all sub-organizations, but no write access. This means users within the parent organization have no ability to use wallets or alter any resources in the sub-organization. For more information on sub-organizations and common use cases for this functionality, follow along in the next section.