How to use API keys for multiple instances of an intranet application

[bjartn]

We sell an intranet portal that our customers are installing in their datacenter, so each customer has a separate installation.

In the portal the users can subscribe to a specific Twitter “search”. We use the Twitter Streaming API to retrieve results for the search continuously.

What is the correct way to register an application and use API keys for this use case?

Do we register one application, and use one API key per customer? If so, how can we make sure we don’t run out of API keys.

Is there a recommended model for our situation?

[LeBraat]

This is a great question.

You should only have one developer account per organization. I recommend that you apply for an ‘organization’ account as opposed to an ‘individual’ account.

Once you have that developer account set up, you will be able to set up different Twitter apps. You should have one Twitter app per use case.

In your situation, you should probably just have a single Twitter app. Then, you will use the 3-legged oauth process to authorize your application to make requests to the statuses/filter endpoint. You can authorize your app to make requests on behalf of as many users as you’d like.

So at the end of the day…
You should have one developer account that manages all of your Twitter apps.
You should have one Twitter app per use case.
You should then authorize your Twitter app to make requests on behalf of your users.

[bjartn]

Thanks for useful feedback.

I have one thing that I would like to have clarified.

Are you saying that every user of our app need to log in to Twitter, so that our app can access Twitter on their behalf? Or, can we do the searches with our own tokens? And if so, how do we avoid running out of tokens? (We cannot create more tokens right now)

One challenge is that we have some Twitter searches that are shared across users, so the search should ideally belong to the app, and not a specific Twitter user.

[LeBraat]

You can have a single connection with multiple parameters per user that you are authorized to make requests on behalf of.

Based on what little I know about your use case, I think you are going to have to authorize each of your users to be able to establish different streams with different sets of parameters. Each user that you authorize will provide you a new set of access tokens that you will use in your request. You can use a single set of access tokens to open up a stream that could be used for multiple users.