We have an old integration between our CRM app (Sugar) with Twitter where you can display a personal or corporate twitter feed in the context of customer record within Sugar. In order to enable this integration, the Sugar Admin had to get an API key from Twitter. We have been told this isn’t allowed so we need to migrate to using a single key.
What’s the expected architecture to handle on-premise or multi-instance integration deployments in a way that protects a premium or enterprise API key? Each Sugar instance has it’s own URL, so I’m not sure how we’re expected to configure the callback URL for a single key that would work when authentication requests could come from any number of different URLs?
Has anybody migrated multiple instances with multiple API keys to a single key before? I’m looking for some advice here. We don’t want this integration shut down.
yoyoel
#2
Hi! Thanks for your question.
Our policies regarding the use of multiple API keys are intended to prevent the abuse of Twitter’s platform and services to circumvent rate limits. You can learn more about these rules at https://t.co/multikey and https://t.co/restricteduses.
In the case of on-prem/multi-instance software, we recognize that technical constraints (such as callback URLs) may inform the specific implementation you develop. However, the intent behind our policies remains the same: While your specific use case may require the use of multiple applications, you should take steps to ensure that they are centrally managed, and, in the case of our Premium/Enterprise APIs, are centrally billed. Whether a solution is on-prem or hosted, the use of multiple applications (including “whitelabeled” versions of a product) to attempt to circumvent rate limits or avoid the need to obtain Premium or Enterprise access, is prohibited.
The best approach in these cases is to use a single Developer account to register applications on behalf of your end users. For example, if Widgets Inc develops a product used by customers A and B, Widgets would need to register for a developer account and then register applications for each of customers A and B (under the central Widgets developer account). If you’re an Enterprise customer, your Enterprise account manager can work with you on implementing this correctly for products like the Account Activity API.
To be clear: Registering applications per-customer is only appropriate in instances where customers need access to products like the Account Activity API which provide authenticated, per-user information. It would not be permissible to register applications in order to, for example, provide search or analytics services (which should all be managed centrally using a single application).
1 Like
Thanks Yoel for the detailed response.
It seems that we will have to deploy some sort of connected service as a proxy for our customer instances. We’ll also need to develop the modifications to the existing code that will need to be released. It’ll take more than 30 days to design, develop, and deliver the new improved solution as a production service in our cloud and upgrade the end customer instances. It may be unavoidable that we’ll have to shut this integration off for some time. In the mean time, we’re disabling this integration in our free trial environment.
system
closed
#4
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.