The ExhibitSet API

ExhibitSet has one API: the accounts service the application talks to. This page says what it does, where its machine-readable description lives, and what it will never receive.

What it is

The accounts API at api.exhibitset.com handles sign-in by e-mailed code, plans and entitlements, and matter metadata: matter names, Bates prefixes and reserved number ranges. It exists so the application in your browser can remember who you are and where your numbering stands. It is not a document-processing service. Every PDF operation happens in the browser, and the API has no route that accepts a file.

Where to find it

WhatWhere
API catalog (RFC 9727)exhibitset.com/.well-known/api-catalog
OpenAPI 3.1 descriptionexhibitset.com/.well-known/openapi/accounts.json
Healthapi.exhibitset.com/health
Base URLhttps://api.exhibitset.com

The OpenAPI document is generated from the API's own route definitions rather than written by hand, so it describes the service as it is built. It covers the routes the application calls; the Stripe webhook and the passkey endpoints are not described.

Who can use it

Today, only the ExhibitSet application. Requests that touch your data are tied to a signed-in user, and the browser origin is checked on every request the application makes that changes something; the Stripe webhook is verified by its signature instead. Sign-in itself is necessarily open, and rate-limited per address, per client and across the service as a whole. There is no third-party API programme, no API keys and no partner access yet. An agent looking for a way in is told the same thing, in the place it looks, at /auth.md. If you are building for law firms and want one, write to hello@exhibitset.com and say what you would connect.

What it never receives

Documents, document names, page text, images or hashes of any of them. The production log and its SHA-256 values stay on your computer. The privacy policy lists exactly what the account service stores; see the privacy policy and the security page.