Architecture

How Workwae works

Your app connects mailboxes, calendars and contact books, and gets every change back as a signed webhook or from an ordered feed. Mail you send goes through a queue.

Early access
The whole path

From a sign-in to an event in your app.

Three paths run through Workwae: connecting an account, syncing and delivering changes, and sending mail. Pick a step or a node to trace it. Moving dots show direction.

  • Request or sync
  • Result: redirect or event
How Workwae connects your app to mail, calendar and contact providers Your app on one side, the providers on the other, Workwae between them. Connect: your backend creates a connect session; the user signs in at the provider through the hosted page and returns to your redirect URI. Sync and delivery: Workwae reads each provider by cursor, records one event per change with a stable id, and delivers it to your endpoint as a signed webhook or through the change feed. Send: your server or browser queues a message in the outbox, the provider sends it, and the result returns as an event. The numbered steps below describe each stage. YOUR APP WORKWAE PROVIDERS CONNECT SYNC AND DELIVER SEND redirect with account_id POST /v1/…/outbox send.* events Your backend API key (wk_), server side creates sessions, books slots Connect session POST /v1/connect-sessions returns a single-use link 1 Hosted connect page Google, Microsoft, IMAP form seals tokens, adds the account 2 Sync Reads each provider cursors, push, poll 3 Event log One event per change kept 7 to 30 days 4 Signed webhooks Standard Webhooks retries, replay 5 Change feed GET /v1/changes oldest first, cursor 6 Your endpoint or poller Verify, reply 2xx in 10 s Dedupe on webhook-id Poll: keep nextCursor Your server or browser API key (wk_) or account token (wat_) queues the send 9 Outbox queued, sending, then sent, failed or cancelled undo window up to 60 s 7 Google Gmail, Calendar, Contacts Microsoft 365 Graph; GCC High and DoD IMAP and SMTP any other mailbox CalDAV and CardDAV calendars and contacts Zoom and Webex meetings on events How Workwae connects your app to mail, calendar and contact providers Your app on one side, the providers on the other, Workwae between them. Connect: your backend creates a connect session; the user signs in at the provider through the hosted page and returns to your redirect URI. Sync and delivery: Workwae reads each provider by cursor, records one event per change with a stable id, and delivers it to your endpoint as a signed webhook or through the change feed. Send: your server or browser queues a message in the outbox, the provider sends it, and the result returns as an event. The numbered steps below describe each stage. CONNECT SYNC AND DELIVER SEND Your backend API key (wk_), server side creates sessions, books slots Connect session POST /v1/connect-sessions returns a single-use link 1 Hosted connect page Google, Microsoft, IMAP form seals tokens, adds the account 2 Providers Google, Microsoft 365, IMAP sign-in at the provider Providers Gmail, Graph, IMAP, DAV changes read by cursor Sync Reads each provider cursors, push, poll 3 Event log One event per change kept 7 to 30 days 4 Webhooks signed, retried 5 Change feed GET /v1/changes 6 Your endpoint or poller Verify, reply 2xx in 10 s Dedupe on webhook-id Poll: keep nextCursor Your server or browser API key (wk_) or account token (wat_) queues the send 9 Outbox queued, sending, then sent, failed or cancelled undo window up to 60 s 7 Providers Gmail API, Graph, SMTP
  1. Create a connect session

    Your backend calls POST /v1/connect-sessions with an API key and gets a link that works once, for 60 seconds to 24 hours (one hour by default). Headless OAuth does the same from your own provider picker.

  2. The user signs in at the provider

    The hosted page offers Google, Microsoft 365 and an IMAP and SMTP form. For Google and Microsoft, sign-in and consent happen at the provider, so Workwae never sees the password. Workwae seals the credentials, creates the account and returns the user to your allowlisted redirect URI with its id.

  3. Workwae syncs the account

    Each account is read from its provider by cursor: Gmail history ids, Microsoft Graph delta queries, IMAP UIDs, CalDAV and CardDAV sync tokens. A provider push only wakes the sync, and polling is the backstop. Failures back off from 30 seconds to 15 minutes; a revoked grant sets reauth_required.

  4. Every change becomes an event

    A change, a send or an account lifecycle step becomes one event with a stable id. The log keeps events for eventRetentionDays: 14 days by default, 7 to 30.

  5. Signed webhooks push it

    Matching events are POSTed to your HTTPS endpoint, signed with Standard Webhooks (HMAC-SHA256). Answer 2xx within 10 seconds. A failed delivery retries after 5 seconds, doubling up to an hour, and is given up after 3 days; an endpoint with 72 hours of failures is disabled. The delivery log and replay recover missed events.

  6. Or poll the change feed

    GET /v1/changes returns the same events with the same ids, oldest first, 1 to 200 per page. Store nextCursor, which is never null; an empty page means you are caught up.

  7. Send through the outbox

    POST /v1/accounts/{accountId}/outbox queues an entry and answers 201. The account's provider (Gmail API, Microsoft Graph or SMTP) sends it in the background: queued, sending, then sent, failed or cancelled, with an undo window of up to 60 seconds. The result returns as send.sent, send.retrying or send.failed through steps 4 to 6.

  8. Offer bookable slots

    A scheduling link lists open slots computed from its accounts' connected calendars, using your hours, buffers and notice. Booking a slot creates the calendar event, with a meeting link if you ask for one, and sends booking.created. See bookings.

  9. Two kinds of credential

    Servers use an API key (wk_) with the scopes read, write, send and admin, which can be limited to some accounts. Browsers get an account token (wat_) that your backend mints with a write-scope key: it reaches one account's routes for 60 seconds to 24 hours, 15 minutes by default.

Behind the diagram

What each part guarantees.

Each point below is how the API and the delivery pipeline behave today, with a link to the guide that specifies it.

1. The user never gives you a password

For Google and Microsoft, the user signs in and consents at the provider; the browser returns only to a redirect URI on your allowlist. IMAP mailboxes use a form on the hosted page, and plaintext IMAP and SMTP logins are refused. Credentials are sealed before they are stored.

Connect flows

2. The provider stays the source of truth

Workwae keeps an index and sealed credentials. Message bodies are read from the provider on request, or stored only if you choose body storage. A provider push is a wake-up: the sync re-reads from the provider rather than trusting the notice.

Mail

3. Every change is one event

Events have a stable id and are kept for 7 to 30 days (14 by default). Webhooks and the change feed carry the same body and the same id, so one dedupe table covers both. A new account announces itself once with account.initialized when its first sync finishes.

Events

4. Webhooks retry and replay

Deliveries are signed with Standard Webhooks. A failed delivery retries from 5 seconds, doubling to an hour, until 3 days after it was queued. An endpoint with 72 hours of failures is disabled, and the delivery log, replay of one event, a range or failed deliveries, and test events help you recover.

Webhook delivery

5. The feed is ordered and resumable

GET /v1/changes lists events oldest first. Save nextCursor after each page and resume from it after any downtime, as long as you poll within the retention period. It needs no public endpoint.

Change feed

6. A send is queued first

The outbox entry is stored and acknowledged with 201 before any provider call. You can reschedule or cancel it until it starts sending. Delivery is at least once, and an unknown outcome, such as a lost reply from the server, is reported as outcome_unknown instead of being sent twice.

Sending mail

7. Bookings reuse the same calendars

A scheduling link serves open slots computed from its accounts' connected calendars. Booking re-checks the slot, creates the event with the invitee as an attendee and sends booking.created through the same event path.

Bookings

8. Keys stay on your server

An API key can read and change every mailbox it reaches, so it belongs on your server. For a browser, your backend mints an account token that reaches one account for at most 24 hours, and then expires without any cleanup.

API keys and account tokens

Early access

See the path with your own accounts.

Workwae is in early access; tell us which providers your users are on, and read the quickstart in the meantime.