You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right you are. I'd like to better understand the way you use the library so we can implement this properly. I see a couple of ways subaccounts could be used:
During instantiation of the SparkPost class - setting subaccount there would make it cascade down through every call:
Any thoughts on which approach would best suit your use case? Is instantiating multiple instances of SparkPost, one per subaccount, something that could work, or do we need more granular control?
Hi,
for me would be better usage the second one. Specify account for each transmission.
In fact, the the first way can be done already. It's not exactly like defining subaccount for master account while init, but I can create two instances with API KEYs related only to subaccounts. That should give me chance to transmit like subaccounts I think, but it seems to me quite ugly way.
The second way seems to me more flexible.
Yeah all good points - thanks for the feedback @cisarpavel. I'm going to extract this in the base resource's request method and then pass through **kwargs to any calls to the self.request from the subclasses.
Activity
richleland commentedon May 23, 2017
Right you are. I'd like to better understand the way you use the library so we can implement this properly. I see a couple of ways subaccounts could be used:
SparkPostclass - setting subaccount there would make it cascade down through every call:sp.transmissions.send:Any thoughts on which approach would best suit your use case? Is instantiating multiple instances of
SparkPost, one per subaccount, something that could work, or do we need more granular control?cisarpavel commentedon May 24, 2017
Hi,
for me would be better usage the second one. Specify account for each transmission.
In fact, the the first way can be done already. It's not exactly like defining subaccount for master account while init, but I can create two instances with API KEYs related only to subaccounts. That should give me chance to transmit like subaccounts I think, but it seems to me quite ugly way.
The second way seems to me more flexible.
Thanks for your help.
richleland commentedon May 24, 2017
Yeah all good points - thanks for the feedback @cisarpavel. I'm going to extract this in the base resource's
requestmethod and then pass through**kwargsto any calls to theself.requestfrom the subclasses.nickperkins commentedon Jul 17, 2019
@jgzamora Preeeety sure this can be closed now