Skip to main content

Portfolio demo. Billing runs in Stripe test mode (card 4242 4242 4242 4242). No real charges.

Security

Last updated: April 2026

This page is meant to be useful to a procurement reviewer or a security-conscious engineer doing due diligence — not a marketing claim sheet. We list what we do, what we don't do yet, and how to reach us. Email security@apidelta.dev for vendor-assessment questions or to disclose a vulnerability.

What we don't have yet

Up front, so you can stop reading early if it's a deal-breaker:

  • SOC 2 Type II: not yet. On the roadmap once seat count and revenue justify the audit.
  • SSO / SAML: not yet. Listed as roadmap on the Business plan.
  • HIPAA / FedRAMP: not in scope. APIDelta processes public changelog content and your alert routing config — not regulated PHI or controlled federal data.
  • Penetration test reports: none we publish today. We can share the scope of the most recent dependency audit on request under NDA once a Team-tier conversation is live.

If any of these are blocking, tell us at security@apidelta.dev and we'll be straight about timing.

Hosting and infrastructure

  • Web app: Vercel (US regions). Static prerender + serverless functions.
  • API and crawler: Railway (US). Long-running Node.js workers behind a managed Postgres instance.
  • Queue + cache: Upstash Redis (US).
  • Customer data is never stored on developer laptops — production access is via tooling that audits each session.

Encryption

  • In transit: TLS 1.2+ on every endpoint (apidelta.dev, api.apidelta.dev). HSTS enabled. Internal service-to-service traffic also over TLS.
  • At rest: Postgres data is encrypted at rest by Railway's underlying provider (AES-256). Redis data is ephemeral (queue jobs and short-lived caches) and encrypted at rest by Upstash.
  • Secrets: API keys and OAuth tokens are stored hashed where the protocol allows it (e.g., bearer tokens for MCP), and encrypted at rest where it doesn't (e.g., GitHub PATs the user provides for the GitHub Issues alert channel). Application-layer secrets live in Vercel and Railway secret stores — never in the repo.

What we store

  • Account info: email, name, OAuth subject ID.
  • Team configuration: monitored API URLs, alert routes, severity thresholds, channel configs (Slack webhook URLs, GitHub PATs, generic webhook URLs + HMAC secrets).
  • Crawled changelog content (publicly available text from the URLs you configure). This is not personal data.
  • AI classifications: severity, change type, affected endpoints, summary text generated by the Anthropic API for each entry.
  • Alert dispatch history (timestamps, channel, status).
  • Stripe customer ID + subscription state.

What we don't store

  • Your source code. APIDelta is a server-side changelog crawler. There is no SDK, no agent, no CI plugin.
  • API keys to the third-party services you monitor. We crawl public changelog URLs — we don't need credentials to Stripe, OpenAI, etc.
  • Credit card numbers. Stripe handles payment surfaces directly; we never see PAN data.
  • Your end-users' data. APIDelta only knows about you, your team, and the URLs you configure.

Sub-processors

Third parties that may process customer data on APIDelta's behalf:

  • Vercel — web hosting and edge delivery (US).
  • Railway — API + worker hosting and managed Postgres (US).
  • Upstash — Redis for queue and cache (US).
  • Anthropic (Claude API) — AI classification of changelog entries. We send only the publicly available changelog text we crawled; we don't send your team or account metadata. Anthropic's API is configured with zero data retention where the option is available.
  • Stripe — payment processing. PCI-DSS Level 1.
  • Resend — transactional email (alerts, magic links, billing receipts).
  • GitHub — only when you connect the GitHub Issues alert channel; we use the PAT you provide to file issues in repos you authorize.
  • Slack — only when you connect a Slack Incoming Webhook for alert delivery.

We will give 30 days' notice via email before adding a new sub-processor that processes customer data.

Authentication and access control

  • End users sign in with email magic link or GitHub OAuth via NextAuth.js v5. We never store plaintext passwords; magic-link tokens are single-use and short-lived.
  • Multi-tenant isolation: every record is scoped to a teamId and queries that read or write team data are guarded at the application layer. There is no shared-tenant data.
  • API keys (MCP server): per-team bearer tokens, read-only, rotatable and revocable from the dashboard.
  • Internal access: production database access requires SSO + MFA. Employees access customer data only when debugging a specific support request, and the access is logged.

Data retention and deletion

  • Change history is retained for the lifetime of your team account (Starter and Team) or per the agreement on Business.
  • Alert dispatch history (delivery attempts) is retained for 90 days.
  • On account deletion, we remove personal data within 30 days, except where retention is required by law (e.g., billing records held for 7 years per US tax requirements).
  • A team admin can request a full data export at security@apidelta.dev.

Vulnerability management

  • Dependencies are monitored for known CVEs via GitHub Dependabot + npm audit, with patches applied on a rolling basis.
  • We use Prisma as the only data-access layer to constrain the surface for SQL injection, and use parameterized queries everywhere.
  • Web inputs are typed and validated at the API boundary (NestJS DTOs + class-validator).
  • We don't yet run scheduled third-party penetration tests. When we do, the report scope will be available under NDA on request.

Vulnerability disclosure

If you believe you've found a security vulnerability, please email security@apidelta.dev. We'll acknowledge within 2 business days and aim to triage within 5 business days. We don't currently run a paid bounty, but we will credit reporters publicly when the fix ships, with permission.

Please don't test against accounts you don't own, don't pull or modify other teams' data, and give us reasonable time to fix before public disclosure. We'll do the same for you.

Incident response

If a security incident affects customer data, we will notify affected teams via the email on file within 72 hours of confirmation, with what we know, what we're doing, and what actions you should take. We'll publish a public post-mortem for incidents that affect more than one customer.

Compliance

We process personal data in accordance with the GDPR for users in the EEA and UK, and the CCPA for California residents. See our Privacy Policy for the full data-rights detail.

Contact

Vendor-assessment questions, vulnerability reports, or data-export requests: security@apidelta.dev.