Permissions given with Gmail API
-
Hello,
I set up a site with the Gmail API and provided a Client ID and Client Secret.
Everything works fine, but when checking the permissions given to Post SMTP to my Gmail account, I read the following:
“Post SMTP can read, compose, send and permanently delete all your email from Gmail.
This app wants permission to do anything you can do in your Gmail, including:
Read your emails
Compose new emails
Add new emails meant for a different email address into your inbox
Send emails for you
Delete your email
Create, change or delete your email labels
Get notified when certain kinds of emails appear in your Gmail inbox, like a travel confirmation
Your email may contain sensitive info, like names of your contacts, your private communications, or financial or medical information.”Can you please clarify what this means precisely and what it implies in terms of security?
Thanks.
-
Hello @dsl225 ,
Thank you for reaching out.
Could you please let us know when the Gmail API configuration was completed and which version of the Post SMTP plugin you are currently using?
The permissions you shared were required in earlier configurations of the Gmail API integration. However, as part of our continued efforts to improve privacy and security, the permissions requested by Post SMTP have been reduced in newer implementations.
The current permissions are limited to:
These permissions are sufficient for the plugin to authenticate and send emails from your WordPress site without requesting broader access to your mailbox.
Once we have the information about when the setup was done and the plugin version, we can better determine why the older permission scope is still being displayed and guide you accordingly.
Thanks for your feedback but I really don’t remember when the plugin was installed at this site with their API and a couple of other sites. Probably something like 2-3 years ago.
All sites are using your latest version.
Even if you changed those permissions recently to be more restrictive, Gmail still gives this message in my account and probably at other accounts also but I didn’t check. I think only a single other one is using the API with another Gmail account but I’ll check further once I get your reply. Thanks.Hi,
Thank you for getting back.
You can remove the existing permissions from your Google account and then reauthorize Post SMTP. This will ensure that the plugin is granted updated and appropriate permissions.
Additionally, could you please confirm which version of the plugin you are currently using? This will help us better understand your setup and assist you more effectively.
As I said before: I’m using your latest versions.
Please let me know how to proceed, thanks.Please follow the steps below to remove existing permissions and reauthorize Post SMTP with your Google account:
- Go to myaccount.google.com → Third-party apps & services.
- Search for Post SMTP and click on it.
- At the bottom, click on “Delete all connections you have with Post SMTP” and confirm.
- This will remove all previously granted permissions and temporarily stop emails from being sent from your site.
After that, please proceed with reauthorization:
- Navigate to WordPress Dashboard → Post SMTP.
- Click on Relaunch Wizard.
- Select Gmail API (Gmail Socket).
- Complete the authorization process again.
This should refresh the connection and resolve any permission-related issues.
Thanks, well noted.
May I use the same codes for the API’s Client ID and Client Secret?Yes you can use those keys.
One more question:
– Is it possible that 2 different sites are using the same Gmail account but with different Client ID and Client Secret codes?
I successfully updated the first site but I can’t find the email used for the second one and it looks like it uses the same Gmail account because I can’t re-authorize it.
In fact I’m getting this error:
Access blocked: This app’s request is invalid
Error 400: redirect_uri_mismatch
So, I didn’t reset the setup and left it as it was and still works fine.
It looks like it’s the same Gmail account. Is it possible to find out which Gmail account is used at this second site and then change this Gmail account to another one when relaunching the wizard?This is just for avoiding confusion. Both sites still work fine.
– In fact not exactly: the second site sends the test emails correctly but I just see they are not logged in the plugin’s email log. Also, contact messages and auto-replies are sent and received fine but ogged twice – one failed and another succeeded for the same message. Looks like the API is not working at all and the plugin is using the fallback settings.UPDATE:
Decided to create a new Gmail Project for the second site and followed your guide.
Used both new Client ID and Client Secret codes but I’m still unable to authorize Gmail.
When trying to authorize Gmail, I’m now getting this error:example.com has not completed the Google verification process. The app is currently being tested, and can only be accessed by developer-approved testers. If you think you should have access, contact the developer.
If you are a developer of example.com, see error details
Error 403: access_denied
Request details: access_type=offline login_hint=contact@example.com scope=https://www.googleapis.com/auth/gmail.send response_type=code redirect_uri=https://example.com/wp-admin/options-general.php?page=postman state=4daa4cc426e7a2eae7937bef2a463ea6 prompt=consent flowName=GeneralOAuthFlow client_id=549615951661-35vg3ptob0kos7senc62km7ocgnt52c0.apps.googleusercontent.com
Hi,
To resolve the Error 403: access_denied, please ensure the following:
- The same email address used to create the API in the Google Cloud Console is also used when configuring Post SMTP.
- In Google Cloud Console> OAuth Consent Screen> Audience, make sure:
- The Publishing Status is set to Production (not Testing).
- The User Type is set to External.
These settings are essential to ensure proper authorization and smooth functionality.
Please make the above adjustments and let me know how it goes.
Thanks but I’ll give up. The whole thing is extremely confusing and time-wasting.
SMTP works fine.
Are there any advantages, especially related to reliability, for using the API instead of SMTP?Hi @dsl225 ,
I completely understand where you’re coming from, it can definitely feel overwhelming, especially when things don’t work as expected. Thanks for your patience so far.
To answer your question:
While SMTP works well in many cases, using an API-based integration does offer some advantages, particularly around reliability and performance:
- Better deliverability: APIs communicate directly with the email service, reducing chances of rejection or delays
- Faster sending: No SMTP handshake required, so emails are processed more efficiently
- Improved error handling: APIs return clearer, more detailed responses
- No dependency on SMTP authentication limits (which providers like Microsoft 365 are tightening)
That said, if your current SMTP setup is working reliably for your needs, it’s perfectly fine to continue using it. We’re here to help
If you’re open to it, you can also create a ticket through our official website, and we’ll do our best to assist you in real-time and simplify the setup for you.
No pressure at all, just wanted to give you a clear picture so you can choose what works best for you.
Many thanks for your feedback. Well noted.
In the meanwhile I managed to make it work with the help of a friend as I became totally allergic at those abyssal interfaces like GCC or Meta’s Business pages that have no structural logic anymore after years of adding “features” here and there, ending up having more submenus than stars in the sky.
So yes, the issue was that the Publishing Status was set to Testing by default and had to switch to production.
That’s fine, but I now have another question: why don’t you mention this in your guide here?
https://postmansmtp.com/how-to-configure-post-smtp-with-gmailgsuite-using-oauth/
as it seems that many people get stuck precisely at this point? At least, I wasn’t able to find something related.
You must be logged in to reply to this topic.