Kinde’s main object delivery method is to include claims in ID and access tokens when a user authenticates. This is a very efficient delivery method because as soon as a user signs in, you have everything you need to give them access, including their permissions.

A minor downside of relying on claims, is that tokens go stale and data can get out of sync, and users may not be able to see the updates you make until they are issued a new token. This is the classic ‘eventual consistency’ problem.

If you make frequent updates to permissions, flags, or other objects, this is likely an issue for you and your users, and this topic will help. Here are some options.

You can use refresh tokens to extend the longevity of an access token. A refresh token is a way to request a new access token, without disrupting a session. Most of our SDKs handle refreshing tokens for you automatically.

For optimum performance our tokens are cached, so that when a new access token is issued it contains the same claims as the previous token.

A token cache becomes invalid, however, when user information is updated in the UI or via API. This includes updates to profile information, organization membership, roles, permissions, properties, and user-level feature flags.

So when you use a refresh token to renew the access token (and user info has been updated), the claims will also be updated.

One way to minimize periods of inconsistency is to set a low value for the access token lifetime, to trigger a refresh token.

There are events that do not trigger individual users tokens to be updated. These include:

• Feature flag changes at an organization or environment level that are inherited by a user
• Permissions added to a role that the user has

For these type of changes you can force a token update using your backend to call the Refresh User Claims endpoint of our Kinde management API. This invalidates the cache for a specific user and means the next time an access token is issued for that user the claims will reflect the current state in Kinde.

You can use the Kinde management API to keep your product in sync with Kinde. Calls to the API are always real time, meaning you have a few sync options.

Even if you are using refresh tokens (above), there might be a few sensitive areas of your application where immediate consistency is vital, for example checking a permission for a payments flow. To deal with this, you could make a call to out to the permissions API when that flow is triggered. This gives you the additional security of real time data where it counts.

Another option for syncing is to make an initial call to the API when your user logs in and store the claim information locally. Then, periodically poll the API to update your stored claim with a real-time response. This could be overkill for things that are not mission-critical, but might be useful for important areas like permissions.

As mentioned above, the Refresh User Claims API endpoint can be used to invalidate the cache for a user, which will ensure they receive updated claims on the next token refresh.

ℹ️ This is a beta feature. You need to request access.

Webhooks let you subscribe your own url endpoints to events, and receive updates as they occur. Events refer to activities that occur within your Kinde business, for example user creation, updates to users, etc.

When an event occurs, such as user.created, Kinde sends all the event data to any subscribed endpoints. You can then trigger your own application code in response, or just maintain your own copy of the event data.

Webhooks can be managed directly in the Kinde admin area, or by using the Kinde Management API Webhook endpoints.

Call the /api/v1/event_types endpoint in the Kinde Management API to view the full list of available events and the schema for the data you receive.

See the webhooks documentation for more information.