"Gmailify" alternative: Gmail API Import fails in live workflow but works in manual test
Status: Open · Asked by Yan K on · 0 views
(This is as an alternative to the deprecated Gmailify. For inbox emails I use the global forward anyway, so only spam remains)
Hello there,
Thanks for contacting us.
Could you please share the Workflow URL so that we can look into it and provide information accordingly?
Please be aware that to assist you effectively, we may need to access your Pabbly Connect account. If you're comfortable with this, please grant us permission by stating in your next email: "You have my permission to log into my Pabbly Connect account, and edit workflow {If required}. Here is the registered email address associated with it."
Thanks & Regards,
Adeel Akhtar
🌐 Pabbly.com
Hi, sure
workflow URL: https://connect.pabbly.com/v2/app/workflow/mapping/IjU3NjcwNTY5MDYzNTA0MzM1MjZjNTUzNDUxM2Ii_pc
You have my permission to log into my Pabbly Connect account, and edit workflow {If required}. Here is the registered email address associated with it - [email hidden]
Hello Yan,
Thank you for sharing the workflow URL, we checked the workflow and the task history. The action is failing because there are multiple From Headers in the MIME message before encoding. Gmail allows only single form Header. Unfortunately, the response is received from Outlook only, which we tried to fix by adding 3 actions in your worklfow and without hampering the original steps. Here we tried to split the MIME version to remove the multiple From Header. If these 3 actions execute in your test then its possible else due to Gmail's policy it won't be possible.

That error is happening because the raw MIME you’re pulling from Outlook via Graph API $value isn’t in the format Gmail expects. Outlook often includes multiple From: headers (for example, one in the envelope and another in the message body), but Gmail’s import endpoint requires exactly one From: header.
Why does Outlook return multiple From: headers
The
$valueendpoint gives you the full MIME stream as stored in Exchange/Outlook.Outlook sometimes duplicates headers (e.g.,
From:in the outer transport headers and again in the inner message).Gmail’s API is strict: it rejects anything that doesn’t look like a valid RFC 2822/5322 message with a single
From:.
Thanks & Regards,
Adeel Akhtar
🌐 Pabbly.com
Thank you!
I see you've added a new text formatter step.
So, I've ran this new workflow, and again as before: manual test worked fine, but live test failed in the Gmail step with the 400 error "Expected a single 'From' header".
Apparently the text formatter didn't provide a solution...
Perhaps you have any other suggestions on how I could achieve the function I'm looking for?
Just to clarify:
As I've mentioned unfortunately, the result is the same:
Manual "Save & Test Request" imports the email into Gmail successfully. The imported email is perfect, including the sender, subject, body, and attachments.
Live workflow execution still fails with:
Error Code: 400
Error Message: Expected a single 'From' header
The thing is - I'm not convinced that the issue is simply that Outlook returns multiple From: headers.
The main reason is that the same workflow succeeds during the manual test. If the MIME returned by Outlook were inherently invalid for Gmail, I would expect the manual test to fail as well.
In addition, during my own investigation I inspected the MIME returned by the Microsoft Graph $value endpoint and found only a single actual From: header. The other occurrences of the word "From" appear inside DKIM/ARC signature metadata (for example, h=From:Date:Subject...), which are part of signed header lists rather than additional message headers.
Because the manual test works while the live execution fails, it seems that something is behaving differently during the live execution path.
Could you please investigate what is different between the manual test and the live workflow execution on Pabbly's side? Since both executions use the same workflow and configuration, I would expect them to produce identical requests to Gmail.
If there is a limitation or known issue with processing raw MIME messages retrieved from the Microsoft Graph $value endpoint during live workflow execution, please let me know.
I'm happy to provide any additional information or allow further testing on my workflow if needed.
Thank you.
Hello Yan,
We fetched the last failed task in the Trigger response to check the manual execution, it seems the email has been deleted already, due to which is the second step failed to fetch the MIME type.
Can you fetch a new trigger response and also trigger the workflow again so that we can check the Trigger response in the workflow mapping and in the Task history as well?
Thanks & Regards,
Adeel Akhtar
🌐 Pabbly.com
Sure! it's done.
Hello Yan,
Thank you for your prompt response.
Please do not delete this email, which you just added as the Trigger response. We will use this for testing, so fetching of the MIME type is required on step 2, for which the email should exist. Further, after initial review, I've escalated the issue to the Technical Team. We will get back to you as soon as we hear from the Team. It may take up to 48 hours to get back to you.
Thanks & Regards,
Adeel Akhtar
🌐 Pabbly.com