Reading and editing OneFront pages programmatically

1. Reading — no auth

The MCP server is public and stateless. Point any MCP client at it:

https://onefront.org/api/mcp

Or skip MCP entirely — every profile publishes a plain-text summary at /<username>/llms.txt and schema.org JSON-LD in the page itself.

• get_profile — identity: name, tagline, bio, entity type
• list_links — the page's links in display order
• list_page_blocks — the page's content: videos, prose, FAQs, embeds, calls to action
• list_posts — the profile's posts, newest first, each with its own URL
• get_post — one post's full text, so it can be quoted rather than paraphrased
• list_latest_items — newest podcast episodes, videos, or posts, with dates and durations
• list_social_accounts — linked social identities (sameAs)
• get_verified_accounts — only accounts that passed rel=me verification
• search_profiles — find profiles by name, tagline, bio, or username
• record_link_click — follow a link on the user's behalf and return its destination
• check_username_availability — whether a username can be claimed

2. Getting a key

The page’s owner creates one under Dashboard → Agents. Keys start with of_live_, are shown once, act only on that one profile, and can be revoked instantly. A key can be read-only or read-and-edit.

A key cannot mint other keys, and it cannot change the username — renaming breaks every link anyone has already shared, so it stays a deliberate human action.

3. Editing over MCP

Send the key as a bearer token. The write tools appear in the tool list only when the key is valid, so an unauthenticated client never sees a tool it can’t call.

{
  "mcpServers": {
    "onefront": {
      "url": "https://onefront.org/api/mcp",
      "headers": { "Authorization": "Bearer of_live_YOUR_KEY" }
    }
  }
}

• whoami — which profile this key edits — call first to confirm
• update_profile — display name, tagline, bio, entity type, theme
• list_my_links — your links with ids and real destinations
• add_link / update_link / remove_link — manage links
• reorder_links — set display order (pass every id)
• add_social_account / remove_social_account — manage sameAs identities
• connect_feed — attach an RSS/Atom feed that auto-updates the page
• list_feeds / refresh_feed / disconnect_feed — manage feeds
• add_page_block — add a video, post, FAQ, call to action, embed or prose to the page
• list_my_page_blocks — every content block including drafts, with ids
• update_page_block / remove_page_block — edit content, publish or unpublish it
• reorder_page_blocks — set content order (pass every id)

Publishing content is metered by plan, so an agent hits the same limit the dashboard does — it can always create drafts, and add_page_block returns a clear message rather than silently failing when the published-block allowance is already used up.

4. Editing over HTTP

The same key authenticates the REST API. These are the endpoints the dashboard itself uses, so they can’t drift from what the product actually does.

curl -X PATCH https://onefront.org/api/profile \
  -H "Authorization: Bearer of_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tagline":"Now shipping weekly"}'

curl -X POST https://onefront.org/api/links \
  -H "Authorization: Bearer of_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"label":"New episode","url":"https://example.com/ep/42"}'

curl -X POST https://onefront.org/api/feeds \
  -H "Authorization: Bearer of_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://feeds.example.com/show.xml","kind":"podcast"}'

Errors come back as {"error": "…"} with a real status code: 401 unknown or revoked key, 402 account not on Pro, 403 read-only key attempting a write, 404 not yours, 400 validation.

5. Auto-updating feeds

Rather than pushing every new episode or post by hand, connect the source once and OneFront polls it. New entries appear on the page and in its structured data within about half an hour, typed as PodcastEpisode, VideoObject, or BlogPosting— with publish dates, durations, and episode numbers, so “what’s their latest episode?” has a real answer.

RSS 2.0, Atom, and podcast feeds all work. Use refresh_feed (or POST /api/feeds/:id) to publish something immediately instead of waiting for the next poll.

6. Subscribers → CRM

Get a page’s confirmed email subscribers into a CRM two ways. Pull them incrementally — pass the last confirmedAt you synced as since and you only get newer ones back:

curl "https://onefront.org/api/subscribers?since=2026-01-01T00:00:00Z" \
  -H "Authorization: Bearer of_live_YOUR_KEY"
# -> { subscribers: [{ email, subscribedAt, confirmedAt }], nextSince, hasMore }

Or push: register a webhook and every new confirmed subscriber (and unsubscribe) is POSTed to it in real time, HMAC-signed so you can trust it.

• list_subscribers — confirmed subscribers, incremental via since
• add_subscriber_webhook — register a CRM/Zapier/Make/n8n URL; returns the signing secret once
• list_subscriber_webhooks — webhooks with delivery health + secret
• test_subscriber_webhook — send a sample delivery
• remove_subscriber_webhook — delete a webhook

Each delivery carries X-OneFront-Signature: sha256=<hmac> — the HMAC-SHA256 of the raw request body keyed with the webhook secret. Recompute it and compare before trusting the payload:

{
  "event": "subscriber.confirmed",
  "occurredAt": "2026-07-23T18:00:00.000Z",
  "profile": { "username": "you", "url": "https://onefront.org/you" },
  "subscriber": { "email": "fan@example.com", "subscribedAt": "…", "confirmedAt": "…" }
}

Only confirmed (double opt-in) subscribers are ever returned or delivered — never a pending address.