Deployed project
InboxLink Gmail Connector
Every app that reads Gmail rebuilds the same OAuth, token refresh and message parsing. I built InboxLink, a standalone connector service with a typed SDK, so an app gets mail through one small API.
Problem and constraints
Gmail access means OAuth consent, encrypted token storage, refresh, rate limits and MIME parsing. Keeping that inside a product app mixes a security-sensitive service with product code.
Role and ownership
Designed, built and operate the service, its SDK, docs site and npm releases.
Key engineering decisions
- A separate service with its own database and an encrypted token vault, so mail tokens never live in the product app
- OAuth with PKCE, tenant-scoped APIs, and signed webhooks so the app hears about new mail
- Durable PostgreSQL sync jobs for Gmail history, so a restart resumes instead of re-reading the mailbox
- A typed SDK on npm, published from GitHub Actions with OIDC (id-token) and provenance instead of long-lived npm tokens
Tradeoffs and alternatives
- Another service to deploy and monitor, in exchange for a clear security boundary and reuse across apps
- A small, stable API surface over full Gmail coverage; IMAP and Microsoft adapters are parked until there is demand
Reliability, deployment, and observability
Health checks, structured logs with secret redaction, and automated tests against a local Gmail stand-in; CI runs lint, type checks, tests and CodeQL, a scheduled smoke test checks production, and a docs check blocks any release whose changelog, README and website SDK page don't match the new version.
Results and lessons
- Askel's production mail reading runs through InboxLink
- Any new app can add Gmail with the SDK instead of writing its own OAuth and parsing