We’d like to provide a “pay as you go” (PAYG) plan to our customers, as well as a “pay monthly” plan. We expect some customers to start with PAYG and move to a monthly plan instead, but we’d like them to be able to keep their remaining PAYG quota when upgrading.
For example, the customer buys a PAYG plan with 300 calls to our API (non-expiring and non-renewing), so we add a security policy (or just add the quota directly to their API key) with a quota of 300.
The customer uses 150 of their API calls, then upgrades to the “pay monthly” plan which provides them 1000 calls per month. We then apply a the “pay monthly” policy to their API key and potentially remove the PAYG one. If you keep both policies, they are not “additive” so the quota is just overridden by (I believe) the last policy in the “apply_policies” list and where they should have 1150 quota remaining, they only have 1000.
What are the ways to approach this, without blocking the user from signing up to a monthly plan when they’ve got PAYG quota remaining?
Thanks
PS. Is there “a way” to easily add quota to an individual API key using the Tyk Gateway API? I’ve used the PUT /tyk/keys/{key_id} endpoint but you’re not able to atomically update individual fields in the “access_rights” and “limit” objects (you’d have to do a GET and then a PUT,) for example.
PPS. I’m just using open-source Tyk Gateway, not Dashboard.
The customer uses 150 of their API calls, then upgrades to the “pay monthly” plan which provides them 1000 calls per month. We then apply a the “pay monthly” policy to their API key and potentially remove the PAYG one. If you keep both policies, they are not “additive” so the quota is just overridden by (I believe) the last policy in the “apply_policies” list and where they should have 1150 quota remaining, they only have 1000.
There isn’t an automated way to do this via an API. It would be necessary to alter the existing policy to be auto renewing and give it 1150 for the first period, then alter it again at the end of that period to have only 1000.
PS. Is there “a way” to easily add quota to an individual API key using the Tyk Gateway API? I’ve used the PUT /tyk/keys/{key_id} endpoint but you’re not able to atomically update individual fields in the “access_rights” and “limit” objects (you’d have to do a GET and then a PUT,) for example.
This is what must be done. The api key is stored as a string in redis so it must be retrieved updated and written back. The APIs reflect that need.
Since we’re discussing keys I’d like to mention the need to think about tidying up expired keys. It is something that should be thought about early to avoid redis growing beyond expectations.
Thanks for your response. Now that I know what’s (not) available I can account for this in other ways.
Presumably, when a client makes an API call and the quota is therefore reduced by 1, Tyk acquires some kind of lock, retrieves the API key, reduces its quota, writes it back and releases the lock? Or is there some mechanism to make use of a Redis DECR command and reconcile the key data later?
I suspect the internal usage of Redis is not considered to be a public API, so manipulating it from outside of Tyk is not something to be condoned?
I’m just exploring my options here, with the fallback of just living with potentially giving out more quota than intended (if a client makes an API request between me retrieving and writing back a key with a modified quota value).
Redis is used under some conditions but it’s a slow way track the rate of API consumption. For higher rates the distributed rate limiter comes into operation which manages rates using in memory data structures rather than via redis.
This does lead to the possibility of slight inaccuracies between nodes.