Technical overview

How Nidget works in production.

A practical guide for editorial, product, platform, analytics and security teams reviewing how Nidget reaches a story page—and what remains under the publisher’s control.

01 · System at a glance

A small delivery surface.

The publication owns the article. Nidget supplies an isolated interactive and the services behind it.

Your CMS

Stores the iframe and optional helper script.

Nidget delivery

Serves the published React widget at a stable URL.

D1 records

Holds workspaces, drafts, versions and analytics.

R2 assets

Stores uploaded media and publication fonts.

Cloudflare Workers

The application and published widget routes run on the Cloudflare Workers runtime.

Cloudflare D1

Structured workspace records, widget configurations, published versions, audit history and analytics are stored in D1.

Private R2 storage

Original uploads are stored in a private R2 bucket. A published asset is served only when the live widget configuration references it.

02 · Delivery

One stable URL. Versioned underneath.

Editors can change what is live without asking the newsroom to replace embed code on every story.

1

Draft

Editing happens against a workspace-scoped draft. Concurrent revision checks prevent one editing session from silently overwriting another.

2

Validate and publish

Nidget validates the widget configuration, creates an immutable published version and records a publication event.

3

Resolve the live version

The public /w/:id route resolves the widget’s current publication and applies the workspace brand system.

4

Serve referenced assets

Published media and fonts receive long-lived immutable caching. Unreferenced private workspace assets are not exposed by the public widget asset route.

5

Roll back without re-embedding

Making an earlier published version live updates the publication pointer while preserving the widget URL and audit history.

03 · Iframes and URL parameters

Contained on the page. Responsive to its context.

The iframe is the security and layout boundary. The small helper script adds automatic height and host-page context.

<iframe data-nidget-embed
  src="https://nidget.app/w/widget-id?theme=auto"
  title="Interactive story" loading="lazy"
  style="width:100%;height:480px;border:0">
</iframe>
<script async src="https://nidget.app/embed.js"></script>
?theme=auto

Uses the host page’s dark-mode signal when the helper is present, or the reader’s system preference when opened directly.

?theme=light

Keeps the widget in its light theme even when the host or operating system is dark.

?theme=dark

Forces the published widget into its dark theme.

?dark=true

Legacy dark-mode flag supported for existing integrations.

?isMobileApp

Marks a mobile-app webview context. It can be placed on the widget URL or forwarded from the host page by the helper.

What the helper reads

The Nidget iframe list, viewport width, iframe container width, the host page URL, host dark-mode state and the presence of isMobileApp. The page URL is reduced to origin and pathname before analytics storage.

What happens without it

The iframe still renders and remains isolated. Automatic height, host-theme forwarding and exact article-path reporting are reduced, so the CMS should provide a suitable fixed or responsive height.

04 · Analytics

Measure the interaction, not the reader.

Workspace default: off

Published widgets do not send audience analytics or set the analytics cookie unless a workspace editor enables consent-managed collection or the testing-only mode.

Publisher consent gate

Consent-managed embeds wait for an affirmative signal from the publisher’s consent system. A missing or refused signal means no collection.

Iframe impressions

After consent, a load is counted only when a published widget runs inside an iframe. Direct previews and standalone visits are excluded.

Approximate unique browsers

A random Partitioned, Secure, HttpOnly cookie is hashed with the publisher domain. The raw identifier is not written into analytics records.

Article locations

The publisher hostname and pathname support placement reporting. Query strings and URL fragments are not stored as the article location.

Engagement events

Formats emit defined actions such as quiz starts and completions, answers, navigation, media playback and other widget-specific interactions.

Useful summaries

Workspace and widget views report impressions, unique browsers, engagement rate, locations and format-specific measures across 7, 30 or 90 days.

Fail-open collection

Analytics requests are asynchronous. A collection failure does not interrupt the published widget experience.

Workspace-controlled CMP integration

A workspace editor chooses the analytics policy once in Settings. Consent-managed mode exposes the copy-ready publisher script. Testing mode needs no script and is intended only for controlled development or staging traffic—not a live audience.

05 · Product and security review

For the team whose job is to protect the newsroom.

The useful review is not “do we like widgets?” It is whether the integration has a narrow surface, clear controls and an acceptable exit path.

Third-party JavaScript
The helper script is optional. It resizes Nidget iframes and passes limited host context; a fixed-height iframe works without it.
Allow the iframe origin only, omit the script, and manage height in the CMS if policy prohibits third-party scripts.
Page safety
Widget UI runs inside an iframe, so its styles and application code are separated from the article DOM. Nidget code widgets use approved components, attributes and classes rather than arbitrary JavaScript.
Review the generated embed, apply a narrow frame-src rule, and test it in the publication’s staging environment.
Publishing control
Drafts are not public. Publishing creates a versioned snapshot, while rollback points the same public URL at an earlier published version.
Use workspace roles, version history and the audit log; remove or block the iframe at the CMS for an immediate publisher-side stop.
Audience data
Audience analytics is disabled by default at workspace level. Editors can enable consent-managed production analytics, or a clearly labelled testing mode that starts immediately without a consent script on controlled development and staging pages.
Keep analytics off, or connect the publisher CMP to Nidget’s consent API. Withdrawing consent stops events and removes the audience analytics cookie.
Vendor and outage risk
A Nidget outage affects the embedded widget area, not the host article. The publication retains control of the page and can remove the embed independently.
Agree escalation, retention, SLA, residency and exit requirements during review; discuss self-hosting when managed delivery is not acceptable.

Suggested approval checklist

Confirm the Nidget origin, CSP frame-src and optional script-src rules, staging behaviour, accessibility review, consent timing, data retention, incident contact, ownership and removal process.

Questions that need a commercial answer

SLA, support response, data residency, retention commitments, subprocessors, security-testing evidence, DPA terms and self-hosting scope depend on the agreed deployment—not the embed code alone.

Reviewing Nidget?

Bring us the hard technical questions.

We would rather document a constraint clearly than hide it behind a feature list.

Start a technical review

The publisher always retains the bluntest control.

Remove the iframe, omit the helper script, block the origin in CSP, or take the widget offline from the Nidget workspace.