Where your customers’ contact data actually lives.

Scope

This page covers how the SyncMachina platform handles customer sync data: where it is processed, how credentials are protected and who else is involved. Website enquiries are covered by the Privacy Notice.

Detailed security documentation — our data-processing agreement, a completed security questionnaire and architecture notes — is shared directly with teams evaluating SyncMachina. Email hello@syncmachina.com and we will send it.

1. Where data is processed

The API, the sync worker and the database all run in Frankfurt, Germany (eu-central). Data is not replicated outside the European Economic Area.

Provider APIs are called from that region. Where a provider stores your customers’ data is determined by that provider and your customer’s own tenancy with them, not by us.

2. What we store

Be aware that we do store contact data — this is a sync service, and a canonical record is what makes two providers agree. Specifically:

• Canonical contacts: the fields the sync is configured to exchange — names, email addresses, phone numbers, company and job title.
• Provider records: what each provider last returned for a contact, kept so a write can be rebuilt without discarding fields SyncMachina does not model.
• Field provenance: which connection last set each field and when, which is how conflicting edits are resolved.
• Operational records: sync runs, webhook events and an audit trail of what changed.

A sync definition limits which canonical fields a given connection may exchange, so a connector can be scoped to less than the full record.

3. Credentials and secrets

• Provider credentials — OAuth access and refresh tokens — are encrypted with AES-256-GCM before they are written to the database, and decrypted only in memory for the duration of a provider call.
• OAuth client secrets you register for your own provider apps are encrypted the same way.
• Your API key is never stored. We keep an HMAC-SHA256 digest computed with a separate application-side secret, plus a short prefix so a key can be identified in a list. The key itself is shown once, at creation, and cannot be recovered afterwards. Keys can be revoked, and last use is recorded.
• Webhook signing secrets for your endpoints are encrypted at rest.

We never ask for and never handle your customers’ provider passwords. Authorisation is OAuth, performed by your customer against the provider.

4. Tenant isolation

Every record carries a tenant, and every authenticated request resolves to exactly one. Queries are scoped to that tenant rather than filtered after the fact, and a dedicated automated test suite asserts the boundary holds.

Inbound provider webhooks are authenticated per tenant. A tenant using its own OAuth application is reachable only by that application’s secret, so a payload signed by one tenant’s credentials cannot be used to inject events for another.

5. Least privilege at the provider

Each connector requests the narrowest scope that supports its declared direction. Microsoft 365 organizational contacts is read-only and requests a read scope only; asking for write access would buy nothing and widen the consent unnecessarily.

Writes carry only the fields the canonical record holds. A connector never blanks a property it has no opinion about, and a provider that stores a single value has its primary entry patched rather than its list replaced.

6. Integrity of what we write

Every write records what the provider echoed back for it, so a later read is recognised as our own change rather than counted as an inbound one. Where a provider supports it, writes are guarded by an entity tag, so a record changed since we read it rejects the write instead of overwriting whoever got there first.

Deletion is treated as consequential: a contact removed at one provider becomes a tombstone rather than an immediate cascade, and each connection’s sync definition decides whether that propagates.

7. Outbound webhooks

Events we send to your endpoint are signed following the Standard Webhooks specification, with a per-endpoint secret shown to you once. Verify the signature before acting on a delivery. Deliveries are retried with a bounded attempt count and then dead-lettered rather than retried indefinitely.

8. Subprocessors for sync data

These are distinct from the website subprocessors listed in the Privacy Notice.

• Fly.io — application and worker hosting, Frankfurt.
• Supabase — managed PostgreSQL, Frankfurt.

Provider APIs you connect — Google, HubSpot, Pipedrive, Microsoft — are not our subprocessors. They are systems your customer already uses and authorises directly.

We will give notice before adding a subprocessor that handles sync data.

9. Deletion and exit

Removing a connection retires its provider mappings without deleting contacts other connections still hold. Deleting a tenant removes its connections, contacts, provenance, provider records and operational history by cascade.

Ask for an export at any time; the canonical records are yours.

10. Data-processing agreement

Where SyncMachina processes personal data on your behalf, we sign a data-processing agreement covering scope, subprocessors, security measures, breach notification and deletion on termination. We send the current version before you share any data — ask at any time.

11. Reporting a vulnerability

Email hello@syncmachina.com with enough detail to reproduce the issue. We will acknowledge within three working days. Please do not test against other tenants’ data or run denial-of-service tests; ask and we will provision an isolated tenant.