Security
Security
Social Freak Ltd (company no. 14659411), Unit 82A, James Carter Road, Mildenhall, Bury St Edmunds, IP28 7DE, UK, operates Social Fetch. This page describes how we protect accounts, credentials, and operational data when you use Social Fetch. It covers API authentication, request tracing, logging and retention, hosting, and how to report a vulnerability. The Privacy Policy and Terms of Service are the binding documents. We do not hold SOC 2 or ISO 27001 certification. This page describes our current practices.
Last updated 7 September 2026
- Transport
- TLS everywhere
- API keys
- Stored hashed
- Sign-in
- 2FA available
- Tracing
- requestId on every call
Access
Account security
API access uses keys prefixed with sfk_. Send keys in the x-api-key HTTP header. Treat keys like passwords: store them securely, rotate them if exposed, and do not commit them to source control. Keys are stored hashed on our side; we only show the full secret once when you create a key. You can create, name, disable, and delete keys in the dashboard.
You can sign in with OAuth providers (Google, GitHub, or Discord) and enable two-factor authentication (2FA) on your account. Sign-in sessions record IP address and user agent for abuse prevention. You are responsible for activity under your account and for protecting your credentials.
Tracing
Request tracing
01
Call
Every response carries a
requestId— inmeta.requestIdor theX-Request-Idheader.02
Inspect
Look the call up in the dashboard by
requestIdwhile the log row is retained.03
Report
Quote the
requestIdto support and we match it to server-side logs.
Every public API response includes a requestId (in meta.requestId on success or error.requestId on failure). The same value is returned in the X-Request-Id HTTP header. You may send X-Request-Id on inbound requests. Quote requestId when contacting support so we can match your report to server-side logs.
The dashboard and our support team can look up API request history by requestId while the log row is within its retention period.
Controls
Technical and organisational measures
We use the following practices to protect the Services:
- Encryption in transit
- TLS for connections to our websites, dashboard, and public API.
- Encryption at rest
- Account and operational data in our managed PostgreSQL database is stored with our cloud provider's encryption at rest.
- Hosting
- Production web, dashboard, and API applications run on Vercel. Customer-request fulfillment, rendering, crawling, and supporting connectivity workloads run on Railway; active Railway customer workloads are currently deployed in Northern Virginia. The primary database runs on Neon (PostgreSQL). Vercel and Neon production processing regions have not been confirmed.
- Access control
- Internal access to production systems is limited to what operations require and is reviewed as roles change.
- Secrets management
- API keys, database credentials, and similar secrets are stored in secure environment configuration, not in application source code.
- Monitoring and logging
- Structured server logs and error tracking (Sentry) support reliability and incident response. Production logs suppress routine info-level output by default.
- Background jobs
- Non-blocking work such as email delivery runs through a message queue (Upstash QStash) with idempotent handlers.
Data
Logging and storage
API request logging
Each API call creates a database row containing minimal operational fields such as the endpoint, HTTP method and path, status code, credits charged, and any error code. Under standard retention, the row also contains request parameters and limited response previews; those payload fields are not durably stored for zero-retention accounts. Rows are not a permanent archive of platform content. We retain standard operational API logs for approximately 30 days, including request metadata and limited response previews, for support, billing, abuse prevention, and reliability, then delete them. Accounts can opt into zero retention: live processing still occurs, but we do not durably store request parameters, target URLs, or response previews; minimal operational, billing, security, and reliability metadata remains. Hosted screenshots and similar short-lived media artifacts are retained for approximately 7 days. Where a customer explicitly opts into hosted social-media originals, those objects are retained for approximately 90 days. Objects are then deleted automatically; customers needing longer retention should download and store the bytes themselves. Logs support billing, abuse detection, support lookup, and reliability work. They are not a permanent copy of third-party platform content.
For personal data in customer-instructed API requests and results, Social Freak Ltd acts as the customer’s processor; the customer remains controller and is responsible for its instructions and lawful basis. We do not sell that data or use it to train machine-learning models, and disclose it only as needed to provide, secure, and support the Services, including through authorised subprocessors.
What we store
We store account and billing metadata needed to operate the Services: profile details, authentication identifiers, credit balance and ledger entries, invoice metadata from Stripe, and the API request logs described above. We do not permanently archive third-party platform content on your behalf; API responses are returned to you at request time. Hosted screenshots and similar short-lived media artifacts are retained for approximately 7 days. Where a customer explicitly opts into hosted social-media originals, those objects are retained for approximately 90 days. Objects are then deleted automatically; customers needing longer retention should download and store the bytes themselves.
Limits
What we do not do
- We do not sell personal data or customer API request data.
- We do not use customer API request data or response content to train machine-learning models.
- We do not warrant that your use of retrieved data complies with third-party platform terms or applicable law — that is your responsibility.
- We do not claim formal security certifications we have not earned (see introduction above).
Supply
Service providers
We publish at /subprocessors a concise, non-exhaustive register of material service providers we publicly identify. Additional diligence information may be available on reasonable request where legally permitted and subject to applicable confidentiality and contractual restrictions. See the Service Provider Register.
Response
Incident response
We maintain an internal process to triage, contain, investigate, and document suspected security incidents. We notify affected customers without undue delay and, where feasible, within 72 hours of becoming aware of a Personal Data Breach affecting Customer Personal Data, providing available information in phases where necessary. See the DPA for the customer-assistance framework.
Regulation
Privacy and GDPR
We process personal data in line with UK GDPR, the Data Protection Act 2018, and EU GDPR where it applies. Social Freak Ltd acts as processor for customer-instructed API workload personal data and as independent controller for account, billing, fraud/security, and direct-relationship data. This is not a third-party certification programme. For legal bases, retention, international transfers, and your rights, see the Privacy Policy. Questions: support@socialfetch.dev.
FAQ
Security FAQ
Are you SOC 2 or ISO 27001 certified?
Do you support GDPR?
How long do you keep API request logs?
What is requestId and why should I include it?
Can I get a list of subprocessors?
Can I use two-factor authentication?
How are payments handled?
Disclose
Report a security issue
If you believe you have found a security vulnerability, email support@socialfetch.dev. We aim to acknowledge reports promptly and will work with you on a reasonable disclosure timeline. We also publish contact details at /.well-known/security.txt.
support@socialfetch.dev
For security issues, put SECURITY in the subject line.
What to include
- Steps to reproduce
- Any relevant details
- The
requestIdfrom the response, when you have one