Strategies for setting up app(s)

[TCoreKevinJ]

These are a best strategies questions from a developer new to the Twitter API. We will be writing a service for that will send Tweets to our customers end users.

We will send Tweets for multiple Twitter accounts, CustomerEntity_A, CustomerEntity_B, CustomerEntity_C, etc. Their end users can elect to subscribe to one or many of those accounts. Do I need to create a separate app for each entity that can be subscribed to or a single app?

Will we need separate apps for each environment: development, in house test, on site test and production?

I have a developer account. I plan to create organization accounts later for test and production. Will I run into any issues waiting to do that?

[hmz]

Hi Kevin!

Thanks for visiting the forums. It sounds like you want to post Tweets on behalf of multiple customer’s Twitter accounts on your app.

To do this, you can create one app and use 3-legged-OAuth to verify and retrieve the correct tokens for your customer accounts and to post on their behalf.

Typically a developer will have a production app and a staging app. You can create an environment on this page for each app.

Applying for an organization account takes the same amount of time as applying for a personal account.

Please let me know if you have any more questions.

Hamza

[TCoreKevinJ]

I’ve been back looking at the online documentation. It seems to me that the 3-legged-OAuth authentication won’t work for my purposes. Because I will be Tweeting from a Windows service, I cannot prompt a user to Tweet on their behalf. It seems to me what I need to use is Single User OAuth authentication (https://developer.twitter.com/en/docs/basics/authentication/guides/single-user). Am I correct or have I missed something?

That leads me to a separate question. Our customer currently has 12 Twitter users that they used a third party (the now defunct TwitterCounter TwitterMail) to Tweet to. How will I migrate those to an organizational developer account? My assumption is that I will migrate each one into 12 separate organization developer accounts. That would add the benefit of each separate account having its own 300 Tweet per 3-hour period limit as opposed to all sharing one pool of 300. Am I correct in all of this?

[TCoreKevinJ]

Also now that I am testing a prototype, I don’t think that multiple apps (for separate entities to be followed independently) in the same developer account will work because the Tweets for all apps are posted from the same user.
So we will need multiple developer accounts ( CustomerEntity_A, CustomerEntity_B, CustomerEntity_C, etc) each with one app in it. Then the user can choose which one to many to following instead of getting everything.
If there is a different way to accomplish this that Twitter would prefer, please let me know.

[hmz]

You should be able to use 3-legged OAuth on their Windows system.

As for your assumption about creating multiple developer accounts, the only time you should do this is if the different @handles are owned by different companies. The best practices are to have a single org account for each company.

If all of these @handles are owned by a single client, then they should have a single org developer account. Within that org developer account, they should have a single Twitter app per use case.

One use case could be… Tweet from our company’s handles. In this case, you would just need a single Twitter app and use 3-legged OAuth to authorize that single app to post on behalf of all of the company’s @handles.

[TCoreKevinJ]

I don’t follow how that could work for our needs.
Twitter’s documentation (https://developer.twitter.com/en/docs/basics/authentication/overview/3-legged-oauth) says that, “The user will always be prompted to authorize access to your application”.

A design that requires any user interaction to authorize Tweets will not work for us. Is that statement in the documentation wrong? Should we be looking at two-legged authentication or another solution?

[andypiper]

I think there is some confusion here and we can definitely clarify in the documentation.

Three-legged OAuth and Sign-in with Twitter are essentially the same thing - the user goes through a sign-in process on Twitter, your app is returned a user token and secret, and can perform actions on behalf of the user. The statement you’re catching in the docs is highlighting a difference between the authorize and authenticate calls - there is no need for you to call the endpoint that forces a new sign in process every time once you obtained the tokens. That’s not very well described.

I would recommend the following.:

• single app owned by your company (you should definitely NOT be registering and creating developer accounts and apps “on behalf of” your clients)
• users sign in with Twitter, and you obtain their tokens
• your app performs actions on behalf of those users via their tokens and permissions.

It is fine if you’re implementing this as a Windows service (though wow, it has been about 15 years since I wrote one myself…!) but you’ll need to implement a UI for that initial auth stage, then securely squirrel and cache the tokens for future use.

In terms of all of the other functionality you’ve described, I would highly recommend that you closely study the automation rules and developer policy. We cannot get into debates about whether individual apps meet the rules, just from the sheer scale perspective. Thank you.

[TCoreKevinJ]

Thanks, that makes sense.
One question though, once I retrieve the user tokens using the sign in button, can I use them indefinitely or do they ever get regenerated? It sounds like they are permanent but I want to verify.

Hopefully, they don’t get regenerated since our service will be hands off once those retrieved tokens are encrypted and saved.
If they are regenerated, are there steps we can take to rectify that before our service starts receiving post errors from Twitter?

[andypiper]

If the user revokes the app in their account settings then you’d see an error. You also have the option to use the invalidate token endpoint to invalidate them yourself. Both cases seem unlikely given the use case you’ve described. Clearly, if a user has a solid reason for revoking your app access to their account, then you should expect an error and to implement remediatory actions.

[system]

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.