Privacy Policy

SocialPipe ("we") operates the SocialPipe API. Controller: SocialPipe. Reach us through the chat widget on every page of socialpipe.dev; it is the only contact route we operate and you do not need an account to use it. We have not appointed a data protection officer or an EU representative.

What we hold about customers

Only a SHA-256 hash of each API key is stored, so a database disclosure does not yield working keys.

We do not write raw client IP addresses. Every API request carries a key, so rate limiting counts against the key rather than an address. One exception, from 2026-09-26: the dashboard reports its own browser errors to Sentry, and a report sent from your browser discloses your address to whoever receives it. We do not store it and Sentry is instructed not to, and no configuration undoes the connection itself.

We record which posts and accounts a customer looked up. Alongside the route and the credit count we store the identifier sent and the response returned. On most routes that identifier names a person or a specific post, so this table is also a record of who our customers research.

What we hold about people who are not customers

The API returns public post, profile, follower and comment records from the platforms in our API reference. Those records describe people who never signed up for anything. This is the most important section in this policy.

The API is a router: it asks the platform for a public record and returns that record unchanged. We do not select fields, rename them, hash them or drop them.

• A response contains whatever the platform published: typically a handle, display name, biography, profile image, creation date, and follower and engagement counts. On a timeline, the same again for any account quoted, replied to or mentioned
• We add nothing. No enrichment, no joining across sources, no inference. Everything in a response is retrievable from the platform itself without an account
• We keep two copies. A response cache, 12 hours by default and 30 days at most, which expires automatically. And the call record: we keep the parameters you sent and the response we returned, indefinitely, and it does not expire
• The customer decides what happens next. Anyone who stores this data, builds profiles from it or combines it with other sources does so on their own legal basis, and our terms bind them to that

How much of other people a capability returns

Every capability carries one of three personal-data classes, stated on that capability's own page in the API reference. We publish the rule rather than a list, because the list is 329 rows long.

A single bulk-people call can return dozens to hundreds of people, each with a handle, display name and profile image. Nothing is hashed, redacted or aggregated.

The rule reads the capability's own name, and where it cannot tell it assigns bulk-people, the most protective of the three. 38 capabilities are in that class for that reason rather than because we are confident they belong there.

The Art. 6(1)(f) balancing test for bulk retrieval

Returning one public profile and returning somebody's follower graph differ in kind, so the second is assessed separately. Adding a platform does not change this test.

• Our interest: giving a developer data the platform already publishes, through one documented interface rather than scraping infrastructure each customer maintains
• The data: public by the platform's design and the account holder's settings. A protected account's followers are not returned to us at all
• Effect on the individual: not "none". A follower list is a social graph, and social graphs support inferences a single post does not
• Safeguards: no user_id on the cache key, so a cached record is about a public account and not about who asked; a contractual ban on profiling, ranking or scoring the individuals in a response; and no bulk route exposed through our AI-agent interface, so a bulk retrieval is always a deliberate act by a developer
• Withdrawn safeguards: transient retention, and keeping no record of which identifiers a customer requested. The call store removed both on 2026-08-23. A follower page returned to a customer is now held indefinitely against that customer's name, and the effect above is correspondingly larger
• What would require revisiting this: enriching, joining across sources, or offering these routes as a monitoring or alerting product

Handles and display names in a reply thread are returned exactly as the platform published them. An earlier draft committed to hashing them; that was withdrawn before any comment data was processed under it.

If you appear in data we returned

• Access. Open the chat widget with the handle or profile URL. We search the stored responses and tell you what we hold, which calls it came from and when. We ask for enough to be confident you are the person named and no more
• Erasure. We delete every stored response containing you and null the stored parameters naming you. The billing row survives, holding the route, credit and timestamp, and no longer the identifier or payload
• Objection. The basis is legitimate interests, so you may object under Art. 21 GDPR. We stop unless we can show compelling grounds, and we tell you which happened
• Timing. Within 30 days of a request we can verify
• The limit of it. We hold what the platform published, and the platform is the controller of that record. Making an account protected stops it appearing in our responses at all, which is a more complete remedy than anything we can offer. Erasure here does not reach a copy a customer already downloaded

What we never store

Video, audio and image files. Media addresses in a response point at the platform's own network; we return the address and never fetch the file.

Automated processing

No endpoint sends your data to a language model. Nothing we operate performs automated decision-making or profiling within the meaning of Art. 22 GDPR.

Your rights

Where GDPR or UK GDPR applies you may request access, rectification, erasure, restriction, portability, or object to processing based on legitimate interests. Ask through the chat widget.

What erasure does. Every API key is revoked. Within 30 days the account record, keys and usage records are destroyed and the payment-provider link is severed. Usage records include the stored parameters and responses described above.

What survives it. Credit ledger entries and invoices are kept as financial records under a legal obligation, so they cannot be deleted on request. They are pseudonymised: the account becomes a random subject identifier and the link to any key is cut, so what remains identifies a transaction rather than a person.

You may also complain to your supervisory authority, which in the EU or UK is the data protection authority where you live.

Security

Keys are hashed, never stored in plaintext. API keys and Authorization headers are redacted from application logs at the point of emission. Application logs are kept 7 days.

Error monitoring. A failed request sends a report to Sentry carrying the exception and line of code, the HTTP method and the route path, and not the query string naming the account or post, not the request or response body, not the headers, not the values held by the crashed code, and not the server's log lines. Each is a separate route by which the identifier could arrive, and each is switched off rather than filtered, because a handle has no pattern a filter could key on. An error report carries no account identifier.

From 2026-09-26 the dashboard reports its own errors too, and that half differs in one way: an API report is sent by our server, so the coarse location Sentry derives is a data centre, while a dashboard report is sent by your browser, so the same mechanism locates you. We configure the reporter not to record your address and never store it ourselves, and we are not going to claim that scrubbing a field unsees a connection. A dashboard report carries the error, the page, and the browser and version. Not form contents, not the query string of any API call, not your session token, and not what you were looking up.

Subprocessors

An addition is published here before it begins processing customer personal data, so you can object under Art. 28(2) GDPR first. To be notified, ask through the chat widget.

All of them process within the EEA, the United States, or at a global edge under its own transfer framework. There are no other transfers.

Crisp receives what you decide to type. If you paste an API key, a customer's details or an identifier you looked up, it is in a third party's system and no filtering on our side sees it first. Redact it before you send it: describe the problem without the secret, and revoke a key from the dashboard rather than quoting it to us. The widget is anonymous: we do not pass the signed-in account's email to it, because that would hand a customer identifier to another system on every dashboard page rather than only when someone starts a conversation.

Changes

Material changes are published here with a new version and effective date, and notified to account holders before they take effect. New subprocessors are published before they begin processing.