Sub-processors

A sub-processor is a third party that processes your data on our behalf. We keep the list short on purpose - every additional sub-processor is another vendor to audit and another DPA to negotiate.

Current list

Sub-processor	Purpose	Region
Hetzner Online GmbH	Application hosting + object storage	EU (Germany)
Stripe, Inc.	Subscription billing and payment processing	US, with EU data routing for EU customers
Postmark (ActiveCampaign)	Outbound transactional email (notifications, autoresponders, receipts)	Outside the EU/EEA, on every plan, under Standard Contractual Clauses
Akismet (Automattic)	Spam classification for submissions	US
hCaptcha (Intuition Machines)	Human-verification challenge on hosted forms	Routed regionally
Google (reCAPTCHA)	Optional per-form reCAPTCHA challenge, using the keys you supply for that form	US
Twilio Inc.	SMS for the automation SMS step and link-in-bio signup confirmations, sent from our account	US
numverify (APILayer)	Optional network validation of phone numbers collected in funnels, on our API key. Off by default	Provider-hosted API; no EU commitment established
OpenAI, L.L.C.	AI moderation scores, AI insights, and AI-drafted replies - only for teams on plans with AI features, and only on forms where those features are switched on	US
Cloudflare, Inc.	Edge TLS termination and reverse proxy for customer-configured custom domains on funnel pages and agency portals, including the submissions posted to them	Global anycast network

That's it. No analytics tracker on customer-facing submission pages, no shadow vendors, no data shared with anyone outside this list.

* * *

Hetzner

What it does: runs our virtual machines, our managed databases, and our object storage.

What we send it: everything. Submissions, files, encrypted database state, application logs.

Why: Hetzner is one of the few hosts that offers high-quality EU-resident infrastructure at a price that lets us run a fair pricing model. They operate data centers in several countries; ours is in Falkenstein, Germany (FSN1). We do not use their US region, so no customer data is transferred there. Hetzner is GDPR-compliant.

DPA reference: linked from our DPA.

* * *

Stripe

What it does: processes credit cards, runs subscription billing, generates invoices, handles SCA / 3DS, hosts the customer billing portal.

What we send it: customer email, billing address, the invoice line items, and (via the customer's browser, never via our backend) card numbers. Tax IDs if you've supplied them. We never see full PANs ourselves - see payment methods for the boundary.

Why: Stripe is the boring correct answer for billing. PCI-DSS Level 1, SOC 2 Type II, and they handle SCA + tax + invoicing in a way that's hard to replicate.

Region: Stripe is US-headquartered but supports EU data routing for European customers. EU customer data is processed on EU infrastructure under SCCs.

DPA reference: stripe.com/dpa.

* * *

Postmark

What it does: sends transactional email - submission notifications to form owners, autoresponders to submitters, billing receipts, account emails.

What we send it: the recipient's email address, the message body (which contains the submission payload for notifications, or the autoresponder template for autoresponders), and minimal metadata.

Why: Postmark has the highest deliverability of any transactional provider we've tested. They route from dedicated IPs and they're aggressive about cutting off spammers, which keeps our reputation clean.

Region: US-headquartered, and we call their global API endpoint. We have not established an EU-region processing commitment for them, so treat this as processing outside the EU/EEA on every plan, under Standard Contractual Clauses.

This page used to say Pro and Team customers were routed via EU servers in Dublin, while the legal sub-processor page said Frankfurt. Neither is configured anywhere in the product and no plan flag switches mail routing, so both claims are withdrawn. The conservative reading is the one above, and it is pending confirmation against the provider account. If an EU-region arrangement exists or is put in place, it gets recorded here with its date.

This is the one path on which submission content leaves our infrastructure without a customer enabling anything, because a notification email contains the submission. If your DPA prohibits any non-EU processing of submission content, turn email notifications off and collect submissions through the dashboard, the API, or a webhook to a destination you control.

DPA reference: postmarkapp.com/dpa.

* * *

Akismet

What it does: classifies submissions as spam or ham. We send the form payload (sanitized of fields you've marked as PII) plus minimal context (IP, user agent, the form's URL) and Akismet returns a verdict + confidence score.

What we send it: as little as possible - fields you've marked as pii: true in the form schema are stripped before being sent. By default, the email field, IP, and free-text body fields are sent. See spam classification for what you can opt out of.

Why: Akismet is good at spam, and spam is our biggest filtering challenge. Their dataset spans millions of WordPress sites, which gives them signal we couldn't build alone.

Region: US-only. There's no EU-routed Akismet. If your DPA prohibits any US-routed processing of submission data, disable Akismet on the form (under Form → Spam protection) and rely on hCaptcha + our internal heuristics. Note that AI moderation also routes through a US provider (see OpenAI below), so leave it off too in that case.

DPA reference: akismet.com/privacy.

* * *

hCaptcha

What it does: presents a human-verification challenge before a submission is accepted. The challenge is rendered in the submitter's browser and the verification token is sent to our backend, which calls hCaptcha to confirm.

What we send it: the verification token, the submitter's IP, and the site key. The submission payload itself is not sent to hCaptcha.

Why: hCaptcha is the privacy-respecting alternative to reCAPTCHA. They don't sell user data or run a global advertising graph off challenge interactions, and they're routed regionally so EU users hit EU-hosted challenge servers.

Region: globally distributed; hCaptcha auto-routes based on submitter geography.

DPA reference: hcaptcha.com/privacy.

* * *

Google (reCAPTCHA)

What it does: presents a reCAPTCHA challenge before a submission is accepted, as the alternative to hCaptcha. A form can have one or the other, never both, and it is off unless you enable it and supply that form's own site and secret keys.

What we send it: the challenge token and the submitter's IP address, on the server-side verification call. Separately, and this is the part worth telling your own visitors about, the challenge script is loaded into the submitter's browser directly from Google, so Google receives their IP address, user agent, and whatever cookies their browser sends, without that data passing through us. The submission payload itself is never sent.

Why: some teams already standardise on reCAPTCHA and need their forms to match. If you have a choice, hCaptcha is the more privacy-preserving default and is what we recommend.

Region: US.

If your DPA prohibits US-routed processing or a Google-set cookie on your form, use hCaptcha, or turn captcha off and rely on the other spam layers. A form that uses hCaptcha never contacts Google.

DPA reference: business.safety.google/privacy.

* * *

Twilio

What it does: sends SMS on our own Twilio account, for the SMS step in automations and the confirmation text on a link-in-bio SMS signup block.

What we send it: the recipient's phone number and the message body. Nothing else.

Why: SMS needs a carrier relationship, and building one per customer is not realistic at our size.

Region: US, under Standard Contractual Clauses.

Note the boundary: a Twilio account you connect yourself, for funnel SMS or WhatsApp one-time passcodes, runs on your credentials. That traffic is yours to disclose, not ours. Only the platform-account paths above are our sub-processing.

DPA reference: twilio.com/legal/data-protection-addendum.

* * *

numverify (APILayer)

What it does: checks whether a phone number entered in a funnel is a live, reachable number on a real network. Off by default: it runs only when a workspace picks numverify as its phone validation driver.

What we send it: the phone number in E.164 form, and nothing else. No name, no email, no submission content.

Why: a lead list full of unreachable numbers costs more to work than it earns, and a network check at capture time is the cheapest place to catch that.

Region: the provider's hosted API. We have not established an EU processing commitment for it, so treat it as a transfer outside the EU/EEA. If that is not acceptable, leave phone validation disabled, which is how it ships. Choosing the Twilio Lookup driver instead runs the check on your own Twilio credentials rather than ours.

DPA reference: request from the provider; we will share what we hold on request.

* * *

OpenAI

What it does: powers the optional AI features - per-submission moderation scores, AI insights summaries, submission categorization, and AI-drafted autoresponder replies.

What we send it: the submission content needed for the specific feature, and nothing else. No account data, no billing data, no files. Nothing is sent unless your team's plan includes AI features and you have switched the specific AI feature on for the form - both conditions are enforced server-side before any AI job is dispatched.

Why: a dedicated language model materially out-performs heuristics for moderation and summarization. We use OpenAI's API under their business terms: API data is not used to train their models, and their standard retention window applies.

Region: US. If your DPA prohibits US-routed processing of submission data, leave AI features off - the product works fully without them.

DPA reference: openai.com/policies/data-processing-addendum.

* * *

Cloudflare

What it does: when you point your own domain at a funnel page or an agency portal, Cloudflare issues the TLS certificate for that hostname and proxies the traffic to our origin. We use Cloudflare for SaaS custom hostnames for exactly this, and nothing else.

What we send it: everything that travels over that hostname. Page loads, the visitor's IP address and user agent, and the submissions posted on that domain. TLS is terminated at Cloudflare's edge, so the request body is readable there before it reaches us.

Why: a customer domain needs a certificate that we can issue and renew automatically, for any hostname, without you sharing DNS control or a private key with us. Cloudflare for SaaS is the mechanism that does that.

Region: Cloudflare runs a global anycast network, so a visitor is served from the point of presence nearest to them. That is the one place in this list where the processing location follows your visitor rather than sitting in the EU.

If that is not acceptable under your DPA, do not configure a custom domain. Funnels and portals served on our own formspring.io hostnames never touch Cloudflare, and every other product is unaffected either way.

DPA reference: cloudflare.com/cloudflare-customer-dpa.

* * *

What about other things you might expect to see here?

• No analytics on submission endpoints. We don't load Google Analytics, Plausible, or anything else on formspring.io/f/.... Submissions are processed without third-party JS.
• No CDN in front of our own hostnames. Forms, surveys, funnels, and every other page served on formspring.io go straight to our origin in Germany. The only edge in the path is Cloudflare, and only on a custom domain you configured yourself (see above).
• AI processing is opt-in, twice over. No submission data is sent to any AI provider unless your plan includes AI features and you have enabled the specific feature on the form. Teams that never turn AI on never have submission data leave our infrastructure for AI processing.

* * *

Changes to this list

• 2026-09-17. Cloudflare added. It terminates TLS for customer-configured custom domains, which makes the submissions posted to those domains readable at its edge.
• 2026-09-17. Google, Twilio, and numverify added. All three were reachable in the product and missing from this page.
• 2026-09-17. Anthropic, which appeared on the legal sub-processor page as an optional AI provider "with zero-retention mode enabled," was removed. Nothing in the product selects it, no credential is provisioned for it, and no zero-retention setting existed to back that claim. No customer or submission data was sent to it. OpenAI is, and was, the only AI provider the application calls.

* * *

Adding a sub-processor

We inform customers of material changes to this list where the agreement provides for it, and you may object to a new sub-processor on reasonable data-protection grounds - see your DPA for the formal mechanism.

There is no subscription or mailing list for advance notice, and this page previously said there was one. What exists instead is this page: it carries the date it was last reviewed, and the change log above records every addition, correction, and removal with the reason for it. If you need to be told directly rather than checking, email info@pixelandprocess.de and say so.

* * *

What's next

• GDPR → - the formal posture and DSAR flow
• Regional hosting → - where the primary data lives
• Encryption → - what's encrypted and where
• Data retention → - how long things stick around