Subprocessors

[to be confirmed: legal entity] ("SocialPipe", "we") engages the subprocessors below to provide the API. This list is versioned: we publish additions here before they begin processing customer personal data, so customers have the opportunity to object under Art. 28(2) GDPR.

To be notified of changes, email privacy@socialpipe.dev and ask to join the subprocessor notification list.

Current subprocessors

Card numbers are entered directly with Stripe and never reach our systems. We do not receive, store or process them.

Planned, not yet engaged

Named here because our architecture anticipates them, and because Art. 28(2) gives you the right to object before a subprocessor starts processing rather than after. None of these holds or receives any data today. Each moves into the table above, with a new version and a changelog entry, before it processes anything.

Transfers outside the EEA

None. Every subprocessor in the table above processes within the EEA, the United States, or at a global edge under its own transfer framework, and no endpoint sends customer or extracted data anywhere else.

Version 6 of this list named Xiaomi (MiMo) on a Singapore endpoint, for AI summarization. The endpoint that called it has been removed from the API, and with it the only transfer that relied on Standard Contractual Clauses. Nothing is transferred to Singapore.

What we send, and what we return

We send a subprocessor a public identifier and nothing else — a username, tweet id, search keyword, country code or pagination cursor. Never an account email, an API key, a customer identifier, or anything about who is asking. A search keyword is the one input a customer composes freely rather than copies from a URL, and it is forwarded verbatim; do not put anything in it you would not send to a third party.

TikHub keeps its own copy for 24 hours, and we did not say so until version 10. Every response it returns carries a note in its envelope: "This response is cached and accessible via the URL below for 24 hours at no extra cost. The cache is for request tracing only." The address is a signed URL, we strip that part of the envelope so no customer ever receives it, and we do not use it. It is disclosed here because it is a real retention of real data at a third party, and a subprocessor list that describes only the parts we chose is not a subprocessor list.

What comes back is returned to the customer unchanged. As of version 8 the API is a router: the response body is the platform's own record of a public post or account, passed through without selection or alteration. That record contains information about the people who published it — handles, display names, biographies, profile images, follower counts — and about anyone they quoted or mentioned. We do not add to it, join it against another source, or infer anything from it. Our own copy is held in the response cache under a declared expiry and nowhere else.

Version 7 of this document said raw commenter handles are hashed before anything is cached, returned or logged. That commitment was withdrawn in version 8 and stays withdrawn. A router has nowhere to perform such a transformation.

Version 8 went further and removed the comment endpoints. Version 9 puts them back, and adds three routes that return social graphs. twitter/comments, twitter/comments-latest, twitter/followers, twitter/following and twitter/retweeters each return a page of accounts that are not the subject of the request, with their handles, display names, biographies and profile images intact. TikHub processes those requests and returns those records; we pass them through and cache them under the declared expiry. Nothing is hashed, and this document no longer implies otherwise. The reasoning, including the Art. 6(1)(f) balancing for bulk social-graph retrieval, is in the Privacy Policy and in ADR-035.

What we store ourselves

Not strictly a subprocessor question, and included because a reader of this page is trying to work out where their data ends up rather than which of the answers is contractual.

A response cache in Redis, at Railway, 12 hours by default and at most 30 days. Keyed on a fingerprint of the request; it carries no customer identifier.

A billing record per call in Postgres, also at Railway: the route name, the credit count, whether it was a cache hit, and when. Not what was asked for.

A capability to store the request and the response beside that billing record, which is switched off. The setting that enables it is zero on every system we run, nothing is written while it is zero, and our build refuses to enable it while the Privacy Policy still says otherwise. That policy's section A store we have built and have not switched on is the fuller account, including what we would owe a data subject if it were ever turned on.

What is never sent to a subprocessor

• Video, audio or image files. Media addresses in a response point at the platform's own network and we do not fetch them
• Account, customer or end-user data of any kind
• API keys in application logs. Keys and Authorization headers are redacted at the point of emission

Change log