Sign up individual users and developers

[niwasystems]

I'm trying out Apigee on the 30 day trial to evaluate it's suitability for our purpose. One question I can't solve myself is how to handle our two types of customers. First there are developers, building apps and using our APIs with rate limits etc. That much I can do. But we also create apps that use those same APIs and I want those individual users to be able to sign up via a friendly portal and then be able to use our apps with that name and password. These are normal folk, not developers, so an API key is not suitable for them and they don't want to register their apps to work they the APIs.

I want them to be able to get 10 uses per day with the free plan, but buy a professional plan if they are doing more than that. The developers would be on a much higher limit (and much higher cost) and would manage their users however they see fit.

So, does Apigee cater to regular app users as well as app developers?

[mschreuder]

Hi @Craig Stanton, Welcome to Apigee community.

If I understand your use-case correctly, in the second scenario, you are making an app (or possibly multiple apps) available that individual users will be using? This app that you make essentially hides / simplifies using your API so that those individual users don't need to know all about APIs / REST to be able to experience using your APIs?

In that scenario, your app would still need to have it's own API key and your app logic & API would need to have a registration flow and a user authentication flow to validate the username & password for the individual users. If you don't already have this, you could use BaaS to provide you with a persistence layer for the user data and build that as a standalone Node.js app in Apigee or implement that in your API directly.

If I have understood that scenario then here is a suggestion for how to manage the individual user limits.

You implement your individual user app so that it provides a header or query param that identifies it as an individual user app in all of the API requests made via that individual user app. You then create a conditional flow in your API Proxy with the condition set to whatever you created as your header or query param value. That conditional flow is where you put the quota policy which you set up to have limit of 10 per day. In order that each individual user gets 10 per day, you would also need to set another header or query param in your individual user app with a unique userid for that user. You would use that unique userid as the countRef in your quota policy.

In this way, a developer would not hit that quota policy because they would not be providing that individual user header / query param and then each individual user gets their 10 requests per day when they quota policy executes based on their unique userid.

Hopefully that makes sense?

One other alternative, but it's not available in Apigee Trial, would be to use our Monetization feature. If that is something you are interested in learning more about, please contact us here.

If this has helped to answer your question, please click the Accept link below, alternatively let us know how we can further help.

[niwasystems]

I definitely intend to get the monetization feature up and running, so if you could explain the solution that involves that I'd appreciate it. I see a slight problem with your suggestion, though it may only be because of our planned implementation. Our apps would be Javascript based and they will hopefully call the API directly. If a user saw their id and our API key on that AJAX request, they could remove the userid and get unlimited calls right? We could make each app target their own domain and only send the users id on each call. Then have our own proxy on that host that takes the user's id and its own app key and talks server to server to get the results, but I don't want to add too many layers.

[mschreuder]

To guard against that you would need to have some extra metadata stored in Apigee that would enable you to know at run time whether the app was intended for individual users or developers. With that extra meta data you can bake the condition into the flow that if it's an individual user app it has to have a header else you return an error. I think the best way to do that would be by creating a custom app attribute that tags specific app/apps to indicate they are for individual users.

When you do the verify API key you would also need to get the custom app attributes. Then when you specify your flow conditions you would have:

Valid individual user: API Key resolved to app with custom app attribute set to "individual user" and header present -> PASS until quota policy hits 10 requests

Invalid individual user: API Key resolved to app with custom app attribute set to "individual user" and header not present -> FAIL immediately, return error.

Valid developer: API Key resolved to app with custom app attribute set to "developer" -> PASS.

Invalid api key: API Key resolution fails -> FAIL immediately, return error.

This won't eliminate all possible exploits though, for example if the individual user registration was not itself protected, then someone could write a script to sign up a new individual user, make 10 calls and then repeat; each time they're using a valid user. Things like captcha could help with minimizing risk there and, of course, you have to reach a balance between potentially turning away valid users because sign-up is too complex vs. enabling malicious users to manipulate the system.

[niwasystems]

That sounds good. It means still managing individual users externally to the API system right?

[mschreuder]

You do have a few options, one would be to implement user management using Apigee API BaaS. You can see a set of examples in the User Management section of that page.

If you already have a user management system then you could use that, either directly or, for example you could use Apigee Edge to create a login proxy and do token management via that / implement oauth flows, etc. There's a lot of flexibility to both fit in with what you already have, or provide you with a framework that you can implement your own solutions in.