Legal Case Sync
Full-stack multi-firm platform syncing law-firm case systems (Litify/Salesforce, Filevine) with Zendesk in both directions.
Architecture at a glance
data flows left to right- Litify / Filevine
- Webhook intake
- Job queue
- NestJS sync engine
- Zendesk
connectedOAuth 2.0MongoDBCloudWatchAdmin dashboard
The problem
Law firms track cases in Litify (on Salesforce) or Filevine. The operations team works in Zendesk. When the two drift apart, a missed update is more than an annoyance. It is a compliance gap. And every firm has its own instance, its own credentials and its own field setup.
What I built
A full-stack platform built on NestJS and MongoDB that keeps both sides in sync, in both directions, for multiple firms at once. Changes in a case system show up in Zendesk, and updates made in Zendesk flow back to the case system. A web dashboard lets the team connect firms, map each firm’s fields and see what is syncing.
Engineering decisions
- One platform, many firms. Each firm is isolated with its own Litify or Filevine connection, credentials and sync configuration, so onboarding a new firm is setup, not new code.
- Field mapping per firm. Every firm sets up its case fields differently. Each firm gets its own mapping between its Litify or Filevine fields and Zendesk, configured from the dashboard instead of hard-coded.
- Queued, containerized processing. Sync work runs on queues inside Docker, so a slow third-party API does not lose events.
- Tests as the safety net. 1000+ tests cover the mapping and sync rules, so changes ship without guessing.
Infrastructure and operations on AWS
- I deploy and operate the production system on AWS EC2. Server access goes through SSM Session Manager, with no open SSH.
- I run production deploys myself. Database migrations run as their own step before the app restarts, and I take RDS snapshots and an EC2 image before risky changes.
- I set up centralized logging in CloudWatch for every service, and caught logging settings that would have shipped an empty log group.
- I built email failure alerts on Amazon SES.
- I wrote a least-privilege IAM policy for document storage in S3, limited to a single folder.
- I added startup checks that stop a service from booting with a broken or half-finished configuration.
- Sensitive client data never appears in logs or alerts.
Security
Legal case data is sensitive, so security is built into every layer, not added at the end.
- Encrypted credentials. OAuth 2.0 tokens and API keys for every firm are encrypted at rest and decrypted only at the moment a sync needs them.
- Tokens are managed, not pasted. Tokens are refreshed automatically by the platform, so no one copies secrets around by hand.
- Firm-level isolation. Every query and sync job is scoped to a single firm, so one firm’s cases and credentials can never leak into another’s.
- Trust nothing at the door. Every inbound webhook is HMAC-verified before it is processed and handled idempotently, so forged requests are rejected and replays never create duplicates.
- Secrets stay on the server. Credentials are never sent to the dashboard or written to logs.
- Least privilege. Each connection asks only for the access the sync actually needs.