Security

Use this page to map the SocialCrawl data path and the controls your security review should cover.

1. Your server sends an authenticated API request to SocialCrawl over HTTPS.
2. SocialCrawl validates the request. When the operation requires an upstream request, SocialCrawl sends only the required parameters to a public source or provider. The provider does not receive your SocialCrawl account information.
3. For a fresh fetch, SocialCrawl receives the source result and maps it into the applicable canonical schema. For a cache hit, SocialCrawl reuses a previously normalized result under the endpoint-specific cache rules.
4. SocialCrawl returns the normalized response over HTTPS.
5. Your system receives the response and applies its own storage, retention, and access controls.

How a request moves through SocialCrawl

Keep the API key on your server. SocialCrawl uses it to authenticate the request and apply the account's usage controls. The key is not sent to the social platform or upstream provider.

Only the parameters required to complete the operation are sent upstream. SocialCrawl then validates and normalizes the result before returning the canonical response. See Response schema for the response contract.

The public-data boundary

SocialCrawl's social-platform collection is limited to information available without logging in. It does not retrieve private accounts, private posts, direct messages, login-walled content, paywalled content, password-protected content, or data that requires your social-platform credentials.

This boundary describes social-platform collection. It does not mean every part of the product is anonymous or public-only. Website account and dashboard sessions process account, authentication, usage, and billing information separately.

Public availability does not remove privacy or data-protection obligations. Public social data can still be personal data. You are responsible for assessing your purpose, lawful basis, notices, retention, and other obligations under the laws that apply to your use. This page is not legal advice. See the Public Data Notice for the published collection boundary.

What SocialCrawl stores and for how long

Detailed API request-log rows record the endpoint, request parameters, and operational metadata. They can also include an IP address and user agent where those values are available. The implemented cutoff removes these detailed rows after 90 days. The Privacy Policy separately describes retaining aggregated and anonymised data after 90 days. That aggregate layer is not the detailed request log.

Do not apply that period to every record in the product. These categories have different purposes and lifecycles:

• Account data is deleted within 30 days after account deletion.
• Website session records are deleted within 30 days after the session expires.
• Monitoring data sent to Sentry is retained for 90 days.
• Cached responses follow endpoint-specific behavior. See Caching for the API contract. There is no single response-cache period stated on this page.
• Stateful features, including Monitors and Cohorts, persist resources and results as part of the feature. Treat them as stored product data, not transient request logs, and review the relevant feature contract before use.
• Webhook signing secrets are encrypted at rest. The plaintext secret is shown once when the webhook-backed resource is created, as described in the canonical webhook contracts.

See the Privacy Policy for the published retention and data-handling terms.

Protect and rotate API keys

An API key is a server-side credential. Protect it as you would any production secret:

• Store it in a secret manager or encrypted server-side environment variable.
• Never include it in browser code, mobile application bundles, URLs, logs, tickets, or chat messages.
• Use a separate key for each environment.
• Set a credit cap on non-production keys to limit spend if a test or CI job loops.
• Rotate a key by creating and deploying its replacement, confirming traffic has moved, and then revoking the old key.

API keys are not permission-scoped. Anyone who holds an active key can use the API access available to that key, subject to its credit cap and other account controls. See Authentication for creation, caps, expiry, revocation, and rotation.

Transport and webhook security

Use HTTPS for API requests. The Privacy Policy states that appropriate safeguards include encryption in transit and at rest where applicable. It does not create a universal storage or residency commitment for every response or product resource.

Monitor and billing webhook receivers must use a public HTTPS URL. SocialCrawl signs each delivery with HMAC-SHA256 over the timestamp, a period, and the unmodified raw request body. Verify the signature against the raw bytes before parsing JSON, and reject timestamps outside the 300-second replay window.

Follow the complete verification and delivery contracts in Monitor Webhooks and Billing Webhooks. Keep webhook signing secrets separate from API keys.

Infrastructure controls and product certifications

Certifications or attestations held by an infrastructure or service provider cover that provider's controls. They do not certify SocialCrawl as a product and should not be presented as SocialCrawl certifications.

Contact SocialCrawl for the current availability of product-level assurance or review materials. Asking about a document does not imply that it is available. Review current service health on Status and the published operating model on Reliability.

Privacy, terms, and public-data notice

The current published documents are:

• Privacy Policy, which explains personal-data handling, retention principles, safeguards, and international transfers.
• Terms and Conditions, which govern use of the service.
• Public Data Notice, which explains the public-source collection boundary and rights information.

The Privacy Policy permits processing or transfers outside the UK and European Economic Area where appropriate safeguards are used. SocialCrawl does not make a product data-residency commitment.

DPA and security review status

Send your required review documents, control questions, processing regions, and retention requirements through Contact. SocialCrawl will confirm the current availability of product-level assurance, data-processing, or security-review materials. Do not treat this page, an infrastructure provider's certification, or general privacy language as a substitute for a document your review requires.

Enterprise and support

Self-serve plans do not include a service-level agreement. A separately signed Enterprise agreement may include a service-level agreement, with its terms defined in that agreement.

Review Enterprise for the information to include in a procurement request. Use Contact to discuss your requirements or ask account and security-review questions. Use Status for current platform health. No support response time is promised on this page.