ReelDocs

Every site that hosts writing now has the same problem: readers can't tell what a person wrote from what a model generated, so they discount everything. That's corrosive for a community — the good writers get suspected along with everyone else, and detection tools guess, publicly and wrongly.

A reel isn't a detector. It's evidence, offered by the author, that a reader can watch: the pauses, the false starts, the sentence rewritten four times. Your users choose whether to attach one. Nobody is accused of anything.

1. Record in your editor. A small library watches text changes in your existing writing surface and turns them into an event stream. It doesn't touch your UI and it makes no network calls.
2. Your backend forwards it to us. When the user is ready, your server posts the finished text and its event stream to the ReelDocs API using your API key.
3. You get a reel link back. Show it, attach it to the post, embed it — it's yours to place.

The key stays on your server and never reaches a browser. Recording happens client-side; publishing happens server-side.

Overflow is a fictional Q&A forum we built as a worked example: write an answer in its composer, post it with a recording attached, and you get a real reel link back — attributed to the forum, not to us. It looks nothing like this site, which is the point.

It is also the reference integration. Its three parts map exactly onto the three steps above: a Quill composer, a recorder attached to it, and a small backend endpoint that holds the key and forwards to our API over ordinary HTTP. Reading it is probably faster than reading this page.

Open the demo forum

Authentication

Each of your writing apps gets its own key, sent as a header. Separate keys per app mean one can be rotated or switched off without disturbing the others.

X-ReelDocs-Key: rdk_live_7fK2mQ…

Server-side only. A key in browser JavaScript is a public key, and anyone who reads it can publish reels in your name.

Publishing a reel

One call, to https://reeldocs.io/api/v1/reels:

{
  "finalText": "The finished document, exactly as written.",
  "events": [
    { "t": 0,    "p": 0, "d": 0, "i": "T" },
    { "t": 143,  "p": 1, "d": 0, "i": "h" },
    { "t": 291,  "p": 2, "d": 0, "i": "e" }
  ],
  "format": "plain",
  "expiresInDays": 30,
  "redact": false,
  "externalUserId": "opaque-id-for-your-user"
}

Each event is one edit: t milliseconds since the writing started, p the position, d how many characters were deleted, i what was inserted. Three optional flags carry the parts that matter most for honesty — x marks an insertion too large to have been typed (a paste), s marks the start of a resumed session, and m marks content that arrived from outside the editor.

The response is the reel:

{
  "id": "kC8iPEBKVcDDPX",
  "url": "https://reeldocs.io/d/kC8iPEBKVcDDPX",
  "editToken": "…",
  "expiresAt": "2026-09-16 05:51:18"
}

Store the id and editToken. They are how you later change a reel's settings or delete it — including when one of your users asks you to. Without them, neither of you can, and the only remedy is a support request to us.

What we verify

Our server replays every event stream it receives and rejects any history that doesn't reproduce the submitted text exactly. A reel that doesn't replay isn't published — there is no way to store one that doesn't reconstruct itself.

Options per reel

• Redaction — replay the writing masked, so the rhythm is visible but in-progress drafts aren't.
• Expiry — a link lifetime in days, or never.
• Relative timestamps — show durations only, not the date the document was written.
• Rich or plain text — formatting travels in a parallel channel and never alters the recorded characters.

Editor support

The hard part of an integration isn't the API call, it's producing a faithful event stream. We plan to ship a framework-agnostic recorder plus adapters for the common open-source editors — plain textarea and contenteditable, Quill, and ProseMirror/TipTap — along with a conformance suite you can run against your own integration to confirm it produces histories we'll accept and flags that mean what they should.

If your editor is proprietary, you implement against the recorder's interface (hand it text changes) rather than against the raw event format.

The Quill recorder exists today and is what the demo forum runs on, so you can see the shape of the thing before committing to it.

Attribution

Reels published through the API name the app that produced them on the reel page — "Written in Your App, via the ReelDocs API". We state where a reel came from and leave the reader to weigh it.

A full agreement comes before anything goes live. This is the shape of it, so there are no surprises in it.

• Your links keep working. Reels you've published stay live. If a key is switched off, that stops new reels being created — it doesn't break the links your users have already shared.
• You hold the handles. You retain the reel id and edit token for every reel you create, and you're the route by which your users change or delete theirs. We'll act on a direct request from an end user only where you can't.
• What we store. The document text, its edit history, and the settings for the reel. Any user identifier you send is opaque to us — we'd rather you send a salted hash than a real username, unless the name is meant to appear on the reel.
• Attribution is not optional. Reels made through the API say which app made them. We won't publish a reel that presents itself as having been written somewhere it wasn't.
• Acceptable use. Reels are published under our domain, so content that would put that domain at risk isn't something we can host. We'd rather agree what that means with you than discover it during an incident.
• If you stop using the service. Existing reels stay reachable. We'll agree a retention period rather than deleting anything on a billing event.

Not set yet. Early partners help us work out what the right shape is — per-reel, per-seat, or a flat platform fee — and we'd rather price it with you than at you.

Contact us for a quote

If you're building somewhere people write and this sounds useful, get in touch — especially if some part of the outline above is wrong for how your product works. That's the most useful thing you could tell us right now.

Contact details to be added.