Meta platform terms: data deletion callback

One shared Meta Platform Terms document governs Facebook, Instagram and Threads — no separate Threads-specific terms page exists. Key operational rules: an app cannot materially change its functionality or data-processing scope without going back through App Review, must delete Platform Data once it is no longer needed, and must implement a Data Deletion Request Callback URL (or an equivalent, clearly accessible self-service deletion path) so a user can actually have their data removed. No numeric rate limit is stated at the Terms level (rate limits live in the API documentation itself, not the policy).

TikTok bans overlaying watermarks/branding on shared content, requires a content preview with editable captions and explicit consent before upload, bans cross-posting scraped or foreign content, and self-imposes a roughly 15-posts-per-24-hours per-creator cap that an integrating app is expected to proactively check via the Creator Info endpoint rather than assume TikTok will silently reject an over-cap post.

YouTube's Developer Policies ban exceeding or circumventing quota, require explicit and specific prior user consent before automating any upload, comment, or like action — with the user retaining final authority over the action — and reserve broad audit/monitoring rights for Google.

X's Automation Rules, incorporated into its binding Developer Agreement, require explicit consent before automated replies or DMs, ban aggressive or spammy bulk actions, require bot-account transparency (disclosing the bot in the account bio), and explicitly prohibit posting identical or substantially similar content across multiple accounts — directly relevant to any multi-account scheduling workflow specifically.

LinkedIn's own API Terms of Use, Section 3.1(26), prohibits using the Content or the APIs "to automate posting on the LinkedIn Services" — read plainly, that sits in direct, unresolved tension with LinkedIn simultaneously running the Community Management API, a partner program specifically built to let third-party apps schedule and post. No reconciling carve-out for approved scheduling partners was found in the public Terms text. Separately, Section 4.1 bans storing or caching Content beyond what is expressly permitted, and Section 4.3 bars refreshing stored profile data other than on an automated schedule — both directly relevant to how a scheduler's caching and sync jobs are built.

Pinterest's Developer Guidelines require per-action user consent for publishing — "the end user must choose each Pin to be published" — which, read literally, implies fully automatic bulk-posting without a per-item confirmation step is not strictly compliant. A stricter, separate rule bans caching any Pinterest data outside a narrow analytics carve-out ("call the API each time you need to access information") — directly at odds with how most scheduling tools cache Pin and board metadata to render their own UI without re-fetching constantly. Neither tension has a visible official resolution; both are worth a product/legal review rather than an assumption either way.

Bluesky's Terms of Service ban compromising, bypassing, or abusing its systems, APIs, or rate limits, and apps that fail to act on known Terms or Community Guidelines violations by their users risk suspension. Telegram's Bot API allows roughly 1 message/second to an individual chat and about 30 messages/second in aggregate on the free tier (20/minute to the same group), with an opt-in Paid Broadcasts tier raising the aggregate ceiling to 1,000 messages/second for a per-message cost above the free threshold; both explicitly prohibit exploiting higher limits for spam or harassment, and require prompt deletion of user data on request or once no longer needed.