Summary: We collect minimal data, host everything in Germany (EU), never sell your data, and comply fully with GDPR.
1. Data Controller & Processor Roles
FeedOracle operates in two GDPR roles depending on context. For standard API usage, FeedOracle is the data controller. For enterprise integrations where customers send data to FeedOracle for processing, FeedOracle acts as data processor under a DPA.
2. Data We Collect
Account Data
- Email address (for API key delivery)
- API keys (generated identifiers)
Usage Data
- API request logs (endpoint, timestamp, response code)
- IP addresses (security, abuse prevention and rate limiting — see Section 5)
- Request IDs (for support troubleshooting)
Data We Do NOT Collect
- Payment card details (processed by third-party)
- Personal identification documents
- Tracking cookies for advertising
3. How We Use Data
- Provide and maintain our API services
- Send transactional emails (API keys, alerts)
- Enforce rate limits and prevent abuse
- Improve service quality and fix issues
- Comply with legal obligations
4. Legal Basis (GDPR)
- Contract: Processing necessary for service delivery
- Legitimate Interest: Security, fraud prevention, analytics
- Legal Obligation: Tax records, compliance requirements
- Consent: Marketing emails (if opted in)
5. Data Retention
- Account data: Until account deletion + 30 days
- Web server access logs: IP addresses are stored only as a network prefix (
/24 for IPv4, /48 for IPv6); these logs are deleted after 14 days. Web server error logs may contain full IP addresses and are deleted after 14 days.
- System and application logs: may contain IP addresses. Retention criterion: they are removed automatically by size-based log rotation when the storage limit is reached; at present this happens after at most about four and a half months.
- Security and abuse monitoring: we analyse requests to detect scanning, abuse and attacks. Some of these records contain full IP addresses. Retention criterion: these records are kept only as long as they are needed to detect, investigate and defend against abuse and attacks on our services. Automated deletion is not yet in place for all of these records; an automated maximum retention of 30 days for full IP addresses is being introduced and is not yet active.
- API request records (key identifier, endpoint, time, status): kept as long as they are needed for billing, support and abuse investigation concerning the respective API key; a fixed period has not yet been set.
- Website analytics (cookieless, no IP address stored, see Section 10): kept as long as they are needed to compare website usage over time; automated deletion after 6 months is being introduced and is not yet active.
- Backups: local daily backups on our primary server, kept for 7 days, accessible only to the system administrator.
- We are introducing fixed retention periods for the categories above that currently have none, and will update this policy when they are in force.
- Pseudonymized IP prefixes in audit receipts: permanent — see Section 11 for full explanation. Only the
/24 network (IPv4) or /48 prefix (IPv6) is stored, never the full address.
- Invoices: 10 years (legal requirement, German GoBD)
6. Data Location & Transfers
Our primary servers are operated by netcup GmbH in EU data centres (Nuremberg, Germany and Vienna, Austria). Secondary servers for our verification service and internal job processing are operated by Contabo GmbH, Munich, Germany. CDN routing metadata (request headers, IP addresses) may transit globally via Cloudflare for DDoS protection.
7. Data Sharing
We do not sell your data. We share data only with:
- Hosting: netcup GmbH, Karlsruhe, Germany (primary servers) — data processing agreement pursuant to Art. 28 GDPR in place
- Hosting: Contabo GmbH, Munich, Germany (secondary servers) — data processing agreements pursuant to Art. 28 GDPR in place
- CDN/Security: Cloudflare, Inc. (CDN, DDoS protection, TLS)
- Card payments: Stripe, which acts partly as our processor and partly as an independent controller under its own privacy policy
- Pay-per-call payments: USDC on the Base blockchain via the x402 protocol, with Coinbase Developer Platform as payment facilitator. Blockchain transaction data (wallet address, amount, time) is public and cannot be deleted by us.
- Legal authorities: When required by law
8. Your Rights (GDPR)
You have the right to:
- Access: Request a copy of your data
- Rectification: Correct inaccurate data
- Erasure: Delete your data ("right to be forgotten")
- Portability: Receive data in machine-readable format
- Object: Object to certain processing
- Withdraw consent: At any time
Contact privacy@feedoracle.io to exercise your rights.
9. Security
- TLS 1.2+ encryption in transit
- Regular internal security reviews
- Access controls and logging
10. Cookies
FeedOracle uses only strictly necessary cookies. No tracking, advertising, or analytics cookies.
cc — Cookie consent acknowledgment (persistent, essential)session — Dashboard session if logged in (session, essential)
Cloudflare may set __cf_bm for DDoS protection (strictly necessary under GDPR). No third-party tracking cookies are set.
Website analytics: we use a self-hosted instance of Umami (analytics.feedoracle.io). It sets no cookies and stores no IP addresses. It records pseudonymous visit data: visited pages, referrer and campaign parameters, browser, operating system, device type, language and approximate location (country, region, city).
11. UVO Verification Receipts
When you use FeedOracle's verification tools (UVO at /uvo/mcp/, AmpelOracle, or any tool returning a Grounding Receipt), an immutable record is created and stored in our append-only receipt database. This is fundamental to the audit-chain integrity guarantee these tools provide.
The paid UVO action-gate service runs on a separate server operated by Contabo GmbH. Its signed decision records include the claim text you submit for verification, and that server's system logs contain the requesting IP address (see Section 5).
What is stored
Each receipt contains:
- Tool name and timestamp — what was called, when
- Cryptographic hashes of input arguments and output content (SHA-256). Within this UVO Grounding-Receipt pipeline the raw input and output text is NOT retained — only their hashes. This statement applies specifically to the verification-receipt pipeline described in this section; it does not extend to other FeedOracle, ToolOracle/DealOracle or platform services that may process message or request content (for example agent-to-agent outreach or conversation logs), which are governed separately.
- Pseudonymized client IP — IPv4 addresses are stored as a
/24 network prefix (e.g., 203.0.113.0/24 instead of 203.0.113.42); IPv6 addresses as a /48 prefix. This preserves enough information for fraud and abuse investigation while reducing direct identifiability. Network-prefix truncation is active mesh-wide for entries recorded since 2026-06-18; a limited number of older legacy entries may still contain earlier un-truncated values, which are being remediated through a separate retention and clean-up process.
- Truncated User-Agent — first 40 characters only
- Authentication method —
x-api-key, oauth, or anonymous; the API key itself is stored only as a hash
- ES256K cryptographic signature linking the receipt to FeedOracle's published JWKS
- Chain link (
prev_hash) connecting receipts in the calling wallet's history
Why this differs from standard log retention
Receipts are immutable by design. The receipt store uses an append-only database with a SQLite trigger preventing UPDATE and DELETE. This is the substantive guarantee FeedOracle makes to auditors and regulators: the audit chain cannot be altered after the fact, including by FeedOracle itself.
Legal basis
Receipt storage relies on Art. 6(1)(f) GDPR — legitimate interest, specifically: providing a tamper-evident audit trail for regulated workflows where the calling party (or their auditor) requires cryptographic proof of tool execution. This interest is balanced against the data subject's rights through:
- Data minimization (Art. 5(1)(c)): IP pseudonymization to
/24 or /48 prefix; no raw input/output retention within this receipt pipeline (only SHA-256 hashes); UA truncation to 40 chars.
- Purpose limitation (Art. 5(1)(b)): receipt data is used only for audit-chain verification and abuse prevention. Not used for marketing, profiling, or analytics.
- Storage scope: receipts are stored on FeedOracle servers hosted by netcup GmbH and Contabo GmbH (see Section 6).
Your rights regarding receipts
The append-only nature of the receipt store creates a specific tension with Art. 17 GDPR (right to erasure). Our position is:
- Art. 15 (right of access) applies fully — you can request a list of receipts associated with your wallet or pseudonymized IP range. Send requests to privacy@feedoracle.io.
- Art. 16 (right to rectification) does not apply — receipts are factual records of events, not statements about you.
- Art. 17 (right to erasure) may be refused under Art. 17(3)(b) and 17(3)(e) where deletion would defeat the audit-trail purpose for which the data was lawfully processed under Art. 6(1)(f). We will, however, supersede the affected entries with a clearly marked redaction record on documented justified request, so that the chain remains verifiable while removing direct linkage to identifiable persons.
- Art. 21 (right to object) can be exercised by ceasing to call FeedOracle tools. Pre-existing receipts will not be retroactively deleted but new receipts will not be generated.
Public verifiability
Receipts can be retrieved by their call_id via uvo_get_receipt, verified offline against our public JWKS at /.well-known/jwks.json, and bundled into deterministic-hash audit packages via uvo_audit_bundle. This means a third-party auditor can reconstruct the audit chain without trusting FeedOracle — exactly the property regulated workflows require.
Full technical specification: /uvo/spec/ · Receipt format: RECEIPT-2.0-SPEC-v0.1.md
12. Changes
We may update this policy. Significant changes will be notified via email or website notice.
13. Contact
Privacy inquiries: privacy@feedoracle.io
Supervisory Authority: You may lodge a complaint with your local data protection authority.