The Per-Service OAuth Problem
If you've ever set up a productivity app that needed to touch your calendar and your email and your files, you know the drill. Three OAuth consent screens. Three pop-ups. Three copies of the same permission prompt, one for each service. And if you ever disconnected one, the others kept humming along in a state that didn't quite match what you thought you'd approved.
hiroi had this problem too. The original design carried a separate ServiceConnection row for calendar, for email, and for files. Each was authorized independently. Each could drift out of sync. Users saw three identical "Connect Google" buttons and wondered — reasonably — why they had to click all three.
As of this week, that's gone. One login per provider. One token store. Every service your agent needs, connected in a single step.
What Changed
Under the hood, ServiceConnection has been replaced with a new primitive called IntegrationAccount. There is exactly one IntegrationAccount per user per provider. Microsoft is one row. Google is one row. That row carries every scope your assistant has been granted — calendar read/write, mail read, mail send, files, whatever — and every service that needs those scopes reads from the same place.
From the user's perspective, the flow is dead simple:
- Click Connect Microsoft (or Google) once.
- Approve the combined scope set on the provider's consent screen.
- Calendar, email, and file search are all live.
Disconnecting is equally simple. One click removes the account and every service dependent on it. No orphaned tokens sitting in the database waiting to cause trouble six months from now.
Why This Matters
Fewer Clicks, Fewer Failures
Every OAuth hop is a place where something can go wrong. The user closes the pop-up. A scope prompt gets denied by accident. A token refresh fails silently and the service looks broken even though the account is still "connected." Collapsing three flows into one eliminates roughly two-thirds of those failure surfaces.
A Coherent Permission Model
When your agent asks to read a calendar or draft an email, it now reaches for the same account object every other service uses. If the Microsoft account is connected, every Microsoft-backed capability lights up. If it's disconnected, everything goes dark at once — and the UI can say so clearly, instead of showing calendar as connected while email quietly 401s in the background.
Less State to Worry About
For anyone doing enterprise deployments: one account per provider means one refresh token per provider, encrypted once, rotated once. The Fernet-encrypted token store is a single predictable surface to audit, not a scatter of per-service rows with slightly different TTLs.
The Migration
For anyone running an existing hiroi instance, the migration runs on startup. Existing ServiceConnection rows get consolidated into IntegrationAccount by provider, scopes get merged, and the tokens carry over. Users don't have to re-authorize anything — their existing connections keep working with no action required.
The old /api/services/* endpoints are gone. Everything now lives under /api/integrations/, which mirrors the new model exactly. If you were using the old endpoints in a custom dashboard, the new ones are a near drop-in replacement with friendlier payloads.
What You Get Out of the Box
Connect Microsoft and your agent instantly has:
- Calendar read/write (appointment booking, availability checks, event details)
- Mail read (checking your inbox for relevant messages)
- Mail send (drafting and sending on your behalf)
- OneDrive / SharePoint file search (surfacing documents during chats)
Connect Google and your agent has:
- Google Calendar read/write
- Gmail read
- Gmail send
- Google Drive file search
The scopes are requested together on the first consent screen. You see them, you approve them (or don't), you move on.
Enterprise Note
If you're deploying hiroi in your own Azure tenant under the enterprise license, admin consent on your Entra ID app registration covers all of this in one shot. Add the delegated permissions to the app, grant org-wide consent, and every user who logs in gets calendar, email, and files connected automatically — no per-user prompts, no service-by-service setup.
The old per-service client IDs (MICROSOFT_CALENDAR_CLIENT_ID and friends) are no longer needed. The main app registration handles everything.
Connect Once, Forget About It
Integrations should be plumbing, not a project. Hiding three different OAuth flows behind a single connect button is the kind of change you stop noticing after the first day — which is exactly the point.
Open your integrations tab to see it in action. If you're already connected, you won't notice a thing. If you're not, you're about three clicks away from a fully equipped agent.