Skip to main content

Billing, caching, and rate limiting

With Authress, you only ever pay for what you actually use. Unlike other providers, we won’t charge you the full month for users who only logged into your app once. The downside of this is a small bit of complexity when thinking about the API. Not every API route incurs charges. Some routes are rate limited.

API route overview

Below is a high level overview of routes and their respective billing, caching, and rate limiting strategies.

This is the official list of billable routes. Only routes marked as “billable” count towards your API call count. Routes not listed here are billable.

Some routes aren’t intended to be utilized in bulk and are therefore restricted in terms of call frequency. When a rate limit is triggered for such route, it returns the status code 429. There are 4 tiers of rate limiting in Authress:

  • Tier 1: 1 call per second - these routes are expected to be used from Authress UIs only
  • Tier 2: 10 calls per second - these are administrative actions and should not be done transactionally
  • Tier 3: ~100 calls per second - meant for transactional but infrequent usage
  • Tier 4: Unlimited - built for full parity with the resource application service

Creating and updating resources

These routes tend to be free. Because they aren’t REST-safe operations (PUT, POST, PATCH, DELETE).

RouteBillableRate Limiting
/v1/users/{userId}/tokens$Tier 3
/v1/users/{userId}/tokens/{tokenId}$Tier 3
/v1/resources/{resourceUri}Tier 2
/v1/records/{recordId}Tier 3
/v1/roles/{roleId}Tier 2
/v1/claimsTier 3
/v1/clients/{clientId}Tier 2
/v1/clients/{clientId}/access-keys/{keyId}Tier 3

Getting resources

RouteBillableRate Limiting
/v1/usersTier 2
/v1/users/{userId}Tier 3
/v1/users/{userId}/resources$Tier 4
/v1/users/{userId}/resources/{resourceUri}/permissions$Tier 4
/v1/users/{userId}/resources/{resourceUri}/permissions/{permission}$Tier 4
/v1/users/{userId}/resources/{resourceUri}/roles$Tier 4
/v1/resourcesTier 1
/v1/resources/{resourceUri}Tier 2
/v1/resources/{resourceUri}/users$Tier 3
/v1/recordsTier 1
/v1/records/{recordId}Tier 2
/v1/rolesTier 1
/v1/roles/{roleId}Tier 2
/v1/clientsTier 2
/v1/clients/{clientId}Tier 2
/v1/clients/{clientId}/.well-known/openid-configuration/✶$Tier 4
/v1/connectionsTier 2
/v1/connections/{connectionId}Tier 2
/v1/applicationsTier 1
/v1/applications/{applicationId}Tier 1

Public key verification

These routes may be utilized by Platform Extensions and Service Client authentication. These are highly cacheable and seldom change. They are billed to encourage the use of client side caching.

RouteBillableRate Limiting
/v1/clients/{clientId}/.well-known/openid-configuration/✶$Tier 4

Authentication routes

These routes are utilized by the Authress Login SDK and most of them are billable. They operate across regions and are highly reliable and scalable.

RouteBillableRate Limiting
/connections/{connectionId}/users/{userId}/credentials$Tier 4
/authentication$Tier 4
/authentication/✶$Tier 4
/authentication/oauth/tokens$Tier 4
/session$Tier 4
/.well-known/openid-configurationTier 3

Administrative Routes

These routes are exposed to make it easier to perform complex meta-management of your Authress account. In general they are billable. We recommend reaching out to us if you plan use them directly.

RouteBillableRate Limiting
/v1/accounts/{accountId}/usage$Tier 1
Authentication via user passwords

Due to the security risks associated with storing user passwords, the password based connection costs $0.011 per login request. All other authentication mechanisms are billed at the standard API rate associated with your account.

Response Caching

Caching is always a tradeoff. On one hand, you want your data to be as fresh as possible, on the other hand, you also want your functions to return as fast as possible. Usually you can’t have both. Cache times in Authress are carefully tuned with this tradeoff in mind. Authress provides suggested cache times on responses so that they can be used for optional caching on the client side.

Caching is difficult to get right and often means you need to pull in additional frameworks into your code. Fine tuning the balance between performance and data freshness takes time and experience. In case of User-Agent integrations (for example, an application UI running in your user’s browser), it is even more crucial, as the User-Agent is rarely under your control and yet demands fast response times. This is why we’ve opted to provide cache recommendations on the Authress side in many cases.

It doesn’t mean you can’t cache returned values for longer - if you’re making a lot of the same, low variability permission checks, you may want to build a cache on top of Authress to limit your costs. It is not strictly necessary though.