REST API Send Email — From User Id (Setting From Name)

When sending an email broadcast the Infusionsoft admin UI allows you to select the user / email that the broadcast will be sent FROM — as well as the ‘Display Name’ that will be visible in the receiving user’s mail box.

The issue is that when I am sending from the REST API via a POST (Keap REST API) I can’t figure out how to set the ‘From’ display name.

I can get the email to send but the ‘from’ name always ends up as the first name / predicate / portion of the email address that preceeds the @ symbol.

My question is: is it possible to to set the ‘From’ attribute to some value other than the email address of the user who is ‘sending’ the email via REST API?

If not — can this be done from the xml-rpc API?

The “from” field can only be a user’s email in the application, which is a safeguard to prevent spoofed spam emails from being sent. This is specified by the user_id field, as stated in that documentation page’s Body Schema:

user_id - integer - The infusionsoft user to send the email on behalf of

Hey Tom,
Thanks — that’s what I have been doing, the email sends correctly.

The issue is that there is no ‘FROM’ header set in the emails that are sent from the API. Ie. it doesn’t use my Infusionsoft User’s First / Last Name — and therefore can’t be modified (by for instance updating that name).

I spoke to infusionsoft support and they indicated that using the InfusionSoft user’s first / last name SHOULD be the intended behavior — I am wondering if this is the result that you get when sending emails from the API (ie. the receiver sees it as FROM your user’s name — rather than just the email address associated with that user).

When receiving the email in an inbox (Gmail for example) It looks incredibly spammy to be ‘FROM’ my email address — and even worse (depending on provider) a lower case version of my first name: ‘scott’ (which is generated by certain providers when no FROM header name is provided — by splitting the address at the @ symbol)

As of right now my only option (since I have no ability to correct this on my side) is to use a different provider to send all emails that require any sort of programatic logic to create their content. Long term that isn’t sustainable so I am hoping this is just a bug on my account specifically!

Hi @Scott_Imbrie, it appears that this is a bug in our endpoint. I will add a bug ticket to our system so that we can get it fixed. Thanks for bringing it to our attention.

Hey thanks Nicholas!
That’s actually great news.
I was kind of worried there was no way to solve the issue — since in many cases it’s not necessarily appropriate for our API integration to send mail from Me specifically as the user.

At least this allows me to rename my user to match the Company name — thereby enabling the majority of our sending.

I suppose I could also add another user (no idea how much that costs — tried and system said I was out of users) in order to be able to send from myself AND from the company when using the API.

Again not totally sure that this is the intended structure for solving the multi-user sending problem — and trying to do it by the book — but would love feedback if you have it.

Is there a place to track bug progress for the issue?

I have to roll out an MVP that requires the functionality prior to the Christmas holiday and would love to be informed — so as to make better decisions on whether to use MailGun as a temporary solution on some of our emails while waiting on a fix.

Alternately if you have feedback on how soon that fix might come that would certainly do instead! Thanks again for the timely support!

If you would like to track the progress of the bug I would suggest that you create a support ticket for the issue here. This will allow you to receive updates as it progresses through the process. I don’t have a concrete estimate for when the issue will be resolved but my guess would be 4-6 weeks.

I don’t know too much about email sending best practices but I think renaming your user to match the company name is probably your best bet.

All sounds good.
Ticket created — I will post back with resolution details if value-able to anyone who runs into the problem in the future.