Gmail and OAuth connectors

Gmail does not hand out a key to paste. An admin signs in, and the service grants a token. Qaldy would keep that token where it keeps keys, sealed at the gate and write-only, and apps would never see it.

Where it stands#

• The catalog lists Gmail as Needs OAuth app. In the console the sign-in button is shown but cannot be used, and says why.
• Nothing pretends to sign in. A real workspace never gets a stand-in consent step; only the demo console, which runs on sample data, does.
• Google Sheets is not blocked by this. It works through a service account, which needs no sign-in and no OAuth app.
• Slack posts through an incoming webhook today. Slack's own OAuth sign-in (a bot token, reading channels) is not built.

What would change it#

An OAuth client has to be registered with the provider for the install, and the sign-in route, the token refresh at the gate and the redirect handling built. The gate already knows how to sign in as a Google service account, so a Gmail connection through a Workspace service account with domain-wide delegation is the likelier first route than a per-user sign-in. Neither is built.

Meanwhile#

To send email from an app use Resend or Postmark. To reach any other API use the HTTP API connector.