Authress API - billing, caching, and rate limiting

Go back to Authress API

The Authress api high level overview. Contains details on billing scenarios, response caching, and route rating limiting.

Creating and updating resources

There are different defaults and restrictions for each API route. Below is a list of them and their associated values.

• Billable - which means that they count towards the api call count.
• Rate Limiting - some routes are restricted to be called at a high frequency. They aren’t intended to be bulk utilized. What a rate limit is triggered for that route it will return the status code 429.
  • Tier 1: 1 call per minute - Expected to be used from Authress UIs only
  • Tier 2: 1 call per second - Administrative action should not be done transactionally
  • Tier 3: 100s per second - Infrequent use but meant for transactional usage.
  • Tier 4: Unlimited - build for full parity with the resource application service.
• Some routes are cached which can be inspected by their Cache-Control header found in the response.

In general these are free, and because they are not safe operations, there is no caching.

Route	Billable	Rate 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/claims		Tier 3
/v1/clients/{clientId}		Tier 2
/v1/clients/{clientId}/access-keys/{keyId}		Tier 3

Getting resources (safe & idempotent operations) can be cached

Route	Billable	Rate Limiting	Caching
/v1/users/{userId}/resources	$	Tier 4	600s
/v1/users/{userId}/resources/{resourceUri}/permissions	$	Tier 4	600s
/v1/users/{userId}/resources/{resourceUri}/permissions/{permission}	$	Tier 4	2XX - 24hr, 4XX - 300s
/v1/resources		Tier 1	600s
/v1/resources/{resourceUri}		Tier 2	-
/v1/resources/{resourceUri}/users	$	Tier 3	300s
/v1/records		Tier 1	600s
/v1/records/{recordId}		Tier 2	5s
/v1/roles		Tier 1	-
/v1/roles/{roleId}		Tier 2	-
/v1/clients		Tier 2	30s
/v1/clients/{clientId}		Tier 2	600s

Cost Estimates

• API calls: $0.0011 per call
• Access Records: $0.00011 per record (only as fallback)

Since most routes of Authress are free and an application is only billed for those that are marked as such above, we can break down the pricing estimates based on expected access patterns. In most cases, these scale proportional to the number of users an application has. Access records are free after the total calls threshold. For each record, 10x authorization requests are expected to be made. In the case these are made, all access records are free. In the case no authorization requests are made, the total access records will be used as the billing starting threshold. The greater of api calls or one-tenth the number of access records will be charged.

Authress usage falls onto the matrix of application access type and authorization caching. While there are other articles that talk about how to effectively cache based on your access type, we won’t discuss those concepts here, other than to acknowledge that they exist.

An application access’s type can be one or more of these possible types:

• Infrequent - Your users may only want to use your application a couple of times a month or year. Tax reporting or banking software are good examples.
• Frequent - Users range from uncommon frequency such as email, document repositories, and news sites to consistent access such as messaging or social platforms
• API - First-class services are built on top of your application interfaces.

It should be easy to see that each of these creates a step up in magnitude. On an orthogonal axis caching exists. By caching we mean repeated calls to Authress with similar or identical authorization patterns.

1. Does user X have permission Y to resource Z
2. Does user X have permission Y to resource Z
3. … (repeated)

For infrequent access type applications, repeated calls to Authress is encouraged, since caching is more complex, but for frequent or API integrations caching becomes an important opportunity.

Caching also can be broken down into multiple levels:

• Authress cache - API calls to Authress contain a cache control header which specifies how long the data will be cached in our edge locations. This allows for optimized performance.
• In-Memory Cache - On the application service side, the cache control headers can be used to short circuit calling Authress and instead use the data that is stored. While in-memory caches shouldn’t be that large, depending on the access patterns, you may see the same user making repeated requests in a short time period. One such example is editing a todo-list. Checking for “Create TODO” or “Edit TODO” may happen in quick succession. Here’s an implementation in NodeJS. (think MB size cache)
• Caching DB - For applications that scale up, in-memory caches start to become too large and cannot be shared among the many shards/instances of the application. To solve this a stared cache running in Redis or Memcached. (think GB size cache)

Understanding the application access patterns and implementing the right level caching are essential for determining overall Authress access. In general Authress aims for $0.26 per user per month. Because the billing plans are pay usage, for more infrequent access or users that aren’t as active, the actual amount should be a lower result. The actual usage would depend on the number of users and the amount of access.

For example for an infrequent access application which contains some sort of caching, at the standard Authress plan of $0.0011 per call, a user performing an action everyday for a month, could be as low as 1 call per day. That’s $0.033 per user. At a hundred users, the bill would be ~$3 total for the month.

That is extremely conservative, on the opposite side of the spectrum there are limited caching API applications that may see millions of API calls a day. Assuming each one of these is a new authorization attempt that could amount to $1000 per month for all users, although at that level, that would amount to hundreds of thousands of users. It all depends on the access patterns.

Going further

In-depth api documentation relevant to integrating with the API as well as the available SDKs can be found on the Authress Management Portal - API section.