Lithic docs
lithicapp.io

API-Referenz

Jede Operation, die Lithic unter /api/v1 aufruft — 145 an der Zahl, verteilt auf 109 Pfade, erzeugt aus dem OpenAPI-3.1.0-Dokument, das der Server aus seiner eigenen Routentabelle schreibt. Was hier steht, gibt es auch.

Ein Server bedient mehr als ein Produkt; diese Referenz deckt die Bereiche ab, die dieses hier nutzt. Ein Endpunkt, der auf diesen Seiten fehlt, fehlt deshalb nicht zwangsläufig im Server — er gehört zu einer Oberfläche, die Ihnen nicht gegeben wurde.

Die Endpunkte selbst stehen auf Englisch. Ihre Beschreibungen stammen unverändert aus der Routentabelle des Servers, und die gibt es genau einmal. Eine übersetzte Zweitfassung würde beim ersten Routen-Umbau auseinanderlaufen, ohne dass es jemandem auffällt — das wäre der teurere Fehler.

Fangen Sie bei API an: Authentifizierung, Fehlerformate, Seitenweise Abfrage und Webhooks.

Workspaces und Personen

Workspaces mit ihren Mitgliedern, Gruppen und Einladungen, die Rechte des aufrufenden Kontos und der bisher verbrauchte Anteil am gebuchten Tarif.

Outlines

Outliner-Dokumente: ein Strukturblock wie eine Seite, dessen Knotenbaum aber im Dokument selbst steckt und nicht im Seitenbaum.

Verweise über Produktgrenzen

Die eine Tür, durch die ein Verweis eine Produktgrenze überschreitet: ein Projekt von einer Oberfläche aus anlegen, die selbst keine hat, und eine gespeicherte Id in die Worte auflösen, die daneben stehen. Hinüber geht eine Identität, nie Inhalt — ein Titel wird dort aufgelöst, wo er gezeichnet wird, und ein Verweis, den niemand sehen darf, löst zu nichts auf statt zu einem Fehler. Beide Produkte müssen im Workspace aktiv sein.

Seiten

Seiten anlegen, verschieben, in den Papierkorb legen und zurückholen; dazu ihre Markdown-Oberfläche, Feldwerte, Relationen, Backlinks, die Suche und die angehefteten Seiten.

Zusammenarbeit

Kommentare, Seitenverlauf, Aktivität, Benachrichtigungen, Anhänge und die Symbolbibliothek des Workspace.

Rechte und Freigaben

Zugriffslisten je Seite, Grenzen der Einschränkung, öffentliche Freigabelinks und die Token-Routen, über die ein Fremder sie liest.

Automatisierung

Persönliche Zugriffstoken, Webhooks, Export und das Auflösen von Links — überall dort spricht die Instanz nach außen. Dazu die wenigen Routen, die in die Gegenrichtung laufen: die Anmeldung zum frühen Zugang und die Frage des Anmeldebildschirms, welche Wege hinein diese Installation überhaupt anbietet. Das sind die Teile dieser API, die ganz ohne Sitzung erreichbar sind.

Verbundene Konten

Die eigene Berechtigung einer Person bei einem fremden Dienst — Google, Microsoft, ein CalDAV-Server oder ein schlichtes ICS-Abonnement — und der Kalenderspiegel, den sie speist. Persönlich und nicht im Workspace geteilt: Diese Routen antworten mit den Verbindungen des aufrufenden Kontos und mit keinen anderen, eine Workspace-Administratorin sieht also ihre eigenen und keine fremden. Zwei Routen ändern einen Termin beim Anbieter, und nur in einem Kalender, der dafür eingeschaltet wurde; alles Übrige liest. Keine Route gibt ein Geheimnis heraus: Refresh-Token, anwendungsspezifisches Passwort und Abonnement-URL bleiben auf dem Server — Letztere wird als das Zugangsgeheimnis behandelt, das sie ist.

Abrechnung und Rechnungen

Abonnement und Rechnungsdaten des Workspace sowie die Rechnungen, die diese Instanz im eigenen Nummernkreis ausstellt — dazu der Rückruf des Zahlungsdienstleisters.

Feedback

Eine Fehlermeldung oder eine Idee aus der laufenden Anwendung heraus einsenden. Mit Sitzung und bewusst außerhalb von /workspaces/{workspaceId}: Die Meldung ist an die Betreiber der Instanz gerichtet und nicht an einen Workspace — deshalb ist sie nur mit Sitzung erreichbar, und deshalb begründet der genannte Workspace keine Berechtigung. Mit unterwegs sind der Bildschirm, auf dem sie geschrieben wurde, die Version, das Fenster, die Eingabeart und eine strukturelle Aufzeichnung dessen, was die Anwendung getan hat — nie etwas, das jemand geschrieben hat. Betreiber lesen sie im Backoffice.