Configurator

The Anchor.Social dashboard at https://embed.zeeker.com creates, previews, publishes, and deploys your embeds. Every installation references a saved data-zeeker-config="<id>".

Start by creating a community in the dashboard, or selecting an existing community you administer. Your community supplies the shared identity, features, and access rules. You can manage its settings in Admin Center.

A simpler setup flow

The builder has three main steps:

1. Choose an experience, such as Comments, Community Feed, or Group Chat, or start with a custom configuration.
2. Place it with an Anchor button, your own button, on the page, or full screen. Preview desktop and mobile placement without creating separate website and app configurations.
3. Preview your choices, give the embed a name, and choose its Embed language. Change style and Access settings are optional. Choose Create draft when ready.

Creating a draft does not publish it. Customize the saved draft, publish it, then open Deploy for website, WebView, or native SDK instructions. Your deployment target is chosen there; it does not change the experience you authored.

An experience supplies starting values for ordinary community and embed settings. It does not lock a separate product mode. Fixed embeds organize customization under Elements, Appearance, and Restrictions; floating embeds use Triggers, Appearance, and Restrictions. Community-owned settings remain in Admin Center rather than being duplicated as conflicting controls.

Community ceiling

The editor first evaluates the selected community. Visibility, membership, post types, badges, default sort, related/external-post policy, chat availability, moderation, SSO, and whitelabel settings come from the community.

Anchor.Social can narrow those capabilities for one placement. It cannot enable a post type, chat, content scope, or identity path that the community does not allow. Unavailable choices are disabled with an explanation rather than silently replaced.

Customize an Element without starting over

For a saved experience, Customize keeps related decisions together:

1. Placement selects how the existing Zeeker surface enters the host: Anchor launcher, a host-owned button, fixed inline, or full screen. Use the Desktop, Mobile, or Both device scope before changing device-specific geometry.
2. Elements controls fixed content, while Triggers controls floating activation and its action tray. Less common surface behavior remains in collapsed sections with the relevant controls.
3. Restrictions controls connection, identity, participation, and exits from the experience. It does not change the selected Social or Chat feature.

The launcher tray can use any existing Zeeker action: Discussion, Community, Chat, Heart, inline Reactions, Share, Save, or Hide. The Element's required opener stays enabled—Chat for Group Chat and MOD Chat, Community for Support Forum and Community Feed, and Discussion for contextual Elements—but the other actions can be enabled and reordered. Heart and inline Reactions are two presentations of the same reaction capability, so only one can be active. On mobile, the compact Heart action replaces the six-button inline reaction strip.

Desktop and mobile action lists are authored independently. Select Mobile to enable the host-style bottom tray, change its actions, or reorder them; select Desktop for the floating launcher. Selecting Both applies shared launcher styling where appropriate without discarding an explicit mobile tray. Moving the Element between launcher, host trigger, inline, and full-screen placements preserves the saved desktop and mobile tray choices so returning to a placement does not rebuild the action list.

Actions are constrained by the real community and access policies, not by an arbitrary preset allowlist. For example, Chat is disabled when community Chat is unavailable, Share is disabled under Strictly containerized outside access, and Save is disabled for Embed-only content. The editor explains the applicable constraint beside the action.

The launcher shown in Live preview is reactive: enabled actions, order, size, color, position, and the mobile bottom-tray choice update as they are changed. Activate the Element opener to inspect the selected live surface. Use the pencil on a launcher/tray—or the pencil on a fixed Element in the canvas—to jump directly to its controls instead of searching through the sections.

Content

Content controls select an existing Social composition:

• Community, thread, chat, URL, or host object — the canonical content source.
• Allowed content types — a subset of the Community's root-post types for feeds, or reply types for contextual collections attached to a host object.
• Thread resolution — the canonical URL or stable host object used to resolve an existing Zeeker thread. Reply ordering inherits Social and community rules; Embed does not add a separate aggregation or sort control.
• Standard community card — show or hide Social's ordinary community identity/about card.
• Community search — show or hide Social's existing community-scoped search when the selected surface supports it.
• Top header — show or hide a generic Embed header and configure its title treatment.
• Contextual root — show or hide the link/object/post that owns a contextual discussion.
• Post and post header — control which normal post-page regions remain visible in the focused layout.
• Related posts — inherit the community policy, narrow it to community-only content, or turn it off for this embed. The embed cannot enable external related content when the community disallows it.
• Composer — show the standard Social composer when participation allows it and place it above or below the content.
• Post opening — open a post inside the same embed or in a new page.
• Outside access — choose Strictly containerized (blocked), Profiles only, or Profiles, posts & communities. This is a navigation/discovery boundary, separate from the server content boundary selected under Connection to Zeeker.
• Review summaries — independently show the shared rating average/distribution and request the optional grounded AI review summary for review-filtered surfaces.

These controls never add Element-specific tabs, headers, dashboards, cards, or content types. For example, the Support Forum preset uses an allowed question post type in the normal community feed; the Reviews preset uses Social's existing review fields.

The information box used by an implementation preset is not an editor control. Community admins and Embed publishers cannot enter arbitrary HTML, replace its markup, or toggle it independently. When the Support Forum preset is applied, Embed programmatically supplies the bounded support box and places it immediately above the feed-filter header. It inherits the adjacent Embed border treatment, remains an opaque themed surface on a transparent fixed canvas, and is capped at 300px high.

Layout

• Element placement — Anchor floating launcher, your own button/trigger, fixed inline, or full-screen. Advanced custom configs can still use the lower-level floating, fixed, anchor, pill, and trigger containers.
• Scrolling — let the host page own scrolling or use an internal scroll region.
• Loading — infinite loading or an explicit Load more action.
• Dimensions — stable desktop and mobile sizes for fixed placements.
• Transparent background — allow the host section to provide the backdrop.
• Container border — generic on/off, width, solid/dashed/dotted style, color, and radius controls.

A fixed or anchor surface is part of the page and therefore has no close button. An overlay such as a floating panel, drawer, or sheet retains the dismissal control required by that container.

Group Chat and MOD Chat default to the Anchor launcher: a floating Chat action on desktop and a Chat action in the mobile tray. They can also use a host-owned trigger, fixed inline placement, or full-screen placement when explicitly selected. Changing placement never changes the underlying Chat destination.

Appearance

• Color scheme — auto, light, or dark.
• Background — transparent, automatic, or an explicit surface color.
• Accent and font — host-appropriate brand overrides.
• Container radius and border — outer integration styling.
• Top header — optional title/subtitle/logo, background, text, and bottom-border treatment.

The generic top header is independent of Social's internal community or post header. Showing it does not create a new Element feature. Element-specific radius applies only to the outer embed/container/header boundary; internal post cards, reply rails, action trays, composers, badges, search, and summaries keep the canonical Social design. See Theming.

The theme beside Live preview simulates the host. An embed saved as Light remains light when that host control switches to dark; an embed saved as Dark remains dark. Only Auto follows the simulator.

Language

Open a saved configuration's Appearance → Language and choose Embed language. Supported languages are English, Spanish, French, German, Arabic, and Hebrew. English is the default for new and existing configurations. Arabic and Hebrew automatically use a right-to-left layout.

The saved language applies to embedded interface labels and layout. Authored member content stays in its original language. The embedded interface has no visitor language selector and does not inherit a language choice saved in standalone Zeeker Social.

The dashboard's signed live preview can show an unsaved language change before it is published. A public demo URL cannot override the saved language.

Access and identity

• Connection to Zeeker — Connected participates in ordinary Social. Embed only uses an exact config-owned partition when the deployment reports the complete server content-isolation capability; it does not duplicate or replace Outside access.
• Who can view — public or authenticated, subject to community visibility and membership.
• Who can participate — read-only, authenticated, or named guest participation. Guest-enabled surfaces retain login/signup and add a display-name-based Continue as guest choice.
• Sign-in method — Zeeker login, community SSO, or either, limited by the community's configured SSO capability.
• When to sign in — on a gated action, on load, or managed by the host.

SSO provider configuration stays in the Admin Center. The embed only narrows which configured identity paths it may use and when the flow begins. Community access and moderation remain authoritative.

Content isolation and the strict container

Embed only (networkMode=embed_only) controls where the server stores and resolves content. It gives one published config immutable ownership of its posts, replies, relationships, and eligible Chat data and excludes that data from ordinary Social discovery. Strictly containerized (outsideAccess=blocked) controls what the visitor can discover or open outside the focused Element. It can also be applied to a Connected embed, but doing so does not isolate that Connected content on the server. Embed only always applies the strict navigation boundary; a stale or API-authored permissive outsideAccess value is ignored at runtime.

Strictly containerized Search queries posts and replies for the exact configured community and exposes only the Posts result surface. It does not search or suggest people, other communities, or topics. Redundant community links and tags, profile/community click targets, and user/community hovercards are withheld so identity chrome cannot become a second discovery path.

On a Connected embed, choose Profiles only when authors may open their canonical Social profiles but post, community, topic, and arbitrary HTML exits should remain blocked. Connected surfaces may retain user-profile previews in this mode. Choose Profiles, posts & communities when the host intentionally permits the normal canonical Social destinations and discovery supplied by the selected surface. Those two looser choices are disabled for Embed only because its closed server partition must not expose navigation into wider Social.

Unsupported policy fails closed

Embed only and named guests can be published and booted only while every participating service reports the required exact-config storage, authorization, and signing capabilities. Missing prerequisites disable the choice; the dashboard does not reinterpret it as Connected or route data into canonical Social/Chat storage.

Selecting Guest atomically selects Embed only. The server rejects Guest with Connected even if an older dashboard or direct API client submits it. The identity sheet keeps login/signup and adds a capability-gated guest option that collects a display name before the first post, reply, or Chat message. It is not the authenticated Anonymous attribution setting. Social and Chat each use their own exact-config storage, revision/revocation checks, and abuse limits.

An Embed-only runtime receives a short-lived scope for one exact config. It can see only that partition, while ordinary Social excludes the isolated content from feeds, search, profiles, notifications, SEO, and shared analytics. Every protected request checks the current config revision and published state, so editing, pausing, or unpublishing the config invalidates an already-running client's old scope on its next request. See Connection and identity policy.

Host-triggered and full-app controls

Trigger mode renders no Anchor launcher. Save a host CSS selector or call window.zeeker.open() from the host's own button, tab, menu item, or bottom-tray action.

The configured destination can be an existing page discussion, community app, community chat, or eligible private MOD Chat. Full-screen community app mode can expose its normal mobile navigation and profile destination. A focused inline or panel Element does not add a global Social button. If outside access permits profiles, the profile action opens the signed-in user's canonical page on zeeker.com.

Full-screen mode does not add a second Zeeker close button when the host app already owns navigation away from that screen.

Live preview

The preview loads the same Social implementation the saved settings select. It does not substitute a fabricated Comments, Reviews, Support, or Q&A mockup. Website previews place the surface inside a representative desktop page; mobile previews place it inside a responsive app/page context and use host-owned navigation where appropriate.

Draft overrides require a short-lived, config-bound signed preview token. A verified preview is read-only across Embed, Social, and Chat and is returned private/no-store. Public query parameters cannot grant preview authority.

Deploy

Deploy provides the relevant website, native iOS, Android, and WebView instructions. Contextual installs pass a stable host object so web and mobile can resolve the same article, product, lesson, event, or app record.

Publishing and history

Publishing versions the config, and History → Restore creates a new version from an older saved payload rather than destructively overwriting history. Connected clients receive the updated version on their next config refresh. For Embed-only clients, every edit advances the authorization revision: an old short-lived scope stops authorizing protected Social or Chat requests immediately, and the runtime must obtain a scope for the new published revision.

Anyone with the admin role on the parent community can edit its configurations. Moderators can inspect Embed configuration and use the moderation tools allowed by their community role. See Roles.