Security
How we protect your data, your keys and your money
Everything on this page describes what the system does today. Where a practice is not in place yet, it is listed as such at the bottom rather than dressed up.
Last updated: 31 July 2026
Credentials
- API keys are never stored
- We keep only a salted SHA-256 hash of each key, plus a 12-character prefix and the last 4 characters so you can tell keys apart in the dashboard. A key that is lost cannot be recovered by us or by anyone else — it can only be replaced.
- Passwords use scrypt
- Account passwords are hashed with scrypt and a per-account salt. We cannot read them, and a database dump does not expose them.
- Scoped keys
- Every key carries explicit scopes. A key without the required scope is refused with 403 — deliberately distinct from 401, so your client knows the credential is valid and should not be discarded.
- Immediate revocation
- Revoking a key takes effect on the very next request. You cannot revoke the key that authenticated the current request, which prevents locking yourself out of your own account.
Isolation between accounts
- Every query is scoped to your account
- Jobs, batches and extractions are always filtered by account. Asking for a resource that belongs to someone else returns 404, not 403 — we do not even confirm that other accounts’ resources exist.
- Cache is not shared across tenants in a way that leaks
- Cached results are keyed by the query parameters, never by identity, and cache hits are billed and reported to you exactly like fresh ones.
Money and correctness
- Credits move atomically
- Every billable call reserves credits, does the work, then commits — and the commit happens in the same database transaction that records the request as served. There is never a moment where money moved without proof that you were served.
- A failed request is not charged
- Any failure after the reservation refunds the credits with a compensating ledger entry. The ledger is append-only, so every movement stays auditable.
- Retries do not double-charge
- Send an Idempotency-Key and a repeated request returns the original response, flagged as a replay, with the original charge. Reusing a key with a different body is rejected rather than silently replayed.
- Long jobs never charge before delivering
- Operations that hand off with 202 keep the credits reserved — not debited — until there is a result. A job that fails returns them.
Transport and browser hardening
- HTTPS only, with HSTS
- All traffic is TLS. Plain HTTP is redirected, and HSTS instructs browsers never to try again over HTTP.
- Content-Security-Policy
- The site ships a CSP that blocks third-party resources, restricts where the page can send data, and disallows plugins and base-tag injection. It was measured against every page before being enabled, not guessed.
- No third-party requests
- Our public pages and documentation load nothing from external hosts — no CDN, no fonts, no analytics beacons riding along with your visit.
Backups and resilience
- Daily backups, verified at the moment they are taken
- Each dump is checked immediately: the archive is read back, critical tables are confirmed present, and a manifest records row counts and total credits. A dump that fails any check is rejected rather than kept.
- Off-site copies
- Every verified dump is replicated to separate storage, in a dedicated area, and the remote copy is confirmed before the backup is considered done. Replication is copy-only: a loss on our side is never mirrored onto the backup.
- Weekly restore drills — on the off-site copy
- Once a week the most recent off-site dump is downloaded and restored into a throwaway database, and its contents are compared against the manifest. Testing the local file would leave the upload, the remote integrity and the download unexercised until the day they were needed.
How we source data
- Licensed sources only
- We buy access to data from licensed providers. We do not scrape, we do not rotate residential proxies, and we do not solve captchas. This is a product decision, not a policy paragraph — it shapes what we are able to sell.
- No anti-bot evasion, ever
- Any feature whose purpose is to circumvent a site’s protections is out of scope, regardless of demand. It is the one thing we will not build.
Availability commitment
The API is designed to degrade rather than break. If our upstream data sources become unavailable, requests are refused before any credits are reserved — you are never charged for an outage — while cached results and the AI tools keep serving. Every response carries a request id; quoting it in an email to support@dataswap.io lets us trace exactly what happened to your call.
We do not yet publish a contractual SLA with service credits. If you need one for a procurement process, talk to us — we would rather agree something we can keep than publish a number we cannot.
Reporting a vulnerability
Email security@dataswap.io with enough detail to reproduce the issue. We aim to acknowledge within one business day and to keep you updated until it is resolved. We will not pursue legal action against researchers who report in good faith, avoid privacy violations and data destruction, and give us reasonable time to fix the issue before disclosing it.
What we do not have yet
- We are not yet SOC 2 or ISO 27001 certified. We will say so plainly here on the day that changes.
- We do not currently offer a contractual uptime SLA with service credits. Our operational commitment is described below.
- Multi-factor authentication for dashboard accounts is on the roadmap and not yet available.
Security or compliance questions?
For a data processing agreement, our sub-processor list, or a security questionnaire, email privacy@dataswap.io. See also our Data Processing Agreement and Privacy Policy.