Privacy Policy

[to be confirmed: legal entity] ("SocialPipe", "we") operates the SocialPipe API. This policy explains what we hold, why, and for how long.

Controller: [to be confirmed: legal entity], [to be confirmed: registered address]. Contact: privacy@socialpipe.dev. [to be confirmed: dpo or eu representative]

What we hold about customers

We store only a SHA-256 hash of each API key. A database disclosure does not yield working keys.

We never write raw client IP addresses. Every request to the API carries an API key, so rate limiting counts against the key rather than against an address.

We do not record which posts or accounts a customer looked up. Usage records carry the route and the credit count, never the identifier that was requested. This matters more than it used to: on nine of our twelve routes that identifier names a person, so keeping it would turn a billing table into a record of who our customers are researching.

What we hold about people who are not customers

The API returns public post, profile and follower records from X (Twitter). Those records describe people who never signed up for anything, and this section says plainly what happens to their information. It is the most important section in this policy — read it before the rest.

Version 5 of this policy said we minimise on the way in rather than promising to clean up afterwards. That claim was withdrawn in version 6 and stays withdrawn. 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.

What that means concretely:

• A response contains whatever the platform published about the account or post you asked for — which typically includes a handle, a display name, a biography, a profile image, account creation date, and follower and engagement counts. On a timeline it includes the same information again for any account that was quoted, replied to or mentioned
• We add nothing. We do not enrich a record, combine it with another source, link it to a different platform, or infer anything from it. Everything in a response is retrievable from X itself without an account
• We keep a copy only in a response cache, for 12 hours by default and at most 30 days if the customer asks for a longer window. It expires automatically; there is no archive and no second copy
• The customer decides what happens next. Anyone who stores this data, builds profiles from it, or combines it with other sources is doing so on their own legal basis. Our terms say so, and it is a real obligation on them rather than a disclaimer

A store we have built and have not switched on

We are telling you about this before it holds anything, which is the same discipline we apply to a new subprocessor and for the same reason: the moment to object to a change in processing is before it starts.

What it would be. Our software can record, against each call, the parameters the customer sent and the response we returned — so that a customer can read back their own history and so that a disputed response can be examined without asking the platform again. It would live beside the billing record for that call, which already names the customer.

It is switched off. The setting that enables it is zero on every system we run, and while it is zero nothing is written to either field. Everything above this section describes what we actually hold, and remains accurate.

It cannot be switched on quietly. Our build refuses the combination: an automated test fails if the setting is enabled while this policy still says there is no archive and no second copy. So this document changes first, with a new version and a changelog entry, or the change does not ship. That is the same mechanism we use to keep the route list and this policy in step, and it exists because a promise nobody can verify is not a promise.

What we would owe you if it were on, stated now rather than later. The paragraph below titled If you appear in data we returned tells you we have no way to search for you. That is true of a cache keyed on a fingerprint of a request. It would stop being true of a stored response, and being able to find someone is what creates the obligation to answer them properly. We are not prepared to make that change without publishing it, taking legal advice, and saying in this document how an access or erasure request would then be handled.

Five routes return other people in bulk

Most routes answer a question about the account you named. These five answer with lists of other people, and we name them individually rather than describing them in general terms:

A single call to any of these can return dozens to hundreds of people, none of whom is the subject the caller asked about. Each carries that person's handle, display name and profile image. Nothing is hashed, redacted or aggregated.

We treat this as a distinct processing operation, not as more of the same. Returning one public profile and returning somebody's follower graph are different in kind, and the balancing test under Art. 6(1)(f) is recorded separately for these five:

• Our interest: providing a developer with data X already publishes, through one documented interface rather than through scraping infrastructure each customer maintains separately.
• The data: public by the platform's own design and the account holder's settings. A protected account's followers are not returned to us at all. We collect nothing that requires a login to see.
• Effect on the individual: this is where the honest answer is not "none". A follower list is a social graph, and social graphs support inferences an individual post does not. What limits it on our side is that we build no such inference, retain nothing beyond a short-lived cache, and never link a person to the customer who requested them.
• Safeguards: transient retention with automatic expiry; no user_id on the cache key, so a cached record is about a public account and not about who asked; no record of which identifiers a customer requested; a contractual prohibition 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. Two of those safeguards are the ones the store described above would remove, which is why it is off and why turning it on requires this balancing test to be re-run rather than edited around.
• What would change the answer: enriching, joining across sources, retaining beyond the cache, or offering these as a monitoring or alerting product. We do none of those, and doing any of them requires revisiting this section before it ships.

Comments are available, reversing version 6. Version 5 committed to hashing commenter handles and display names; version 6 withdrew that commitment and removed the comment endpoints rather than publish a promise the software could not keep. Version 7 takes the other route: the endpoints ship and this document states what they return instead of promising a protection that does not exist. Handles and display names in a reply thread are returned exactly as X published them. No comment data was ever processed under the version 5 wording.

If you appear in data we returned. We hold no account for you and no way to search for you: our cache is keyed on a fingerprint of the request, not on the people in the answer, so we cannot look you up without knowing the exact request that would produce you. Anything we hold expires on its own within 30 days and typically within 12 hours. X is the controller of the record it published and is where an access or erasure request can actually be answered — including making an account protected, which stops it appearing in our responses at all. Email privacy@socialpipe.dev and we will tell you honestly what we can and cannot do.

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 and AI

No endpoint sends your data to a language model. Version 4 of this policy described a summarization endpoint that submitted text to a third-party provider. That endpoint has been removed from the API. Nothing we operate performs automated decision-making or profiling within the meaning of Art. 22 GDPR.

We do not carry out automated decision-making producing legal or similarly significant effects.

Your rights

Where GDPR or UK GDPR applies you may request access, rectification, erasure, restriction, portability, or object to processing based on legitimate interests. To exercise any of these, email privacy@socialpipe.dev.

What erasure does. Access is cut off: 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, wherever that store is switched on.

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

You may also complain to your supervisory authority. [to be confirmed: supervisory authority]

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 retained for 7 days.

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.