Security overview
Bidson CRM Sync uses authenticated Shopify access, provider-specific connection controls and shop-scoped application data. Shopify webhooks are authenticated before their contents are processed, and background work is designed to be idempotent so duplicate delivery does not create duplicate work or CRM records.
Data protection
CRM Sync reads the customer identity, contact details and selected business information needed for synchronization. Optional groups cover commerce summaries, tags and marketing state, lifecycle information and coarse location. Complete Shopify customer, order and webhook payloads are not intentionally stored as synchronization data. The database keeps the technical identifiers, job state and limited audit metadata needed to operate, reconcile and delete the service safely.
Connections and credentials
Connections use the method supported by each CRM, including OAuth or a user-provided API key. Shopify session secrets and CRM credentials are encrypted by the application before database storage and are bound to the relevant shop and connection context. Credentials are used only for the requested integration. Disconnect and uninstall flows remove ordinary access; credentials needed to finish a pending privacy obligation are isolated from normal synchronization until that obligation is resolved.
Infrastructure and availability
CRM Sync separates web requests from background processing and stores durable queue and reconciliation state in PostgreSQL. Production PostgreSQL has point-in-time recovery enabled and scheduled daily, weekly and monthly backups. Application recovery tooling can quarantine ordinary work after a restore, validate connections and reconcile current Shopify state before normal processing resumes. These controls improve recoverability but are not an uptime, RPO or RTO guarantee.
Reliability and monitoring
Synchronization uses bounded concurrency, leases, duplicate prevention, controlled retries and current-state reconciliation. Shopify and CRM rate-limit instructions are respected, and temporary failures are scheduled for later processing instead of being retried aggressively. Worker health, queue delays and normalized failure events are recorded without customer payloads or access tokens.
Access and operational security
Secrets and production configuration are kept outside source code. Two-factor authentication is enabled for the current Railway project member. Application logs use allowlisted technical fields and opaque Support IDs. Source-controlled changes are checked with linting, type checking, automated tests, builds and security-focused suites appropriate to the change. Infrastructure access and account controls are reviewed separately from application code.
Incident response
Bidson maintains a documented process to investigate, contain and recover from suspected security or personal-data incidents. It covers credential rotation, evidence preservation, impact assessment, required notifications and post-incident improvements. No fixed response-time commitment is made here.
Vendors and subprocessors
Bidson documents service providers appointed to process personal data. Shopify and the merchant-selected CRM are also part of the data flow, but are services selected and contracted by the merchant for the requested synchronization.