- 🔄 Auto mail categorization into labels
- ✍️ AI-generated draft responses
- ⚡ Quota-aware Gmail client and concurrency-safe pipeline
- 🔔 Real-time processing via Gmail → Pub/Sub
- 🔒 Quick and easy OAuth server built in
- Bun (v1.3+)
- MongoDB service running
- OpenAi API key
- Gmail account
- Google Cloud Project with Pub/Sub enabled
git clone https://github.com/Benzo-Fury/Inboxer &&
cd Inboxer &&
bun iEnable the Gmail API and Cloud Pub/Sub API in your GCP project, then create a topic and subscription:
# Create a Pub/Sub topic
gcloud pubsub topics create gmail-notifications
# Create a pull subscription
gcloud pubsub subscriptions create gmail-sub --topic=gmail-notifications
# Grant Gmail permission to publish to your topic
gcloud pubsub topics add-iam-policy-binding gmail-notifications \
--member=serviceAccount:gmail-api-push@system.gserviceaccount.com \
--role=roles/pubsub.publisherSet up authentication by creating a service account with Pub/Sub Subscriber role and download its JSON key. Set the GOOGLE_APPLICATION_CREDENTIALS environment variable to point to this file.
Create a .env file in the project root with the following:
CLIENT_ID=your_google_oauth_client_id
CLIENT_SECRET=your_google_oauth_client_secret
OPEN_AI_API_KEY=your_openai_api_key
PUBSUB_TOPIC=projects/YOUR_PROJECT_ID/topics/gmail-notifications
PUBSUB_SUB_NAME=gmail-subRun the project with:
bun build &&
bun start
Inboxer does not store refresh tokens encrypted...
The standard OAuth flow would be to store the users OAuth refresh token encrypted in the database and store the decryption key in a KMS like this:
graph LR
A[(OAuth Refresh Token)]
C[Server]
D[OAuth Token Usage]
A -- "Fetches Encrypted Token " --> C
C -- "Decrypts token using KMS decryption key" --> D
While it's a little more complex and not exactly the same (especially when using envelope encryption), that's the general idea. Inboxer does NOT do this and stores refresh tokens in plain text in MongoDB as it is intended not to be ran in production exposing many user keys.