twilio/twilio-csharp

Trusthub related API methods should add the pathAccountSid parameter for subaccount calls like the rest of the SDK

mikequ-taggysoft opened this issue · 3 comments

mikequ-taggysoft commented

We use the DI pattern to inject pre-registered ITwilioRestClient for use with all Twilio API calls. Such clients are initiated with the master account Sid and credential.

When it comes to actual API calls, lots of actions need to be performed on subaccounts because we're an ISV. Various SDK methods such as those related to phone number operations have a pathAccountSid parameter which allows us to pass in the subaccount Sid at runtime to target specific subaccounts, without the needs to re-initiate new rest clients.

Now we're implementing the 10DLC starter brand registrations via API by following this guide:
https://www.twilio.com/docs/sms/a2p-10dlc/isv-starter-api#

Unfortunately, the Trusthub related methods are missing this pathAccountSid parameter. This means we cannot use the same injected ITwilioRestClient to make these calls and must create new ones.

It would be great if the parameter is added to make them in line with the rest of the SDK.

Examples of the key Trusthub APIs are:

PoliciesResource
CustomerProfilesResource
EndUserResource
SupportingDocumentResource
CustomerProfilesEntityAssignmentsResource
CustomerProfilesEvaluationsResource
TrustProductsResource
TrustProductsEntityAssignmentsResource
TrustProductsEvaluationsResource
BrandRegistrationResource
ServiceResource (this one is in Messaging)
UsAppToPersonResource (also in Messaging)

eshanholtz commented

Hi @mikequ-taggysoft, some API's have path account sid parameters as they were part of the original 2010 API design. Newer API endpoints do not take an account sid as a path parameter and there are no plans to introduce a path account sid to them in the future. The recommended approach would be to create new clients with the proper subaccount credentials configured.

mikequ-taggysoft commented

@eshanholtz Thanks for the clarification. In that case, the various Twilio documentations that mention how main API keys are supposed to be capable of managing subaccounts really should be updated to mention that they only apply to the old v2010 APIs.

So essentially, for the new APIs, to operate on subaccounts (and utilize IHttpClientFactory), we need to:

  1. Retrieve the subaccount auth token using the main account credential/client.

  2. Initialize a new TwilioRestClient and pass in the subaccount token and HttpClient (injected into the calling class via IHttpClientFactory)

For some reason, TwilioRestClient has read-only/non-exposed username/password properties. It would have been easier if these properties are settable so we can at least re-use the same instance by just assigning different credentials to it.

Out of curiosity, I wonder why Twilio decided to make subaccount management more cumbersome in the newer APIs (and in the process wasting an extra API call to retrieve the subaccount tokens every time, as it makes no sense to store those individually as an ISV), when the previous setup worked just fine?

shwetha-manvinkurke commented

Hi @mikequ-taggysoft We hear you. I am not exactly sure why it was designed that way but I do know we have internal tickets to improve this process for all the newer APIs but at the moment, there isn't a better way.

  • 👍1