A new way to think about connected work. Explore the RelayOS demo ↗
Data + Communication

Supabase and Gmail integration

Connect Supabase with Gmail: an example workflow for application records, field mapping, duplicate prevention and reliable delivery.

Connect Supabase to Gmail

This example transfers a useful update from Supabase to Gmail when a database event is received. The goal is to make the source context available to the receiving team without giving every teammate access to both systems. It is a design blueprint, not an activated connector.

SupabaseValidate + mapGmail

The event contract

Send table, record ID and event type as the initial payload. Keep the Supabase source identifier alongside the Gmail destination reference. Treat the event timestamp as data, not as a unique key. If an optional field is missing, omit it explicitly rather than overwriting an existing destination value with an empty string.

  1. 01

    Choose the trigger

    Start with a test event where a database event is received. Apply a filter so only records owned by the intended team continue.

  2. 02

    Resolve the destination

    Look up the matching Gmail record using the stored source key. Define what should happen when there are zero, one or several matches.

  3. 03

    Transform the payload

    Normalize dates to ISO 8601, preserve currency codes and map the data fields into the receiving schema.

  4. 04

    Write and acknowledge

    Save the result in Gmail, then mark the source event as delivered. Keep the acknowledgement separate from the outgoing request.

Failure handling and replay

A repeated event should reuse its original key. A permission error should pause the connection and notify its owner. A rate-limit response should wait for the indicated interval. Send malformed application records to a review queue and retain only the fields needed to diagnose the error. Never place an access token in an execution log.

A practical acceptance test

Create three sample application records in Supabase: a complete record, one missing an optional value and one containing a non-ASCII name. Deliver each to Gmail, replay one event, and confirm that the destination contains three intended results. Document the response when a required field is absent.

Is this a two-way sync?

The illustrated recipe is one-way. A two-way design additionally needs conflict resolution, loop prevention and an explicit system of record.

Are performance figures guaranteed?

No. Measure latency and success rate against your actual accounts. The demonstration makes no uptime or throughput guarantees.