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

  1. 01

    Call

    Every response carries a requestId — in meta.requestId or the X-Request-Id header.

  2. 02

    Inspect

    Look the call up in the dashboard by requestId while the log row is retained.

  3. 03

    Report

    Quote the requestId to 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?
No. We do not hold SOC 2 or ISO 27001 certification. This page describes our current practices. For diligence questionnaires, contact support@socialfetch.dev.
Do you support GDPR?
We are designed to support UK and EU GDPR rights. See the Privacy Policy for how we collect, use, and retain data. This is our own privacy practice, not a third-party GDPR certification.
How long do you keep API request logs?
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. 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.
What is requestId and why should I include it?
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.
Can I get a list of subprocessors?
Yes. See our live Service Provider Register for the material providers we publicly identify, broad processing locations, safeguard status, and change-notice information. The register is non-exhaustive; additional diligence information may be available where legally permitted and subject to applicable confidentiality and contractual restrictions.
Can I use two-factor authentication?
Yes. You can enable 2FA on your account in the dashboard. We recommend it for accounts with billing access or production API keys.
How are payments handled?
Stripe processes card payments. We do not store full card numbers on our systems.

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 requestId from the response, when you have one