Security at EB Connect

EB Connect is EcomBalance's marketplace-to-accounting connector. It reads financial settlement data from a client's marketplace accounts and posts reconciled journal entries to their accounting software. This page is our published information security policy: the controls that protect that data, and the rules our team operates under. It applies to all EcomBalance employees and contractors with access to EB Connect systems or data.

1Data minimization — what we handle, and what we don't

The strongest control is not holding sensitive data in the first place.

• We store: marketplace OAuth tokens, financial settlement and payout data (sales, fees, refunds, reimbursements — aggregate amounts by category and SKU), and the accounting records built from them.
• We do not store consumer personal information. We request read-only, finance-scoped API access only, and deliberately exclude marketplace scopes that carry buyer names, addresses, or contact details.
• We never handle client passwords. Every marketplace and accounting connection is authorized by the account owner through the platform's own OAuth consent flow, and can be revoked by them at any time.
• All access is read-only toward marketplaces: EB Connect never modifies a client's store, listings, orders, or fulfillment.

2Infrastructure and network security

• EB Connect runs entirely on managed serverless infrastructure (Netlify). We operate no self-managed servers, VMs, or corporate network hosting production systems — the platform provider handles physical security, network-level threat mitigation, DDoS protection, and workload isolation (per-function, per-site).
• All traffic is encrypted in transit: HTTPS/TLS-only ingress, and TLS on every outbound call to marketplace and accounting APIs.
• Data is encrypted at rest by the platform's managed storage.
• Cross-origin requests are restricted to our own origins — no wildcard CORS.
• Staff endpoints have no direct network path to production data stores; all access goes through the application's authenticated API layer.

3Access control

• The application is invite-only. There is no self-service signup; accounts are provisioned by an administrator and staff sign in with Google single sign-on.
• Every API request is authenticated and enforced server-side — requests without a valid identity or service credential are rejected, not merely logged.
• Access follows least privilege: production configuration, secrets, and deployment are restricted to a small number of authorized administrators.
• Access is revoked promptly on role change or departure: SSO account disabled, application invite revoked, and shared service credentials rotated where applicable.

4Credential and secrets management

• API secrets and signing keys are held in the hosting platform's encrypted environment configuration — never in source code, and never committed to version control. Automated secret scanning runs on every deploy.
• Internal service-to-service calls carry a dedicated shared-secret credential compared in constant time.
• Marketplace OAuth tokens are refreshed and rotated server-side; expiring token pairs are replaced automatically and stale credentials are never written back over fresh ones.
• Provider secrets (API keys, client secrets) are rotated on a schedule or immediately upon suspicion of exposure.

5Application security

• OAuth flows use single-use, unpredictable state values verified on callback; platform webhooks are verified by HMAC signature over the raw request body and rejected on mismatch.
• Third-party API responses are treated as untrusted input; unrecognized data is quarantined rather than silently processed.
• Changes are tracked in version control and pass an automated verification suite covering authentication, connection flows, and posting logic before deployment.

6Endpoint and personnel security

• Company endpoints run endpoint protection with real-time scanning and automatic definition updates, and operating systems receive automatic security updates.
• Staff accounts use strong, unique credentials with multi-factor authentication on administrative and email accounts.
• All staff and contractors are bound by confidentiality obligations and are trained on this policy's data-handling rules, including the prohibition on exporting client credentials or financial data outside managed systems.

7Backups, retention, and deletion

• Application data is backed up on a scheduled basis; backups are access-restricted to authorized administrators and are never stored in source control.
• Financial records are retained as required for the accounting services we provide. When a client disconnects a marketplace or ends service, the associated credentials are revoked and deleted; we honor platform deletion and redaction requests via each marketplace's compliance webhooks.

8Incident response

• Suspected security incidents are triaged immediately by the engineering owner: affected credentials are revoked or rotated first, then scope is assessed from access and deployment logs.
• Where client data or a platform integration is affected, we notify the affected clients and the relevant platform without undue delay, and in line with applicable law.
• Every incident ends with a written post-mortem and a permanent, verified fix — incident learnings are encoded into the automated verification suite so regressions cannot ship.

9Vendor and platform security

Production dependencies are limited to established providers — our hosting platform (Netlify) and the official APIs of the marketplaces and accounting platforms our clients connect (for example Amazon Selling Partner API, Shopify, TikTok Shop, Intuit QuickBooks). Each integration follows that platform's partner security requirements and uses the platform's own OAuth consent and revocation model.

10Reporting a vulnerability

If you believe you have found a security issue in EB Connect, email api@ecombalance.com. We acknowledge reports promptly, and we ask that you do not access data that is not yours or disrupt the service while investigating.