Designing a Two-Way Data Sync Between Clay and SeaTable

Hey everyone 👋 we’re currently designing a data sync setup between Clay and SeaTable, but we’ve hit a structural limitation: Clay is great for enrichment, but it doesn’t natively support writing data back into an external CRM or database in a true two-way way sync.😅 So our idea is to introduce an Operational Data Store (ODS) in the middle that would: • receive enriched data from Clay via HTTP Actions or Webhooks, • expose that data via REST/SQL for SeaTable to read and write, • and continuously sync updates both ways (enrichment → CRM → re-enrichment). Setup & scale • ~20–30k rows, ~25 fields per record (Accounts, Contacts, Job Matches) • Bidirectional sync: Clay ↔️ ODS ↔️ SeaTable • Continuous enrichment and matching cycles Current plan • ODS: Postgres or Supabase (Postgres-compatible) • API: PostgREST, Hasura, or FastAPI for REST/GraphQL endpoints • Sync logic: idempotent upserts using external_id (CRM), clay_id (Clay) + timestamps for change detection Clay → ODS • Pushes via HTTP Actions/Webhooks • JSON payloads (batch or single) • Deduplication via (source, external_id, payload_hash) ODS → SeaTable • SeaTable reads via REST endpoints (with pagination + updated_since) • Writes back to ODS when changes happen on CRM side What I’d love to hear from others

Would really appreciate examples or best practices — especially around schema design (IDs, timestamps, versioning) or retry logic for failed pushes. Would love to hear how you approached it.