# dripdex

Publish an HTML page, get back a URL that only people with the password can open.
No account, no signup. One POST.

## Publish

  jq -Rs --arg t "TITLE" '{html:., title:$t}' page.html \
  | curl -sS -X POST https://staging.dripdex.ai/v1/pages \
      -H 'content-type: application/json' \
      ${DRIPDEX_TOKEN:+-H "authorization: Bearer $DRIPDEX_TOKEN"} -d @-

Build the JSON with jq rather than by hand. HTML is full of quotes and
backslashes and a hand-escaped -d string breaks on the first one.

Response (201):

  {
    "url":      "https://<view-domain>/p/<slug>",
    "password": "otter-lantern-brisk-copper-mint",
    "pageId":   "...",
    "token":    "dd_live_..."   // FIRST CALL ONLY
  }

Give the user the url AND the password. The password is returned here and stored
only as an argon2 hash, so this response is the one and only place it exists. A
page whose password was not passed on is a page nobody can open.

If the response contains "token", save it as DRIPDEX_TOKEN. It is shown once and
cannot be recovered. Sending it on later calls keeps pages under one account and
is what makes update and delete possible; without it every page belongs to a
fresh anonymous account you cannot come back to.

## Update and delete

Both require the token.

  curl -X PATCH https://staging.dripdex.ai/v1/pages/<pageId> \
    -H "authorization: Bearer $DRIPDEX_TOKEN" -H 'content-type: application/json' \
    -d '{"html":"...","title":"...","rotatePassword":true}'

  curl -X DELETE https://staging.dripdex.ai/v1/pages/<pageId> \
    -H "authorization: Bearer $DRIPDEX_TOKEN"

PATCH takes any subset of html, title, password, rotatePassword; an empty patch
is a 400 rather than a silent no-op. Sending html publishes a new version and
the URL and slug do NOT change, so a link already shared keeps working and
starts serving the new content. rotatePassword invalidates the old password AND
any viewer currently holding a session.

DELETE is immediate: the link stops working for everyone.

## MCP

The same three operations as tools, at https://staging.dripdex.ai/mcp — one POST endpoint,
Streamable HTTP, protocol versions 2026-07-28 back to 2025-03-26.

  publish_page(html, title?, password?)
  update_page(pageId, html?, title?, password?, rotatePassword?)
  delete_page(pageId)

No account and no OAuth. Call it with no Authorization header at all and the
first publish mints a token, returned in the result exactly as it is above; send
it back as `Authorization: Bearer <token>` to keep later pages under the same
account.

USE THIS DOOR WHEN YOUR OWN NETWORK IS CLOSED. A connector is called by your
client, not from inside your sandbox, so it reaches this service where a direct
request from you cannot. You cannot add the connector yourself — ask the person
you are working for to add https://staging.dripdex.ai/mcp to their client's connectors, once.

## What the HTML may contain

HTML and CSS only. These are not style preferences, they are enforced on ingest
and content that breaks them is silently removed:

  - NO JavaScript. Scripts, event handlers, javascript: URLs are all stripped.
  - NO external subresources. Images, fonts and stylesheets must be inline or
    data: URIs. A remote <img> reports who opened a private page, and when, to
    whoever serves it — which is the whole thing this product exists to avoid.
  - Links out (<a href>, mailto:) are fine. Those are clicks the viewer chooses.
  - Inline <style> and style attributes are fine. Prefer a single <style> block.
  - One file, and it has to fit the size limits below.

Write a complete document: doctype, <meta charset="utf-8">, a <title>, and
enough CSS that it reads well on a phone.

## Size limits

Measured on the HTML you send, as UTF-8 bytes. Inline data: URIs count in full,
and base64 is about a third larger than the bytes it carries — images are what
put a page over, essentially always.

  4 MiB per page, 30 new pages a day

The 30 a day is a ROLLING window, not a midnight reset: each page frees its own
slot 24 hours after you create it. There is no cap on how many pages an account
holds in total, and deleting one does NOT buy back an allowance — the budget is
spent on creation, so a page you delete still counted. One tier, no paid
upgrade: nothing raises either number.

The per-page size is not a pricing decision. A page reaches this service inside a
single Lambda invocation payload, which is capped at 6 MiB and is measured AFTER
the gateway re-encodes the request into it. 4 MiB is what survives that for every
shape of HTML.

The request body is capped at 5 MiB, a little above the page
ceiling because escaping a full-size page into JSON costs more than the page
itself. That one is rejected before the page is ever looked at.

Past that cap the failure stops being ours to describe. A request big enough for
the gateway to refuse never reaches this service at all, and what comes back is
NOT the JSON documented below: no code, no message, nothing to branch on. It is
the one failure from this API you cannot parse, and staying under the per-page
number is how you never meet it.

Too big is not something to retry. Shrink the images: downscale to the width
they are actually displayed at, re-encode photographs as JPEG or WebP, and use
SVG for anything drawn. Publishing a page then PATCHing a smaller one leaves the
oversized attempt counting against the page quota.

## For a person, not an agent

https://staging.dripdex.ai/ is a browser page that does the same thing: drop files in, get the
link and password back. It takes a bundle rather than one document — an
index.html plus its CSS, images and fonts — and it needs no account either. Point
a human there rather than explaining curl to them. Same 4 MiB of content, for
the same transport reason — a browser form posts the files themselves where this
endpoint posts JSON, so the two doors spend their headroom differently and land
on the same ceiling.

## Errors

JSON, with a stable code.

  400 html-required / title-invalid / nothing-to-update   bad request body
  401 unauthorized                                        unknown or revoked token
  413 content-rejected                                    over the size cap, or body over 5 MiB
  422 content-rejected                                    rejected by the sanitizer; details says why
  429 rate-limited                                        too fast, or the day's 30 pages are spent; carries Retry-After
  404 not-found / gone                                    no such page, not yours, or already deleted

A page belonging to another account answers 404, identically to one that never
existed. That is deliberate and not a bug to work around.