Build a public live-stats widget for your marketing site

Why this matters

Marketing wants “live, real numbers.” Engineering doesn’t want to ship a backend for it. So the marketing site stays static, with hardcoded testimonials and a “10,000+ users” badge that hasn’t updated since 2023.

Agentry can help, but the safe path starts by proving which metrics are answerable from the saved signal map, latest verify report, answer contracts, and event/property metadata. If a ready metric is publishable through a real query blueprint, you get a returned public URL scoped to that query; if it needs custom rollups, the agent should use a protected/server-rendered route instead of pretending every number has an embeddable URL.

Plausible Analytics did this for their own public dashboard and it directly contributed to their growth. Developer-tool startups should do it only for metrics they are comfortable making public and can prove from live data.

What you get

• Returned public URLs only for ready metrics backed by real query blueprints
• CORS-open, ratelimited, no signups required
• Embed-friendly: drop in an <iframe> or render server-side with fetch
• Updates every time your data changes (no caching headaches)

Walk through it

# Server-side route sketch:
# - owner/server calls analytics/query for customer and monthly error counters
# - owner/server calls GET /v1/projects/:project_id/cases for open investigations
# - the public page renders only the aggregated numbers, not AGENTRY_PRIVATE_API_KEY

<div class="live-stats">
  <div data-metric="customers">1,247 customers</div>
  <div data-metric="errors">18,392 errors caught this month</div>
  <div data-metric="open-cases">47 active investigations</div>
</div>

If you want public-query URLs instead of server-rendered counters, I should add real query blueprints for the headline counters first.

The output

✅ Server-rendered public stats route planned

  "Total customers"          → 1,247
  "Errors caught this month" → 18,392
  "Active investigations"    → 47

Public-query URLs are not created until the exact counters have real query blueprints.

Security notes:
  • AGENTRY_PRIVATE_API_KEY stays server-side
  • The public page renders aggregated numbers only
  • If you later publish blueprint-backed public queries, revoke any time with DELETE /v1/projects/:project_id/public-queries/:publication_id

Setting it up

Use public-query URLs only for metrics that are verified as answer-ready and backed by real query blueprints. For custom headline counters, render them server-side from analytics/query, cases, or deploy reads and expose only aggregated values.

Iframe embed (simplest — works in any HTML context):

<iframe src="PUBLIC_URL_FROM_AGENTRY"
        width="240" height="100" frameborder="0" loading="lazy"></iframe>

Server-side render (for Notion-friendly markdown, static-site templates, RSS feeds):

// In your page loader
const publicUrl = "PUBLIC_URL_FROM_AGENTRY";
const res = await fetch(`${publicUrl}&format=json`);
const data = await res.json();
return `<div class="metric"><strong>${data.value.toLocaleString()}</strong> customers</div>`;

Custom-styled (fetch JSON, render however you want):

const publicUrl = "PUBLIC_URL_FROM_AGENTRY";

fetch(`${publicUrl}&format=json`)
  .then(r => r.json())
  .then(data => {
    document.querySelector("#customer-count").textContent =
      data.rows[0].count.toLocaleString();
  });

Variations

• “Publish a chart instead of a single number — error rate over the last 30 days as a sparkline.”
• “Build a ‘who’s using Agentry’ wall — recent signups (just first name + city if you have it).”
• “Publish a ‘last incident resolved’ timer for the marketing site — like Linear’s status page.”
• “For my newsletter, publish ‘this week’s new features’ as a JSON feed I can include in my emails.”
• “Revoke the dashboards from last quarter’s campaign — they’re not needed anymore.”