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 (for rate limiting, deleted after 30 days)
- 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
- API logs: 90 days
- Raw IP addresses (rate-limit logs, nginx access logs): 30 days, then deleted
- 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
Primary data storage is in Germany (EU). CDN routing metadata (request headers, IP addresses) may transit globally via Cloudflare for DDoS protection. Personal data is not intentionally transferred outside the EU/EEA.
7. Data Sharing
We do not sell your data. We share data only with:
- Hosting provider: netcup GmbH (Germany)
- CDN/Security: Cloudflare (GDPR DPA in place)
- 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
- Encrypted storage at rest
- Regular security audits
- 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.
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.
What is stored
Each receipt contains:
- Tool name and timestamp — what was called, when
- Cryptographic hashes of input arguments and output content (SHA-256). The raw input and output text is NOT retained — only their hashes.
- 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.
- 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; 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 EU-based infrastructure (German data center), not transferred to third countries.
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.