Official social embed policy contract

Reviewed: 2026-08-27 UTC

Research status: several providers document bounded official embeds for operator-selected public content, but the catalog cannot be promoted as one package. Meta, Telegram, and Pinterest have candidate surfaces for later, separate implementation packages. LinkedIn's official-code and intermediary restrictions need a provider-approved integration design; TikTok requires express written authority for this commercial use; Tumblr's endpoint and API-agreement boundary needs clarification; and X requires a developer account plus approval covering the exact product, use case, and any white-label distribution. Automatic account ingestion and a normalized cross-provider feed are not authorized by this report. Every future provider must remain isolated, live provider content must not be copied into DynoStatic, and visitors must choose before third-party resources load.

Implementation status: research only. The current Instagram, Facebook, LinkedIn, Telegram, TikTok, Pinterest, Tumblr, X, and generic Social Feed modules remain link_only; Facebook Comments remains the existing separately reviewed official_embed. No module readiness or public-rendering claim changes until a later implementation package satisfies this contract and its tests.

Primary sources

Meta: Instagram and Facebook

• Meta Embeds for WordPress — Meta's current official plugin documents tokenless oEmbed endpoints and supported public URL shapes for Instagram posts, reels, and profiles, and Facebook posts and reels. It also identifies the provider scripts loaded in visitors' browsers and states that rendering is subject to Meta privacy and platform terms.
• Meta Platform Terms and Meta Platform Policy — governing terms linked by Meta's official embed implementation.

Meta's official plugin is implementation evidence for the documented tokenless surfaces, not reusable WordPress code or permission to accept arbitrary provider HTML. It does not document a general Facebook Page timeline widget or an automatic Instagram/Facebook account feed for this package.

LinkedIn

• Availability of your content off LinkedIn — only content whose audience is Anyone can be embedded. LinkedIn documents text, article, image, video, live-video, and document posts; multi-photo posts and reposts with commentary are excluded. Source deletion removes the embed.
• Settings required to allow post embedding — the author controls whether otherwise public activity can be embedded.
• LinkedIn Embed Terms of Use — governs the unmodified Embed Code supplied through LinkedIn's embed generator, restricts modification and intermediary/service uses, and imposes use, privacy, and monetization conditions.

These pages document individual public posts, not a URL-only oEmbed contract or a general organization, member-profile, or feed-history widget. The reviewed workflow tells the publisher to use LinkedIn's generated “Copy code” output. DynoStatic cannot infer permission to reconstruct or modify that code, and accepting arbitrary pasted HTML would violate the product's security boundary. LinkedIn therefore remains link_only unless LinkedIn approves a narrowly specified integration or publishes a suitable URL-only contract.

TikTok

• Embed Videos — TikTok documents selected public-video embedding, visible attribution, source links, removal behavior, and its tokenless oEmbed endpoint.
• Embed Player — TikTok documents the direct https://www.tiktok.com/player/v1/{post_id} iframe and supported player options.
• Embed Creator Profiles — TikTok also documents a tokenless profile surface containing recent videos and engagement information; it has automatic playback behavior and is outside this package.
• Content Display — broader account/content access is a separate Display API product and is outside this tokenless package.
• TikTok Developer Terms of Service — prohibits commercial use of the developer services without TikTok's express written consent and imposes additional data, branding, and platform restrictions.

The player and oEmbed surfaces prove technical availability, not authority for DynoStatic's proprietary and agency use. TikTok remains link_only until the operator or product has the required written authority. Creator Profile embeds are additionally excluded because their multi-item, metric, privacy, and automatic-play behavior exceeds the selected-item boundary.

Telegram

• Post Widget — Telegram permits embedding a selected message from a public group or channel using its t.me link.
• Telegram Widgets — the official widget catalog distinguishes Post, Discussion, Login, and Share widgets.

The Post Widget is not a historical channel-feed API. This package does not use bot updates, login, or discussions as a substitute.

Pinterest

• Pinterest add-ons — Pinterest documents official Pin, Board, and Profile widgets and requires its pinit.js script only once per rendered page.
• Pinterest Developer Guidelines — restrict storage, combining Pinterest account information with other services, scraping, modification, attribution, filtering, and uses involving machine learning.

Pinterest is the provider in this review with a documented Board widget in addition to selected-item and profile widgets. Instagram and TikTok also document profile surfaces, so their existence must not be misrepresented. Pinterest widgets must remain standalone provider views and must not supply records to a generic mixed feed, local corpus, filtering system, or AI feature.

Tumblr

• Embed Basics — Tumblr documents selected-post embeds, source attribution, interaction, live edits, deletion behavior, and a whole-blog script.
• Tumblr API documentation — Tumblr's official documentation describes oEmbed and separately documents authenticated API access, but its recorded endpoint examples and the currently observed live endpoint are not sufficiently consistent for readiness.
• Tumblr API License Agreement — applies terms, registration/credential expectations, display restrictions, and data-use duties to applications interacting with Tumblr's services and API.

The currently observed oEmbed route uses https://www.tumblr.com/oembed/1.0, while older official material records a different path. The whole-blog script can also originate from a user-controlled custom domain. DynoStatic will not allow arbitrary script hosts, assume an undocumented exemption from API registration, or freeze a disputed endpoint into the public contract. Tumblr therefore remains link_only pending current written documentation or Tumblr confirmation of the tokenless selected-post boundary.

X

• oEmbed API — X documents unauthenticated oEmbed for selected posts and supported user/list timeline URLs, including the dnt option.
• X Publish — states that embedding X content constitutes agreement to X's Developer Agreement and Developer Policy; transport without an authentication header does not waive those product terms.
• Embedded Posts — official embeds preserve source attribution, actions, media, and current provider state.
• Display requirements — displayed X content must not be materially altered and must retain X's identity and actions.
• Developer Policy — requires a developer account and approved intended use, notification and approval for substantive changes and white-label versions, Enterprise access when product scope requires it, a service privacy policy, consent when X content promotes a product or service, separation from advertising, legally sufficient browser-data/cookie disclosure and consent, child-directed tailoring safeguards, and contact above 10 million daily embed impressions.

For a proprietary, self-hosted multi-website product, an authentication-free HTTP request is not proof of an account-free integration right. X remains link_only until authority explicitly covers DynoStatic's distributed operator and agency/white-label model and the exact use case.

Provider surfaces and terms can change. Re-review the primary pages and endpoint behavior before implementing a policy-version change or promoting any module from link_only.

Researched product surface

The existing names may remain for catalog continuity, but setup and public copy must say exactly what is rendered. For example, Telegram is “selected posts,” not a synchronized feed. Unsupported providers and URL shapes remain safe outbound links rather than being silently upgraded.

Threads has a current Meta tokenless embed surface, but DynoStatic has no dedicated Threads module in this package. Adding one requires its own catalog/UI decision and tests; the generic Social Feed must not silently create an undeclared module capability.

Persistence and content lifecycle

1. Persist only the operator-entered canonical HTTPS URL, provider key, display order, privacy choice, and a small allowlisted set of presentation options. Do not persist provider-returned titles, author details, captions, media, reactions, comments, or embed HTML.
2. Treat an oEmbed response as short-lived rendering material, not imported content. If a server-side exchange is required, generate the provider view on demand or retain it only in the existing bounded transient cache; never put it in content export, backups, local workspaces, AI context, search indexes, static bundles, webhooks, or Automation payloads.
3. Source edits, moderation, privacy changes, and deletion are authoritative because the live official embed renders provider state. A failed or unavailable embed shows the canonical source link and an accessible unavailable state; DynoStatic does not preserve a stale visual copy.
4. Removing a configured item deletes its URL and local options. Disconnecting or deleting a website needs no provider credential revocation because this package owns no social account token.
5. Do not mix provider content with another provider or put it into review ratings, testimonials, CMS entries, generated summaries, sentiment analysis, or model training. An operator may place separately labeled provider widgets on the same page, but DynoStatic does not normalize, rank, filter, export, or claim ownership of their contents. The current generic Social Feed remains link_only.

URL and server-fetch boundary

• Accept HTTPS only and validate a provider-specific canonical host and path grammar. Reject userinfo, non-default ports, fragments when irrelevant, deceptive suffixes, IP literals, encoded host/path ambiguity, control characters, and credential/token-like query parameters.
• Store the validated canonical input rather than a redirect destination. Shortened/share URLs are not enabled by the current runtime. A future provider may accept one only after introducing a bounded manual redirect loop that validates DNS/IP and provider URL grammar before every hop and at the terminal URL. The existing outbound client intentionally disables redirects and does not supply that workflow.
• Never fetch an operator-controlled URL. Where oEmbed is necessary, send the validated public URL only to a fixed, code-owned provider endpoint. The implementation package must add a provider-response transport that retains the current DNS/IP, timeout, and body-size protections while also bounding accumulated headers, requiring the exact allowed JSON media type, rejecting content-type ambiguity, and validating the complete JSON object shape. The current OutboundHttpClient is not by itself an acceptance artifact for that contract.
• Do not render provider-returned HTML in the administrator origin. Parse only fields required to construct the reviewed embed, or place strictly sanitized material inside the future purpose-built isolated response route. Direct, documented iframe URLs are preferred when they preserve required attribution and behavior.
• No API keys, OAuth credentials, copied cookies, browser automation, undocumented endpoints, scraping, or arbitrary administrator-pasted embed code are part of this package.

Browser, privacy, and security boundary

Third-party embed code can track visitors and executes outside DynoStatic's control. Every provider item therefore starts as a local placeholder containing the provider name, privacy notice, canonical outbound link, and an explicit “Load” action. A site may connect that action to an applicable consent category, but lack of consent must preserve the placeholder and link. There is no eager server or browser preconnect to a provider before that choice.

After consent, load each item through a purpose-built isolated HTML response route, never directly in the administrator page or host-site DOM. That future route must emit a provider-specific Content Security Policy and sandbox with only the exact frame, script, image, media, style, and connection origins verified during implementation. The current media host emits direct iframes and some existing presets grant allow-same-origin; it does not satisfy this contract. The new route must not grant allow-same-origin merely to make a script work. A provider surface that cannot function under an acceptably isolated policy stays link_only. Validate postMessage origin and schema if player controls are implemented.

The implementation must also:

• use one provider script per isolated document even when several items render;
• bound item count, response bytes, dimensions, and render time;
• lazy-load below-the-fold embeds without layout shift;
• prevent horizontal overflow at 390, 768, and 1440 CSS pixels;
• give every frame a meaningful title and every placeholder/load/fallback control an accessible name and keyboard path;
• disable autoplay by default and avoid requesting microphone, camera, geolocation, clipboard, payment, or download permissions;
• force dnt=true for X posts and timelines, irrespective of site category;
• preserve provider-supplied attribution, links, controls, and appearance instead of recoloring or rewriting provider content; and
• provide operator-facing disclosure that provider terms, availability, cookies, and visitor data processing remain provider-controlled.

This is a browser feature implemented by PHP-generated markup and ordinary JavaScript assets. It adds no Node, daemon, cron, shell, or Composer-at-runtime requirement to a deployed shared-hosting installation. A future endpoint may send no provider credential at request time, but that transport fact never removes provider account, approval, operator disclosure, or consent duties; X in particular remains blocked on an approved product/use case.

Provider-specific implementation notes

Meta

Use fixed Meta oEmbed endpoints and the currently documented URL patterns. The server response is untrusted and bounded. Public profiles are supported only where Meta's curr