Look at the public roadmap of almost any tool in this category and you will find the same line item: Gmail integration. Connect your inbox, we will watch it for you.
We are not going to build that — and it is not a resourcing decision. We looked at what it costs and decided the cheaper mechanism produces the same answer.
The short version
- Stria sees a client message only if you forward or CC it. There is no mailbox connection and no OAuth grant to revoke.
- Reading a Gmail inbox needs a Google restricted scope — OAuth verification plus an annual third-party security assessment.
- Forwarding produces the identical scope judgment with none of that risk, and a tool that cannot read your mailbox cannot leak it.
- Detection is on the free plan. Paying buys the one-click change order and volume — not permission to look.
The short answer: forwarding, not access
Stria only sees a client message if you forward it. There is no mailbox connection, no OAuth grant, and nothing to revoke — because nothing was ever granted.
You forward or CC one message to your workspace address. Stria checks it against the scope you locked, tells you whether the request falls outside it, and prices it against your rate card. Your client is not emailed, and the other 40,000 messages in your inbox are not involved, because Stria cannot reach them.
What reading a mailbox actually requires
This is the part that is usually skipped in a roadmap line item.
Reading message bodies through the Gmail API needs the gmail.readonly scope. Reading only headers
needs gmail.metadata. Google classifies both as restricted scopes, which triggers its heaviest
review path. Per Google’s own documentation, apps requesting restricted scopes must pass
OAuth app verification, and apps handling
restricted data through a third-party server must complete
an annual security assessment by a Google-approved assessor.
Read that again with the word annual in mind. It is not a launch hurdle you clear once. It is a recurring external dependency, on a third party’s calendar, for as long as the feature exists.
Google’s own guidance is to request the least access necessary and prefer non-sensitive alternatives where they exist. A forwarded message is the non-sensitive alternative. We took the advice.
The three costs a connector would impose
| Who pays | The cost |
|---|---|
| You, at the consent screen | Granting gmail.readonly to a young company hands over read access to every message in your mailbox — your accountant, your landlord, your doctor, other clients’ confidential briefs — to solve a problem about six emails a month. |
| Us, as a schedule dependency | An annual third-party assessment sits permanently between our roadmap and a working feature. We would be shipping on someone else’s cadence. |
| You again, if we were breached | A tool holding read access to thousands of freelancers’ entire mailboxes is a target with a blast radius far beyond its own data. The best way to protect data you do not need is to never hold it. |
That third row is the one that decided it.
What forwarding gives up
A post that only listed the upsides would be marketing rather than reasoning. Forwarding costs you two real things:
- You have to remember. A request you answer straight from your own inbox is never examined. The habit that works is forwarding anything that makes you hesitate — close to the set that matters, but a habit, and habits fail.
- There is no retroactive sweep. Stria cannot look back through last year’s mail for scope you absorbed, because it never had it. If your question is “what did I give away in 2025,” nothing here answers it.
Those are the costs. We think they are worth paying for a mechanism that needs no access to your mailbox at all. You may weigh it differently — and that is a fair thing to weigh.
What is identical either way
Here is what made the decision easy. From the moment the message text is available, the work is the same:
- Compare the request against the locked scope items for that project.
- Decide whether it refines what exists or undoes something agreed.
- Quote back the specific lines it was measured against.
- Price it against your rate card, showing the basis.
- Write an append-only determination and raise at most one alert for you.
Steps two through five do not care how step one’s text arrived. A connector would change the delivery mechanism and nothing downstream — another way of saying the restricted-scope review, the annual assessment, and the mailbox-wide grant would buy convenience, not capability.
How it works in practice
- Forward or CC. Each workspace gets its own mail address. Nothing to connect, no access to grant.
- You get a determination, not a nudge. Every forwarded message comes back with a verdict or the one setup step that would unlock one — usually a scope baseline that has not been locked yet.
- Nothing reaches your client. Examining a message produces a record for you and, at most, one alert. It never replies to anyone.
- Findings are append-only. A determination is written once. It is evidence, so it is not quietly rewritten later.
- Detection is on the free plan. The free tier includes AI scope classification with 3 clients and 6 deliverables a month. Paying for Stria buys the one-click change order and unlimited volume — not permission to look.
Why this is the more honest architecture
There is a version of this post that frames forwarding as a limitation we plan to remove. That would be dishonest, because we do not.
A tool that cannot read your mailbox cannot leak your mailbox, cannot be compelled to produce your mailbox, and cannot quietly widen what it looks at after you stop reading the changelog. Those are properties, not gaps. For a product whose whole promise is a record you can stand behind, holding as little as possible is the position that matches the pitch. (The record itself: what makes a client approval defensible.)
Frequently asked questions
Does Stria read my email? No. Stria has no connection to your mailbox and cannot open it. It only sees a message if you forward or CC that specific message to your workspace address. There is no OAuth grant to give and nothing to revoke, because no access was ever granted.
Why not just build a Gmail integration?
Reading message bodies needs gmail.readonly and metadata needs gmail.metadata — both restricted
scopes. Google requires apps requesting them to pass OAuth verification and undergo an annual
security assessment by a Google-approved third party. That is a recurring dependency on someone
else’s schedule, and it buys a result we can already produce from a forwarded message.
What does forwarding give up compared with a connector? Two real things: you have to remember to forward (a request handled entirely in your own inbox is never examined), and there is no retroactive sweep of last year’s mail, because Stria never had it. A connector would do both — at the cost of mailbox-wide access.
Does Stria ever email my client? Not from the scope check. A forwarded message produces a determination and, at most, one alert for you. Client-facing email in Stria only happens where you asked for it, such as a review link or an invoice you sent.
Scope detection without the mailbox grant
You can evaluate the whole idea the first time it catches something real — on the free plan, with no card and no inbox access.
Start free or open the live demo. Stria is live — free plan, no waitlist. Prefer the reasoning first? Start with scope creep is a records problem.
Google’s verification and assessment requirements are summarised from their published documentation, linked above, and were checked on 2026-08-09. Google changes these requirements; verify on their site before relying on this.