API-Änderungen

Gilt ab Work7 0.10.0 · Stand 06.11.2026

Diese Seite listet je Version der Public API v1, was hinzugekommen ist, was sich geändert hat und was veraltet ist. Die API-Version steht in der Spezifikation unter info.version. Innerhalb von v1 kommen Felder und Endpunkte nur hinzu; bestehende Felder werden nicht entfernt oder umbenannt (siehe Fehler und Limits). In der API-Referenz tragen Endpunkte und Felder ab 1.1 den Hinweis „Seit API 1.x“.

• App-Version nennt das erste Work7-Release, das die API-Version enthält. app.work7.net bekommt zwischen zwei Releases auch Zwischenstände; eine API-Version kann dort deshalb schon vor diesem Release verfügbar sein.
• Datum ist der Tag, an dem die API-Version festgelegt wurde.
• Download: Ab Release 0.9.0 wird die Spezifikation je Release archiviert. Die Archivdatei ist die vollständige OpenAPI-Datei dieses Stands und lässt sich zum Beispiel für einen Vergleich mit der aktuellen Spezifikation nutzen.

API 1.24: Arbeitstag einer Zeit mit Kommen und Gehen

App-Version: noch in keinem Release (nach Work7 0.9.0) · Datum: 06.11.2026

Keine neuen Endpunkte oder Felder.

Geändert

• work_date in GET /time-entries: Bei Personalzeit mit Kommen und Gehen ist der Arbeitstag jetzt immer der Tag des Kommens in österreichischer Zeit (Europe/Vienna), auch wenn erst nach Mitternacht gegangen wird. Eine Nachtschicht von 22:00 bis 06:00 trägt den Tag des Kommens; eine Buchung zwischen 0 und 2 Uhr den österreichischen Kalendertag. Bisher konnte work_date bei solchen Einträgen den Tag des Gehens bzw. das UTC-Datum tragen. Bestehende Einträge werden nicht umgeschrieben.

API 1.23: Demo-Account ohne Public API

App-Version: noch in keinem Release (nach Work7 0.9.0) · Datum: 05.11.2026

Keine neuen Endpunkte oder Felder.

Geändert

• Neu möglich: 403 FORBIDDEN mit code demo_locked auf jedem Endpunkt, wenn der Betrieb des Schlüssels ein Demo-Account ist. Im Demo-Account sind Anbindungen gesperrt, auch ein Schlüssel aus der Zeit vor der Demo funktioniert dort nicht. Die Antwort hat das Format der Fehler aus der Geschäftslogik (error, message, code, details, timestamp). Für alle anderen Betriebe ändert sich nichts.

API 1.22: Projekt- und Kundennummer je Betrieb

App-Version: noch in keinem Release (nach Work7 0.9.0) · Datum: 01.11.2026

Keine neuen Endpunkte oder Felder.

Geändert

• project_number und customer_number sind nur noch innerhalb eines Betriebs eindeutig, nicht mehr über alle Betriebe. Ein anderer Betrieb kann dieselbe Nummer tragen; Ihr API-Schlüssel sieht ohnehin nur Ihren Betrieb.
• 409 CONFLICT mit details.code duplicate_project_number bei POST /projects und PATCH /projects/{id} kommt nur, wenn die Nummer im eigenen Betrieb schon vergeben ist.
• Neu möglich: 409 CONFLICT mit details.code NUMBER_TAKEN bei POST /projects ohne project_number und POST /contacts, wenn die von Work7 vergebene Nummer im selben Moment im Betrieb anders vergeben wurde. Nichts wird angelegt, ein erneuter Versuch kann klappen; die Antwort wird nicht unter dem Idempotency-Key gespeichert.
• Ohne project_number vergibt Work7 die Nummer aus dem Nummernkreis „Projektnummer“ des Betriebs (Standard PR-<Jahr>-<laufende Nummer>, z. B. PR-2026-0001; vorher PR-<Endung der Kundennummer>-<laufende Nummer>). Neue Kontakte bekommen ihre Kundennummer aus dem Nummernkreis „Kundennummer“ (für neue Betriebe KD-000001; bestehende Betriebe behalten ihr bisheriges Format). Bestehende Nummern bleiben unverändert.
• Rapportnummern im Beispiel heißen RA-2026-0087 (Standardmuster seit dem Rapport-Nummernkreis).

API 1.21: Schreibende Aufrufe

App-Version: noch in keinem Release (nach Work7 0.9.0) · Datum: 27.10.2026

Grundlage für schreibende Endpunkte; Kontakte und Projekte sind schreibbar.

Hinzugefügt

• Kontakte schreiben mit Scope core:write: POST /contacts legt eine Organisation oder Person im Status active an (201 mit Header Location, optional Idempotency-Key). GET /contacts/{id} liest einen Kontakt (core:read), PATCH /contacts/{id} ändert Felder, archiviert (status: archived, nur ohne weitere Felder) oder reaktiviert (status: active), DELETE /contacts/{id} löscht (204). id ist die numerische ID oder die Kundennummer. Neue Schemas ContactCreate, ContactUpdate, ContactPersonLink und ContactPersonLinkResult.
• POST /contacts ohne country (oder mit null) legt den Kontakt mit dem Land des Betriebs an, zum Beispiel AT bei einem österreichischen Betrieb. Ein mitgeschicktes Land bleibt unverändert.
• Löschen ist ein Soft-Delete: Der Kontakt ergibt danach bei jedem Zugriff 404 und fehlt in Listen; Verknüpfungen mit Ansprechpartnern werden entfernt. Hat der Kontakt versendete oder fertiggestellte Belege, kommt 409 CONFLICT mit details.code has_documents; stattdessen archivieren.
• Archivieren und Löschen über die API ändern nichts außerhalb des Kontakts. Hat er Entwürfe von Belegen, offene Rapporte oder Abnahmeprotokolle, Anfragen oder Projekte, die die App dabei mitändern oder löschen würde, kommt 409 CONFLICT mit details.code has_open_items und der Anzahl je Art in details.items (siehe Fehler und Limits); diese Vorgänge in der App bereinigen. Gespeicherte Idempotency-Key-Antworten zum Kontakt werden dabei gelöscht.
• status: deleted beim Bearbeiten ergibt 400 validation_error; kind ist nach dem Anlegen fest, is_active und email_domain sind nie schreibbar. Bank- und Steuerdaten (iban, bic, vat_number, tax_number) ohne das Recht, sie zu sehen, ergeben 403 statt still ignoriert zu werden.
• Ansprechpartner: POST /contacts/{id}/people verknüpft einen Personen-Kontakt mit einer Organisation (Position, Hauptansprechpartner), DELETE /contacts/{id}/people/{personId} löst die Verknüpfung (404, wenn es keine gibt).
• POST /kontakte als Alias von POST /contacts. Die neuen Pfade mit {id} haben keinen Alias.
• POST /inquiries wertet den Header Idempotency-Key aus. Der Body wird dort weiterhin auch ohne Content-Type: application/json gelesen.
• Header Idempotency-Key für POST-Aufrufe (16–128 druckbare ASCII-Zeichen). Gleicher Schlüssel mit gleichem Body innerhalb von 24 h liefert die gespeicherte Antwort mit Idempotent-Replay: true, ohne erneut zu schreiben. Anderer Body, Pfad oder Query-String: 409 CONFLICT mit details.code idempotency_conflict; läuft die erste Anfrage noch: idempotency_in_progress; seit mehr als 5 Minuten offen (Ausgang unbekannt, kein erneuter Lauf, vor neuem Schlüssel per GET prüfen): idempotency_outcome_unknown.
• Fehlercodes unsupported_media_type (415, falscher oder fehlender Content-Type; kaputtes JSON ergibt 400 validation_error) und payload_too_large (413, JSON-Body über 64 KB) für schreibende Aufrufe; gemeinsame Antworten Conflict, UnsupportedMediaType und PayloadTooLarge in der Spezifikation.
• Projekte schreiben mit Scope core:write: POST /projects legt ein Projekt an (Pflicht name und kontakt_id, optional project_number, Status über status_id oder status; 201 mit Header Location, optional Idempotency-Key, Herkunft „API“). PATCH /projects/{id} ändert Felder und den Status; id ist die numerische ID oder die Projektnummer. Neue Schemas ProjectCreate und ProjectUpdate. Löst project.created bzw. project.updated aus.
• Archivieren eines Projekts ist ein Statuswechsel per PATCH auf einen Status mit der Bedeutung archived (status: archived); ein DELETE /projects/{id} gibt es nicht. expected_status_id sichert den Statuswechsel ab: Hat sich der Status inzwischen geändert, kommt 409 CONFLICT mit details.codePROJECT_STATUS_STALE, und nichts wird geändert.
• kontakt_id eines Projekts muss ein nicht gelöschter Kontakt des eigenen Betriebs sein, sonst 400 validation_error mit details.field kontakt_id. Eine schon vergebene Projektnummer ergibt 409 CONFLICT mit details.code duplicate_project_number.
• Konflikte tragen den Fall in details.code: neben den drei Idempotenz-Fällen has_documents, has_open_items, duplicate_project_number und PROJECT_STATUS_STALE.
• Eigenes Limit für schreibende Aufrufe: höchstens 60 POST, PATCH und DELETE pro Minute je Schlüssel, zusätzlich zum Gesamtlimit von 600; darüber 429 rate_limited mit Retry-After. Uploads der Datenablage (POST /inbound) und mit 403 abgewiesene Aufrufe zählen nicht mit.
• Webhook-Ereignisse offer.rejected (Angebot als abgelehnt markiert, Status rejected) und offer.reopened (Ablehnung zurückgenommen, Status wieder sent). Die Nutzlast ist die des Angebots wie bei offer.accepted; GET /offers kennt den Status rejected schon.

Geändert

• Korrektur: Validierungsfehler aus der Geschäftslogik liefern jetzt error: "validation_error" (400), wie die Spezifikation es beschreibt. Bisher kam in diesen Fällen error: "BAD_REQUEST". Wer auf den alten Wert prüft, sollte beide Werte akzeptieren. NOT_FOUND, CONFLICT, FORBIDDEN und INTERNAL_ERROR bleiben unverändert.
• Korrektur: Anfragen aus POST /inquiries sind jetzt dem Nutzer zugeordnet, der den API-Schlüssel angelegt hat, wie unter Authentifizierung beschrieben. Bisher blieb der Ersteller leer. Schlüssel ohne bekannten Ersteller legen Anfragen weiterhin ohne Ersteller an.
• Korrektur: POST /inquiries ohne source (Standard api) oder mit source: "website" liefert jetzt 201 statt 500. Beide Werte standen in der Spezifikation, wurden von der Datenbank aber abgelehnt.
• Das Rate-Limit von 600 Anfragen pro Minute je Schlüssel gilt für Lesen und Schreiben zusammen; schreibende Aufrufe sind zusätzlich auf 60 pro Minute begrenzt (betrifft auch POST /inquiries, nicht POST /inbound).
• POST /inquiries prüft den Body jetzt: höchstens 64 KB (sonst 413), Längen wie in AnfrageCreate (zum Beispiel title 255 Zeichen, description ohne eigene Grenze), source nur mit den erlaubten Werten (sonst 400 validation_error mit details.field statt 500). Schlüssel der Rollenstufe 3 (ohne Recht, Anfragen zu bearbeiten) bekommen 403; bisher legten sie Anfragen an. Unbekannte Felder werden weiter ignoriert.
• expected_status_id bei PATCH /projects/{id} gilt auch, wenn nur Felder und kein neuer Status geschickt werden (409 PROJECT_STATUS_STALE, nichts gespeichert).
• Webhooks: Die Nutzlast invoice enthält im Unterobjekt item zusätzlich discount_percent, discount_amount (Positionsrabatt in Prozent oder als Betrag, sonst null) und line_net (Netto der Position nach Positionsrabatt); am Rechnungskopf steht discount_amount (Gesamtrabatt netto). Bisherige Felder bleiben.
• Webhooks: contact.deleted steht jetzt in der Liste der Ereignisse; es wurde schon bisher beim Löschen in der App gesendet und kommt nun auch aus DELETE /contacts/{id}.
• Korrektur: GET /projects/{id} liefert die Felder des Projekts jetzt direkt in data, wie die Spezifikation es beschreibt. Bisher standen sie nur unter data.project. Der Schlüssel data.project bleibt mit denselben Werten erhalten und ist ab 1.21 veraltet; neue Integrationen lesen die Felder direkt aus data. Eine numerische id außerhalb des Zahlenbereichs ergibt jetzt 404 statt 500.

Korrektur im Stand 1.20: Filter status=overdue

App-Version: noch in keinem Release (nach Work7 0.9.0) · Datum: 22.10.2026

Fehlerkorrektur ohne eigene Versionsnummer: info.version bleibt 1.20, die Korrektur gilt ab dem Stand 1.20 vom 22.10.2026 (in älteren Fassungen dieser Doku als „1.19.1“ geführt).

Geändert

• GET /invoices?status=overdue liefert Rechnungen (Belegart invoice), die nach wirksamer Fälligkeit überfällig sind: Restbetrag > 0, und der spätere Tag aus Fälligkeit und Zahlungsaufschub liegt vor heute (Europe/Vienna), unabhängig vom gespeicherten Status. Das Feld status kann daher auch sent, partial_paid oder finalized tragen; eine Rechnung mit gespeichertem overdue, deren Aufschub noch läuft, fehlt. Bisher lieferte der Filter nur den gespeicherten Status overdue.

API 1.20: Büro-Freigabe

App-Version: noch in keinem Release (nach Work7 0.9.0) · Datum: 20.10.2026

Projektstunden, Rapporte, Bautagebuch-Einträge und Fotos von Mitarbeitern können im Betrieb auf eine Freigabe durch das Büro warten.

Hinzugefügt

• GET /time-entries und GET /site-reports (Alias /rapports) liefern je Eintrag approval_status (approved = freigegeben, pending = wartet auf Freigabe, rejected = abgelehnt) und rejected_reason (Grund der Ablehnung, sonst null).
• GET /site-reports/{id} liefert zusätzlich approved_at. Wer freigegeben hat, wird nicht ausgeliefert.
• Filter approval_status an beiden Listen; ein anderer Wert ergibt 400 validation_error.
• Webhook-Ereignisse time_entry.approved/.rejected, site_report.approved/.rejected, site_diary.approved/.rejected und document.approved/.rejected (Fotos). Die Nutzlast dieser Bereiche trägt approval_status (bei time_entry.* zusätzlich entry_id und user_id), nie den Grund.

Geändert

• Nichts an bestehenden Feldern. Ohne Filter kommen wie bisher alle Einträge, auch offene und abgelehnte. Wer nur geprüfte Stunden übernehmen will (zum Beispiel für die Lohnverrechnung), filtert approval_status=approved. Bestandsdaten und Einträge von Admin und Manager sind approved.

API 1.19: Kostenvoranschläge

App-Version: Work7 0.9.0 · Datum: 02.10.2026 · Download: openapi-public-v1-1.19.yaml (Stand von Release 0.9.0)

Hinzugefügt

• GET /cost-estimates und GET /cost-estimates/{id} (Scope offers:read, Modul Angebote). Ein Kostenvoranschlag ist ein eigener Beleg (Nummernkreis „Kostenvoranschlag“, Standard KV-JJJJ-NNNN) mit Verbindlichkeit (is_binding), Gültigkeit, optionalem Entgelt und Status bis zur Annahme, Ablehnung oder Umwandlung. Geliefert werden nur fertiggestellte Kostenvoranschläge.
• Webhook-Ereignis project.sent (Fotos eines Projekts an den Kunden gesendet).

API 1.18: Herkunft aus Leistungspaketen

App-Version: Work7 0.9.0 · Datum: 02.10.2026

Hinzugefügt

• GET /offers/{id} liefert je Position bundle_id und bundle_item_id: Leistungspaket und Paketposition, aus denen die Position übernommen wurde (null ohne Paket). Das ist eine Momentaufnahme ohne Verweisgarantie: das Paket kann inzwischen geändert oder gelöscht sein. Kopien und Angebote aus Vorlagen tragen keine Herkunft.
• Webhook-Ereignisse offer.items_added (mehrere Positionen und Titel auf einmal, z. B. ein Leistungspaket übernommen; mit item_count, section_count und bundle_id) sowie service_bundle.created, service_bundle.updated und service_bundle.deleted.

API 1.17: Lieferscheine

App-Version: Work7 0.9.0 · Datum: 02.10.2026

Hinzugefügt

• GET /delivery-notes und GET /delivery-notes/{id} (Scope offers:read, Modul Angebote). Ein Lieferschein ist rein dokumentarisch und hat keine Beträge. Geliefert werden nur fertiggestellte Lieferscheine mit Lieferdatum, Lieferzeitpunkt, Warenempfänger und je Position der gelieferten Menge.

API 1.16: Auftragsbestätigungen

App-Version: Work7 0.9.0 · Datum: 02.10.2026

Hinzugefügt

• GET /order-confirmations und GET /order-confirmations/{id} (Scope offers:read, Modul Angebote). Eine Auftragsbestätigung ist die unveränderliche Kopie eines angenommenen Angebots mit eigener Nummer (Nummernkreis „Auftragsbestätigung“, Standard AB-JJJJ-NNNN). Geliefert werden nur fertiggestellte Belege.

API 1.15: Filter „Offen“, Bild und Einheit an Angebotspositionen

App-Version: Work7 0.9.0 · Datum: 02.10.2026

Hinzugefügt

• GET /invoices akzeptiert am Statusfilter den virtuellen Wert open: fertige Rechnungen (Status finalized, sent, partial_paid, overdue, Belegart invoice) mit offenem Restbetrag (remaining > 0). Entwürfe, bezahlte und stornierte Rechnungen sowie Storno- und Korrekturbelege fehlen.
• GET /offers/{id} liefert je Position image_id, frozen_image_id und unit_id, am Angebot show_item_images. Vorerst sind die Positionsfelder null und show_item_images ist false.

API 1.14: Projektstatus je Betrieb

App-Version: Work7 0.9.0 · Datum: 02.10.2026

Jeder Betrieb hat eine eigene Statusliste für Projekte (Standard: Planung, Ausführung, Abnahme, Abrechnung, Abgeschlossen, Archiviert).

Hinzugefügt

• Project liefert status_id, status_label (Name im Betrieb), status_color, status_system_key (Standardstatus, z. B. acceptance; null bei eigenen Status) und status_changed_at.
• Der Filter status nimmt zusätzlich eine numerische Status-ID des Betriebs.
• Webhook project.* trägt status mit denselben Werten sowie status_id, status_label und status_system_key.

Geändert

• Project.status behält die bisherigen Werte (active, paused, completed, cancelled, archived): laufende Status ergeben active, abgeschlossene completed, archivierte archived. Projekte, die vorher paused bzw. cancelled waren, liefern diese Werte weiter. active und archived filtern wie bisher, ohne die Projekte in paused bzw. cancelled.

API 1.13: Zeitart je Zeitbuchung

App-Version: Work7 0.9.0 · Datum: 02.10.2026

Hinzugefügt

• GET /time-entries liefert je Eintrag time_type (work = Arbeitszeit, travel = Fahrtzeit, school = Berufsschule, nur bei entry_type = personal). Ältere Buchungen und Kommen/Gehen sind work.

API 1.12: Rechnungsfelder fest freigegeben

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Hinzugefügt

• Neu dokumentiert und garantiert sind unter anderem offer_id, currency, Rabatt- und Steuerbeträge, service_date, paid_at und updated_at sowie Steuersatz und Herkunft je Position.

Geändert

• GET /invoices und GET /invoices/{id} liefern Rechnungskopf und Positionen nur noch mit den Feldern der Schemas Invoice und InvoiceItem (feste Freigabeliste wie bei Webhooks). Interne Felder, die bisher undokumentiert mitkamen (interne Notiz, Zahlungs- und Fußtext, signiertes PDF, Nutzer-IDs, Herkunft des Fertigstellens, Storno- und Korrekturgrund, Klärung „Nie ausgestellt“, Positionsnotiz), werden nicht mehr ausgegeben. Neue interne Felder erscheinen nie automatisch.

API 1.11: Guthaben erstatten und verrechnen

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Das Guthaben eines Storno- oder Korrekturbelegs (negatives remaining) wird erstattet oder mit einer offenen Rechnung desselben Kunden verrechnet. Keine neuen Felder.

Hinzugefügt

• Webhook-Ereignisse invoice.refund_recorded (Gegenbeleg, mit amount, payment_date, payment_method, from_invoice_id) und invoice.credit_applied (Rechnung, mit amount, from_invoice_id, to_invoice_id).

Geändert

• Erstattung: Am Gegenbeleg sinkt already_paid (wird negativ = zurückgezahlt), remaining steigt Richtung 0.
• Verrechnung: Am Gegenbeleg sinkt credited_amount, an der Rechnung steigt credited_amount und remaining sinkt; status wird paid bzw. partial_paid.

API 1.10: Rechnungskorrektur über Teilbeträge

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Eine fertige Rechnung lässt sich um einen Teilbetrag mindern (Nachlass, Minderleistung).

Hinzugefügt

• Die Rechnungskorrektur erscheint in GET /invoices als eigener Beleg mit document_kind = correction, eigener Nummer (z. B. RK-2026-0001), corrects_invoice_id und negativem total. Mehrere Korrekturen je Rechnung sind möglich, zusammen höchstens bis zum Rechnungsbetrag.
• Webhook-Ereignis invoice.corrected (Original, mit correction_id und correction_number).

Geändert

• Am Original steigt credited_amount um den verrechneten Betrag, remaining sinkt; ist danach nichts mehr offen, steht es auf status = paid. Nach einer Rechnungskorrektur wird eine Rechnung nicht mehr storniert.

API 1.9: Angebotsversionen

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Ein fertiges Angebot wird als neue Version unter derselben Nummer überarbeitet (version_no 2, 3 …). Die Arbeitskopie ist dann wieder ein Entwurf (finalized_at = null, status = draft), frühere Fassungen bleiben unverändert.

Hinzugefügt

• Offer liefert accepted_version_no (angenommene Fassung), GET /offers/{id} zusätzlich version_no und version_count (Zahl der fertigen Fassungen).
• Invoice liefert offer_version_no (Fassung, aus der die Rechnung erzeugt wurde).
• Webhook-Ereignisse offer.version_created (mit version_no und from_version_no) und offer.version_discarded (mit discarded_version_no); offer.accepted trägt accepted_version_no.

API 1.8: Storno und Rechnungskorrektur

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Eine fertige Rechnung wird nie mehr geändert, sondern nur noch über einen eigenen Gegenbeleg aufgehoben oder ersetzt.

Hinzugefügt

• Invoice liefert document_kind (invoice/cancellation/correction), corrects_invoice_id (Original, das dieser Storno- oder Korrekturbeleg aufhebt bzw. mindert), replaces_invoice_id (Rechnung, die ein Korrektur-Entwurf ersetzt) und credited_amount (durch Belege verrechneter Betrag).
• GET /invoices filtert nach document_kind.
• Webhook-Ereignis invoice.cancelled (Original, mit cancellation_id und cancellation_number).

Geändert

• total und remaining sind bei Storno und Rechnungskorrektur negativ; das Original steht dabei auf status = cancelled.
• Der Stornobeleg selbst löst beim Fertigstellen invoice.finalized aus (document_kind: "cancellation").

API 1.7: Angebote fertigstellen

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Hinzugefügt

• Offer liefert finalized_at (Zeitpunkt des Fertigstellens, null = Entwurf, noch bearbeitbar) und version_no (aktuelle Fassung).
• Webhook-Ereignis offer.finalized.

Geändert

• Der Bearbeitungsstatus ist vom Annahmestatus status getrennt: Ein fertiggestelltes, noch nicht versendetes Angebot hat status = draft und finalized_at gesetzt.

API 1.6: Rechnungen fertigstellen

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Hinzugefügt

• Invoice liefert finalized_at (Zeitpunkt des Fertigstellens), payment_extended_until (Zahlungsaufschub; wirksame Fälligkeit ist der spätere Tag aus due_date und payment_extended_until) und, nur in GET /invoices, sent_at (Zeitpunkt des Versands, null bei einer fertiggestellten, noch nicht versendeten Rechnung).
• Rechnungsstatus finalized: fertiggestellt (Nummer vergeben, gesperrt), aber noch nicht versendet.
• Webhook-Ereignis invoice.finalized: einmalig beim Fertigstellen, auch automatisch beim Versand eines Entwurfs. Die Nutzlast von invoice.* trägt zusätzlich finalized_at und payment_extended_until.

Geändert

• Ein Rechnungsentwurf trägt bis zum Fertigstellen keine Nummer. Die Public API liefert nur nummerierte Rechnungen; ein Entwurf erscheint weder in GET /invoices noch unter GET /invoices/{id} (404).
• invoice.created trägt invoice_number: null; die Nummer kommt mit invoice.finalized.

API 1.5: Zusatzfelder am Projekt, Belegnummern

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Hinzugefügt

• GET /projects und GET /projects/{id} liefern attributes: frei benannte Zusatzfelder als Objekt aus Texten (z. B. {"Kostenstelle": "71"}, Standard {}). Der Schlüssel Altnummer trägt eine Auftragsnummer aus dem Datenimport, die als Projektnummer schon vergeben war.

Geändert

• Project.status nennt die tatsächlich verwendeten Werte (active, paused, completed, cancelled, archived).
• Angebots- und Rechnungsnummern kommen aus den Nummernkreisen des Betriebs (Muster je Belegart, z. B. AN-2026-0001, RE26-00120) und werden vollständig geliefert. offer_number enthält jetzt auch das Präfix: Bestandsangebote, die bisher eine reine Ziffernfolge trugen (4711), heißen AN-4711, auch in den Nutzdaten der Webhooks offer.*. Belegnummern enthalten immer mindestens einen Buchstaben oder Trenner; eine reine Ziffernfolge im Pfad ist deshalb immer die ID.

API 1.4: Mahnwesen

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Hinzugefügt

• GET /invoices/{id} liefert business_transaction (Geschäftsart der Rechnung, null = aus dem Kontakt abgeleitet) und dunning_blocked (Mahnsperre). Der Grund der Mahnsperre wird nicht ausgegeben.
• GET /invoices liefert je Zeile dunning_level (höchste versendete Mahnstufe, null = noch nicht gemahnt) und akzeptiert am Statusfilter den virtuellen Wert dunned (offene Rechnung mit mindestens einer versendeten Mahnung; kein eigener Rechnungsstatus).
• Webhook-Ereignis invoice.dunning_sent: Der Betrieb hat eine vorbereitete Mahnung als per Post versendet markiert (mit dunning_level, payment_deadline und amount = Zahlbetrag laut Mahnung).

API 1.3: Webhook-Ereignisse englisch

App-Version: Work7 0.9.0 · Datum: 24.09.2026

Geändert

• Ereignisnamen sind englisch, <bereich>.<aktion> in snake_case (inquiry.created, contact.updated, site_report.completed, catalog.material.created).
• data.data trägt nur freigegebene Felder je Bereich, nie ganze Datensätze. Ziel-URLs müssen öffentlich erreichbar sein (siehe Webhooks).

Veraltet

• Die früher dokumentierten Ereignisnamen (anfrage.*, kontakt.*, rapport.*) und interne Namen (anfragen.*, rapports.*) werden in bestehenden Abos und beim Anlegen eines Abos dauerhaft auf die englischen Namen abgebildet.

API 1.2: Scopes englisch

App-Version: Work7 0.9.0 · Datum: 23.09.2026

Geändert

• Scope-Bereiche heißen inquiries, site-reports, offers, invoices, time-tracking und appointments (dazu unverändert core und int.inbound).

Veraltet

• Die alten Scope-Namen anfragen, rapport, angebote, rechnungen, zeiterfassung und termine werden dauerhaft akzeptiert. Beim Anlegen eines Schlüssels werden sie auf die neuen Namen abgebildet (z. B. anfragen:read → inquiries:read); bestehende Schlüssel funktionieren unverändert weiter.

API 1.1: Englische Pfade

App-Version: Work7 0.9.0 · Datum: 23.09.2026

Hinzugefügt

• GET /contacts, GET/POST /inquiries, GET /site-reports und GET /site-reports/{id}.

Veraltet

• /kontakte, /anfragen, /rapports und /rapports/{id} bleiben als Aliase dauerhaft erreichbar (identische Antworten, kein Redirect, keine Frist zum Umstellen) und sind in der Referenz als deprecated markiert.

API 1.0: Erste Fassung

App-Version: Work7 0.2.0 · Datum: 12.09.2026

Hinzugefügt

• GET /me, GET /projects, GET /projects/{id}, GET /kontakte, GET/POST /anfragen, GET /rapports, GET /rapports/{id}, GET /offers, GET /offers/{id}, GET /invoices, GET /invoices/{id}, GET /time-entries, GET /appointments und die Zustellung von Webhook-Ereignissen.
• Nachgetragen ohne eigene Versionsnummer am 15.09.2026, erstmals in Work7 0.9.0: Datenablage GET /inbound und POST /inbound (Scope int.inbound, siehe Datenablage).