twiliotwilio-apitwilio-conversations

How to handle auth-token and api-keys for dynamically created sub-accounts


In a different question, it was recommended that for ISVs, we create a new subaccount for each customer-organization. See: https://stackoverflow.com/a/73310624/4816322. This brought up a few more questions.

Assumption: I'm assuming that for APIs where an account-SID is required, we can no longer universally use the master-account-SID. We would need to use the subaccount-SID where the resource was or should be created.

Question 1: I'm assuming that for APIs where an API key needs to be provided, we can no longer use the master-account's API key? This means that whenever we dynamically create a subaccount, we would also need to dynamically create a new API-key for that subaccount, and then store that api-key's secret in our data store, and then dynamically retrieve it when needed to perform certain API operations. Same goes for the account auth-token as well. Is this accurate?

Question 2 (more important): Looking at the Java sample for this API:

Twilio.init(ACCOUNT_SID, AUTH_TOKEN);
User user = User.creator("RedgrenGrumbholdt").create();

As discussed earlier, I'm assuming that the accountSid and authToken need to be subaccount-specific. However, we have a single fleet of servers for all customers using different subaccounts. Each server runs a multi-threaded JVM to serve the requests. Imagine if there are 2 requests in parallel. The first request is using twilio-subAccount1, and the second request is using twilio-subaccount2. This means that the Twilio.init(ACCOUNT_SID, AUTH_TOKEN) invocations will overwrite one another, since they take effect for the entire JVM. Instead of creating 1 user in subaccount1 and the 2nd user in subaccount2, we may end up with both users being created in the same subaccount.

The only way I can think to avoid this problem is to serialize every single twilio API call, even if the JVM is designed to handle a large number of concurrent requests. Or to bypass the Java-SDK entirely and construct/parse the HTTP request/response myself.

Am I missing something here, or is it practically impossible to use the Java-SDK to concurrently manage multiple twilio subaccounts without severe performance limitations?

Edit: After digging a bit more, I'm seeing that we can build a custom TwilioRestClient, and use it to make the API calls. I'm assuming this is what the modified code should look like, to handle concurrent requests on multiple subaccounts?

var myClient = new TwilioRestClient.Builder(subaccountSid, subaccountAuthToken).build();
User user = User.creator("RedgrenGrumbholdt").create(myClient);

I'll leave this question up since I'm still unsure about the above, but please let me know if I've misunderstood anything or if there are any other suggestions


Solution

  • Question 1

    Yes, and there is an API to create API Keys given the Account Sid and Auth Token of a Subaccount.

    Question 2

    Yes, if you want to use different subaccounts, then the singleton version of the client won't work for you. That is the correct pattern for building a new, independent client object.