Add the ability to impersonate a subuser

[thinkingserious]

Please see the Python implementation for an example.

[Jericho]

@thinkingserious the documentation says:

To use the feature, add the on-behalf-of header:
on-behalf-of: subuser_<username>

I notice that subuser_ is outside the angle brackets. Is that a typo or is it intentional?

In other words, if I want to impersonate a user called "bob", do I need on-behalf-of: subuser_bob or on-behalf-of: bob?

[Jericho]

@thinkingserious One more question regarding impersonation: the documentation clearly says that the on-behalf-of header does not work with the mail.send API, but I also found a few resources, such as batches, campaigns, teammates, etc. (see below for complete list), where this header is not documented. Is that just an oversight in the documentation or does it mean they don't support impersonation?

Here's the list of endpoints where the documentation omits the on-behalf-of header:

• Batches
• Campaigns
• IP Addresses
• IP Pools
• Mail send
• Partner Settings
• Subusers
• Teammates

[mbernier]

It is my understanding that the on behalf of should be available on all v3 endpoints except mail/send

[mbernier]

Now, having said that, these one's don't have support:

• Subusers can't have subusers
• Subusers can't manage their own IPs

The other items listed support On-Behalf-of

[mbernier]

@ksigler7 @Whatthefoxsays for visibility on possible docs update (see @Jericho's message 3 up from this one)

[Jericho]

@mbernier if subusers can't manage their IPs (which explains why the on-behalf-of header is not supported in the IP Addresses and the IP Pools endpoints), why are they allowed to add/remove an IP to/from warmup? IMHO that's not consistent.

[apigirl]

thanks @mbernier - should be updated now

[Jericho]

@ksigler7 can you let us know what was updated?

[apigirl]

@Jericho - I updated this API documentation to include on-behalf-of:

• Batches
• Campaigns
• Partner Settings
• Subusers
• Teammates

[apigirl]

@Jericho - I also removed it from the IP warmup stuff. Thanks for pointing that out! on-behalf-of was the very first update I made to the API docs after I joined the company, and I had no idea what I was doing :)

[Jericho]

Thanks @ksigler7. I see the changes in the documentation for batches, campaigns, partner settings and IP warmup but I don't notice anything different in the doc for subusers and teammates. These two sections did not mention the on-behalf-of header and, as far as I can tell, they still don't. Anyway, based on the explanation @mbernier gave me a few days ago, I understand these two endpoints are not supposed to support impersonation so I was not expecting any changes.

[Jericho]

@ksigler7 also, I think my original question was overlooked. Is that something you can look into?

[apigirl]

@Jericho to answer your original question, it should be on-behalf-of: subuser_bob

[Jericho]

@mbernier Feature request: would SendGrid be open to the idea of enhancing Mail.Send so we can impersonate a subuser when sending emails?

If not, is there a workaround that ensures emails are associated with the desired subuser (and count against their monthly quota)?

[Jericho]

@mbernier Just following up on my suggestion from a few months ago. Do you think SendGrid would consider adding the ability to impersonate when sending an email?

[Jericho]

@thinkingserious can you check with @mbernier if he can comment on my feature request?

[thinkingserious]

@Jericho,

@mbernier is no longer with SendGrid.

I will put in a new feedback request to our product team requesting this feature today.

With Best Regards,

Elmer

[thinkingserious]

@Jericho,

In the feedback form, there a section for the business use case. Could you please elaborate on that for me?

Thanks!

Elmer

[Jericho]

The use case is: being able to send transactional emails (and bulk emails as well) on behalf of another account (which is called a "subuser" in SendGrid's lingo) and ensure these emails are counted against that other account's monthly quota as opposed to being calculated against my monthly quota. I had a long in depth discussion with Devin Chasanoff on this topic back in November last year and also discussed it with Matt Bernier in March 2016. Every time I bring it up I'm told this is a well known feature request that should be looked at and eventually implemented. I'm just trying to formally request this feature.

[thinkingserious]

Perfect, thanks!

[ilFusta]

Hello,
Any news about this?

[thinkingserious]

Hello @ilFusta,

I don't have any news on this feature yet, but due to your request I have asked for an update and will respond here when I learn more. Thanks for reaching out!

With Best Regards,

Elmer

[thinkingserious]

Hello @Jericho @ilFusta,

I've done some investigation and found that our current stance is that it's preferable to use API Keys for this purpose since each key's permissions can be fine-tuned. Is there a use case where that would not work for you?

With Best Regards,

Elmer

[ilFusta]

Thanks @thinkingserious

It's ok for me, it just need some more configuration to setup different api keys, but actually you are right, it's more secure and can be better tuned.

Thank you.

[Jericho]

I'm curious why SendGrid went to the trouble of allowing us to execute several API calls 'on behalf of', but not this one. If the logic is that it's more secure, then why is it not more secure for the other calls? I just don't understand the lack of consistency.

[thinkingserious]

HI @Jericho,

I believe those other calls were implemented as one-off requests for specific use cases.

My guess is that the mail/send endpoint probably warrants additional security considerations and implementing this feature on that endpoint is not as high of priority vs the rest of the items on our backlog.

With Best Regards,

Elmer

[brettpostin]

@thinkingserious the docs state there is a 100 limit on api keys, is that in total for the parent account?

If so, how can we send on behalf of subusers if we have more than 100 subusers?

Edit: After speaking with SendGrid the limit is per account, so each subuser has it's own 100 limit.

[jkerrwilson]

Has there been any update on this type of feature? Is there anyway to perform requests on behalf of a sub user, or even to simply set headers on a RequestAsync API call?

[brettpostin]

@jkerrwilson you can set the request headers in the SendGridClient constructor. I recently had to do this to set the "on-behalf-of" header.

[childish-sambino]

Closing this issue out as the request to support the on-behalf-of header for mail-send is not something that can be addressed by this library. The header is currently supported for many other APIs with docs and support in this library. We will circle back if there's any update.

Note that backend product teams do not use GitHub to track feature requests. Best to contact support in order to help push the request.