Pricing built for every size business. No more hidden "enterprise" taxes, no more gating security behind a bigger bill. No credit card required to start.
A tenant is a grouping of users who have access to a common set of data, configurations, and security settings. Each tenant has its own unique set of data, configurations, and security settings, which are isolated from other tenants, but they share the underlying infrastructure and resources, such as the database and server. Typically for B2B applications, tenants are associated to organizations or companies using your application. In Wristband, multiple tenants can live under a single application, and multiple users can live under a single tenant.
B2B tenants (classified either as "standard" or "standalone" tenants) typically represent specific organizations, with a smaller, carefully managed group of users accessing your application on behalf of the organization. Consumer "global" tenants handle larger volumes of individual users accessing your app without organizational affiliation. Because of the differences in the amount of users they handle, the usage threshold limits differ accordingly. To learn more about the different types of tenants in Wristband, check out our documentation about tenant types.
A tenant is considered active when there is at least one active user within that tenant in a given month.
A user is considered active when they authenticate or perform a token refresh with Wristband at least once in a given month.
MAU overages are calculated on a per-tenant basis. For example, let's say you were on the Serious Business Plan where 100 users per tenant are included. Imagine there were two tenants: Tenant A and Tenant B. If Tenant A had 60 MAU's and Tenant B also had 60 MAU's, then the total of 120 MAU's does not count as going over the per-tenant limit. However, if Tenant A had 150 MAU's, then an overage is calculated for the 50 users who went past Tenant A's 100 user-per-tenant limit.
Tenants are logically isolated from each other. They exist in the same database instance, but data is isolated from each other using a tenant identifier discriminator column. In addition, each tenant has their own subdomain under the application's domain, and authenticated sessions are scoped to the tenant domain.
Wristband manages the association between users, roles, and permissions, but the actual authorization decision is handled by your application. Wristband is responsible for providing the roles and permissions of the authenticated user to your application, but your application is responsible for using those roles and permissions to enforce authorization.
Not exactly. We prioritized our hosted Onboard UI pages for our out-of-the-box offering. We also allow you to host your own UI by configuring "Custom Page URLs" that lets you take control of our workflows through API calls. As a result, we don't currently support an embedded widget, though it is possible we may add some widgets in the future.
Yes!Β You can checkout our list of currently supported auth SDKs. We are working on adding more SDK's for your development. We'll provide updates to our documentation as they get released.
For now, we work with our customers on a case-by-case basis, especially for those with a larger volume of data. If the data set is small enough, you can migrate data into Wristband by leveraging our APIs. For larger volumes of data, we typically create a script to help import your data. In the future, we aim to support a bulk user import and export APIs.
If something isn't working for you, we'll go above and beyond to make your experience with us better. That said, we understand that sometimes you may have different needs. In that event, you can use this export script to export your data as a CSV. If you have more complex needs, reach out to support and we will get you sorted.