Security

Introduction

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.

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.

Request tracing

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.

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 applications run on Vercel. The primary database runs on Neon (PostgreSQL).
• 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.

API request logging

Each API call creates a database row with the endpoint, HTTP method and path, status code, credits charged, request parameters, response previews, and any error code. Rows are not a permanent archive of platform content. We retain operational API logs for approximately 30 days, including request metadata and response previews, for support, billing, and reliability, then delete them. Logs support billing, abuse detection, support lookup, and reliability work. They are not a permanent copy of third-party platform content.

We do not sell customer API request data or response content, do not use it to train machine-learning models, and do not share it except with subprocessors that help us operate the Services under appropriate safeguards.

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.

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).

Service providers

We use trusted third-party providers for hosting, payments, email, and analytics. Stripe processes payments. A detailed subprocessor list is available on request for security reviews.

Privacy and GDPR

We process personal data in line with UK GDPR, the Data Protection Act 2018, and EU GDPR where it applies. 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.

Report a security issue

If you believe you have found a security vulnerability, email support@socialfetch.dev. Include steps to reproduce and any relevant details. For API issues, include the requestId from the response when you have one. 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.

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 operational API logs for approximately 30 days, including request metadata and response previews, for support, billing, and reliability, then delete them. Each API call creates a database row with the endpoint, HTTP method and path, status code, credits charged, request parameters, response previews, and any error code. 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?
Public pages describe categories only. A detailed list is available on request for legitimate security reviews — email support@socialfetch.dev.

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.

Related documents

Privacy Policy · Terms of Service · Contact