For the complete documentation index, see llms.txt. This page is also available as Markdown.

Notes API (Coming Soon)

The Notes API lets you programmatically create, read, update, delete, organize, link, and export case notes in Monolith. Notes are rich-text (HTML) documents attached to a case, optionally organized into folders and linked to other Monolith objects such as evidence items, tasks, and timeline events.

Each endpoint has its own page with full request/response examples and Python samples:

Endpoint
Method & Path
Docs

List / get notes

GET /v1/notes, GET /v1/notes/{uuid}

Create a note

POST /v1/notes

Update a note

PATCH /v1/notes/{uuid}

Append to a note

PATCH /v1/notes/{uuid}/append

Delete a note

DELETE /v1/notes/{uuid}

Note version history

GET /v1/notes/{uuid}/versions

Note authors

GET /v1/notes/note-users

Export notes (PDF/DOCX)

POST /v1/notes/export

Note Images

POST /v1/notes/{uuid}/images and related

Base URL

All public API endpoints are served under the /v1 prefix on your Monolith instance:

https://<your-monolith-host>/v1/notes

Replace <your-monolith-host> with the hostname of your Monolith deployment.

Authentication

Every request must include a Monolith API key in the X-Api-Key header. API keys are created in the Monolith app by an administrator and are tied to an API user; all activity performed with the key (note authorship, exports, etc.) is attributed to that user and logged.

Requests without a valid key receive 401 Unauthorized.

Quick check

Verify your key and connectivity with the /v1/info endpoint:

Reusable session

The Python examples throughout these docs assume a requests.Session configured like this:

Conventions

Identifiers

Notes are addressed by their uuid (a string UUID). Numeric ids (case_note_id, case_id, user_id) appear in responses but endpoints take UUIDs unless documented otherwise.

Note content

  • note_tag — the note's title.

  • note_data — the note body as HTML. On create/update the server normalizes the HTML through the rich-text renderer, so what you read back may be a cleaned-up version of what you sent. Unsupported markup is silently removed, not rejected — see Constructing note_data safely before building note bodies programmatically.

  • is_folder — folder notes group other notes. A note's parent_id must reference a folder note in the same case.

Pagination

List endpoints accept page (default 1) and page_size (default and maximum 3000) and return:

next_page is null on the last page.

Timestamps

Timestamps (created_on, updated_on) are returned in full ISO-8601 UTC format — YYYY-MM-DDTHH:mm:ss.sssZ, e.g. 2026-08-03T14:21:09.000Z. updated_on is null until a note is first updated. The export endpoint renders timestamps into the document in a timezone/format of your choice — see Export Notes.

Errors

Validation failures return 400 with a message and a Zod errors array describing each invalid field:

Service-level errors return a message only:

Status
Meaning

400

Invalid input (bad parent folder, wrong case, unsupported image type, ...)

401

Missing or invalid API key

404

Note, case, or link not found

500

Unexpected server error (details are logged server-side, not returned)

Constructing note_data safely

Every note_data value you send — on create, update, or append — is parsed into the Monolith rich-text editor's document model and re-serialized back to HTML before it is stored. This guarantees that whatever the API stores can be opened and edited in the Monolith app.

The important consequence: this is a normalization step, not a validator that rejects bad input. Markup the editor's schema doesn't understand is silently dropped or unwrapped — the request still succeeds. If you send unsupported elements, you lose them without an error. The response to every create/update/append call contains the note as it was actually stored, so you can always compare what came back against what you sent.

Note Data HTML Examples

Valid examples of HTML data that can be correctly passed to the API are provided at Note Data Examples.

Supported block elements

Element
HTML
Notes

Paragraph

<p>

Bare text is wrapped in a paragraph automatically. Supports style="text-align: left/center/right/justify".

Headings

<h1><h6>

Supports the same text-align style.

Bullet / numbered lists

<ul>, <ol>, <li>

Nesting supported.

Task lists

<ul data-type="taskList"> with <li data-type="taskItem" data-checked="true/false">

Nesting supported.

Blockquote

<blockquote>

Code block

<pre><code class="language-python">...</code></pre>

Language from the language-* class (defaults to plaintext). data-wrap="true" on the <pre> enables soft wrapping. Escape the code's HTML entities.

Horizontal rule

<hr>

Table

<table>, <tr>, <th>, <td>

colspan/rowspan supported.

Image

<img>

Keeps src, alt, title, width, height, data-uuid. Sizing via a style attribute is stripped — use the width/height attributes. Images are inline and get wrapped in a paragraph. Prefer the markup returned by the image upload endpoint; base64 data: URIs are accepted but bloat the note.

Line break

<br>

Supported inline formatting (marks)

Formatting
HTML

Bold

<strong> or <b>

Italic

<em> or <i>

Underline

<u>

Strikethrough

<s>, <del>, or <strike>

Inline code

<code>

Link

<a href="https://..."> — standard protocols (http, https, mailto, tel, ftp) and relative paths survive; unsafe schemes (javascript:, data:) are removed. target, rel, and class are overwritten with the editor's values.

Text color

<span style="color: #b91c1c"> — the color style is honored only on a <span>; a color style on <p> or headings is stripped.

Highlight

<mark data-color="#fef08a">

What gets removed or rewritten

  • Unknown block containers (<div>, <section>, <article>, <span> wrappers, ...) are unwrapped: their text content survives, the element and all of its attributes do not.

  • Elements with no schema equivalent and non-text content<script>, <style>, <iframe>, <video>, <audio>, <form>, <canvas>, embeds — are dropped entirely, including their content.

  • Attributes not listed above are stripped: id, custom class values, event handlers (onclick, ...), and custom data-* attributes (except the documented ones like data-uuid, data-checked, data-wrap, data-color).

  • Inline styles other than color (on spans) and text-align (on paragraphs/headings) are stripped — including font-family, font-size, background, margins, and widths. There is no font-family/font-size support; those belong in the export step (Export Notes accepts a font for DOCX).

  • Links with unsafe schemes (javascript:, data:) lose the link mark; the anchor text itself survives as plain text.

  • HTML comments are removed.

  • Insignificant whitespace between tags is collapsed per normal HTML parsing rules — don't rely on indentation or blank lines for layout; use paragraphs and <br>.

Equivalent markup is also normalized to canonical form (no content is lost): <b><strong>, <i><em>, <del>/<strike><s>, table cell content gets wrapped in paragraphs and tables gain <colgroup>/<tbody> scaffolding, and task items are re-rendered with the editor's checkbox markup. Expect the stored HTML to differ from your input even when nothing was dropped.

Practical guidance

1

Stick to the tables above

Everything listed round-trips losslessly.

2

Escape interpolated text content

Use html.escape() in Python so user data can't be misread as markup — especially inside <pre><code> blocks.

3

Verify the round trip

When developing an integration, the create/update/append response contains the stored note_data.

4

Avoid unsupported presentation

Don't embed presentation you can't express in the schema. If you need pixel-perfect layout (letterheads, complex styling), attach a rendered file to the case instead and keep the note to the substantive content.

A 60-second tour

1

Create a note in a case

2

Append a finding to it

3
4

Export it to PDF and download

Last updated

Was this helpful?