Lucid Dream APIKeep the account.
Structure the rest.

A journal is a source, not a verdict

This Lucid Dream API guide focuses on user-reported dream accounts. The interface may organize text, maintain revisions, and attach optional annotations. A field describing reported lucidity remains a self-report; its presence in JSON does not make it an independent measurement of a sleep state.

Start with the original text, a stable entry identifier, a revision, and a clearly described origin. Separate when the record was saved from when the person believes the experience occurred. Permit an unknown experience date rather than guessing one from the surrounding context.

Make uncertainty part of the schema

Missing, empty, and unknown values should have documented meanings. A user who did not answer a lucidity question should not automatically receive a false value. One proposed design uses reported_lucid, reported_not_lucid, and unspecified. The labels describe the account, not a diagnostic classification.

Keep generated tags distinct from user tags. Associate summaries with the exact source revision they describe. When the original changes, mark derived results stale rather than silently carrying them forward as if they still describe the current entry.

Inspect a concrete example

The example record and downloadable JSON Schema are static reference files. They illustrate explicit origins, optional dates, and bounded text fields. They are not a live API contract or a complete security design. A schema validates structure; your application must separately enforce ownership, permissions, and lifecycle rules. Date-format enforcement also depends on your validator's configuration.

Give every derivative a lifecycle

An entry may produce a summary, search document, embedding, cached preview, or export. Track those relationships so correction and deletion can reach more than the original row. Recheck resource availability before a background worker publishes a result, especially when a user deleted the source while processing was underway.

Keep export understandable outside the application. Include original text, meaningful dates, and enough field documentation to distinguish self-reports from generated annotations. Test an export with an unknown date and an edited summary; those cases often reveal hidden assumptions that a polished example does not.

Keep collection purposeful

Do not add personal fields merely because they might be useful someday. State why an application collects each piece of information and which operation requires it. Saving a journal, requesting a summary, and contributing to research are different purposes and should not be represented as one unlimited permission.

Continue to Lucid Dream AI for optional summarization and reflection. Use Lucid Dreaming API when working with research observations or event streams, where timestamps and evidence types need a different model. Keep the two sources connected when appropriate, but never interchangeable by default.