Security at SFHooks

1Our approach

The data flowing through SFHooks — Change Data Capture events from your Salesforce org — is often the most sensitive data a business has: customer records, deal details, support cases. Our security model starts from that assumption.

Three principles guide how we build:

• Minimize what we hold. Event payloads can be filtered to only the fields you need, delivery logs are pruned on a fixed schedule, and credentials are deleted the moment you disconnect.
• Make every hop verifiable. Deliveries are signed, transport is encrypted end to end, and you can inspect the full history of every event in the dashboard.
• Say only what's true. This page lists what we actually do today. Where we haven't yet earned a certification, we say so plainly in Section 10.

2Encryption

In transit

All traffic to sfhooks.com and the dashboard is served over TLS. Behind our edge, traffic stays encrypted: connections between the edge and our application origin use TLS with an authenticated origin certificate, connections from SFHooks to Salesforce use TLS, and our application enforces TLS on every connection to its own database. Webhook deliveries to your endpoints are made over HTTPS.

At rest

All databases and storage are encrypted at rest with AES-256 through AWS-managed encryption (KMS). On top of full-disk encryption, the most sensitive values — Salesforce OAuth access and refresh tokens and per-webhook signing secrets — are additionally encrypted at the application layer with AES-256-GCM before they are written, so their plaintext never lands in the database at all.

3Webhook delivery security

Every delivery SFHooks makes to your endpoint is signed so you can prove it came from us and hasn't been tampered with or replayed:

• Each request carries an X-SFHooks-Signature header containing an HMAC-SHA256 signature computed over the delivery timestamp and the exact payload bytes, using a signing secret unique to your webhook.
• The signed timestamp (also sent as X-SFHooks-Timestamp) lets your endpoint reject stale or replayed requests.
• Signing secrets support zero-downtime rotation: during a rotation, deliveries are signed with both the old and new secret, so you can roll credentials without dropping verifications.
• Custom headers you configure can never override the signature or content-type headers.

Verification takes a few lines of code in any language — see the signature verification guide.

4Salesforce org access

SFHooks connects to your org exclusively through Salesforce OAuth. We never see, ask for, or store your Salesforce password.

• Access and refresh tokens are encrypted with AES-256-GCM at the application layer before storage (Section 2).
• Tokens are used solely to subscribe to your Change Data Capture stream and maintain the connection — nothing else.
• Access is revocable at any time, either from the SFHooks dashboard or from your Salesforce org's connected-app settings. When you disconnect, the stored tokens are deleted.

5Infrastructure & network

SFHooks runs on Amazon Web Services in the United States, behind Cloudflare's edge network.

• Locked-down origin. The application load balancer accepts traffic only from Cloudflare's published IP ranges and presents an authenticated origin certificate — you can't bypass the edge and talk to our origin directly.
• Private data layer. Databases run in private subnets with no public accessibility, reachable only from the application tier, and require TLS on every connection.
• Immutable, repeatable deploys. Application servers are built from versioned machine images and rolled out through an automated deployment pipeline — no hand-configured servers.
• Certified data centers. The underlying AWS infrastructure maintains SOC 1/2/3, ISO 27001, and PCI DSS certifications, among others (see AWS compliance programs).

6Application & access controls

• Password storage. Account passwords are stored only as salted bcrypt hashes — never in plaintext, never recoverable.
• Role-based access. Team members are invited with explicit roles, including a read-only role for teammates who need visibility into deliveries without the ability to change configuration.
• Separated staff tooling. SFHooks' internal admin tooling is a separate application plane with its own authentication, gated behind TOTP-based two-factor authentication. Customer-facing APIs and staff APIs never share endpoints.
• Tenant isolation. Every query in the application is scoped to your organization; delivery history, webhooks, and connections are never visible across tenant boundaries.

7Data retention & minimization

• Payload filtering. You can configure each webhook to deliver only the fields you need, so data your downstream systems don't use never leaves the pipeline.
• Bounded log retention. Event and delivery logs are kept for your plan's retention window — 7, 30, or 90 days — and then automatically pruned. We don't keep payload data indefinitely.
• Credential deletion. Salesforce OAuth tokens are deleted when you revoke a connection or close your account.

Retention of account and billing data is described in our Privacy Policy.

8Payment security

All payments are processed by Stripe, a certified PCI DSS Level 1 service provider — the highest level of certification in the payments industry. Card details are collected by Stripe directly and never transit or rest on SFHooks servers; we store only a payment token and limited metadata such as card brand and last four digits. Billing events we receive from Stripe are themselves cryptographically verified before we act on them.

9Availability & monitoring

• Public status page. Service health is monitored continuously and published at status.sfhooks.com.
• At-least-once delivery. Failed deliveries are retried automatically; events that exhaust retries land in a dead-letter queue where they can be inspected and replayed — individually or in bulk — so a downstream outage doesn't mean lost events.
• Health alerts. Per-endpoint delivery-health alerts notify you when an endpoint starts failing, before it becomes an incident.
• Full observability. Every event's delivery history — payload, attempts, response codes, timing — is available in the dashboard for the duration of your retention window.

10Compliance posture

We believe trust pages should distinguish between what a company does and what it has been audited for. Plainly:

• SOC 2 / ISO 27001: SFHooks has not yet completed a SOC 2 or ISO 27001 audit of its own. We're an early-stage product and will update this page when that changes. The AWS infrastructure we run on holds these certifications; our application-layer controls are described honestly on this page.
• GDPR & CCPA: For Salesforce record data flowing through the service, SFHooks acts as a processor on your instructions. Our Privacy Policy describes roles, legal bases, and your rights; customers who need a Data Processing Addendum (DPA) can request one at [email protected]. Where personal data leaves the EEA, UK, or Switzerland, we rely on Standard Contractual Clauses.
• PCI DSS: Fully delegated to Stripe (Section 8); card data never touches SFHooks systems.

11Subprocessors

We use a deliberately small set of infrastructure providers: Amazon Web Services (hosting), Cloudflare (CDN, DNS, and edge security), Stripe (payments), and PostHog (product analytics), alongside Salesforce as the source of your event data. The authoritative list, with purposes and locations, is maintained in our Privacy Policy.

12Contact

Questions about anything on this page, security questionnaires, or DPA requests: [email protected].