Skip to main content
PATCH

Übersicht

Mit diesem Endpunkt können Lieferanten eine ihnen zugeordnete Bestellung über die comstruct API aktualisieren — Bestätigung, Ablehnung, Bearbeitung, Bestätigung einer Stornierung, Bestätigung eines Abrufs sowie Bestätigung des Bestelleingangs werden über einen einzigen PATCH-Aufruf abgewickelt. Der eigentliche Statusübergang wird serverseitig aus dem Feld change_type abgeleitet — das Feld status ist im Body bewusst nicht zugelassen, damit die Statusmaschine im Backend bleibt.
Wenn die übergebenen Felder mit dem aktuellen Stand der Bestellung übereinstimmen, antwortet der Endpunkt mit Keine Änderungen und führt keinen Schreibvorgang aus. ERP-Systeme können bei Bestätigungen daher gefahrlos den vollständigen Bestelldatensatz mitschicken.

Berechtigungen

Der API-Schlüssel muss mit einem Lieferanten verknüpft sein. Reine Kunden-API-Schlüssel können diesen Endpunkt nicht verwenden. Lieferanten dürfen ausschließlich Bestellungen aktualisieren, die ihrem eigenen Lieferantenkonto zugeordnet sind.

Pfadparameter

Änderungstypen (change_type)

changes wird ausschließlich für EDIT_ORDER ausgewertet. Bei den übrigen Änderungstypen wird der Inhalt von changes ignoriert.

Optionales PDF (pdf_base64)

Das PDF kann zu jedem change_type mitgeschickt werden — z. B. Bestellung bestätigen und Auftragsbestätigung in einem Request. Identische PDFs werden per Content-Hash dedupliziert.

Editierbare Felder (nur EDIT_ORDER)

Felder einer Position (items[])

Verhalten

  • Nur tatsächlich geänderte Felder werden geschrieben — übereinstimmende Werte werden serverseitig erkannt und übersprungen.
  • Werden in EDIT_ORDER keine echten Änderungen erkannt, antwortet der Endpunkt mit Keine Änderungen.
  • properties wird flach gemerged mit den bestehenden Werten; Schlüssel ohne neuen Wert bleiben erhalten.
  • items wird vollständig ersetzt, wenn das Feld in changes übergeben wird.
  • Bei jeder erfolgreichen Mutation wird automatisch eine Änderungsbenachrichtigung an das Bauunternehmen gesendet — comment wird in dieser Mail mitgeführt.

Response Codes

Autorisierungen

X-API-Key
string
header
erforderlich

API-Schlüssel zur Authentifizierung. Kontaktieren Sie Ihren Customer Success Manager, um einen API-Schlüssel zu erhalten.

Jeder Endpunkt erfordert spezifische Berechtigungen (Scopes); die erforderlichen Scopes werden pro Endpunkt angezeigt.

Pfadparameter

id
string<uuid>
erforderlich

Bestellungs-ID (UUID)

Body

application/json
change_type
enum<string>
erforderlich

Treibt die Statusübergänge der Bestellung:

  • CONFIRM_ORDER → Status CONFIRMED
  • DECLINE_ORDER → Status DECLINED
  • EDIT_ORDER → Status unverändert; changes werden angewendet
  • CONFIRM_CANCEL_ORDER → Status CANCEL_CONFIRMED (Bestellung muss vorher CANCELLED sein)
  • CONFIRM_ON_DEMAND → Status ON_DEMAND_CONFIRMED
  • RECEIVE_ORDER → Status RECEIVED
Verfügbare Optionen:
CONFIRM_ORDER,
DECLINE_ORDER,
EDIT_ORDER,
CONFIRM_CANCEL_ORDER,
CONFIRM_ON_DEMAND,
RECEIVE_ORDER
comment
string

Optionaler Kommentar des Lieferanten zu dieser Änderung. Wird in der Benachrichtigung an das Bauunternehmen mitgesendet.

Maximum string length: 2000
changes
object

Konkrete Feldänderungen. Wird nur für change_type: EDIT_ORDER ausgewertet — bei allen anderen Änderungstypen wird der Inhalt ignoriert, sodass ERP-Systeme den vollständigen Bestelldatensatz risikofrei mitschicken können.

pdf_base64
string

Optionales base64-kodiertes PDF (roh oder mit data-URI-Präfix, max. 10 MB dekodiert)

pdf_file_name
string

Optionaler Dateiname für den Dokumenttitel bei pdf_base64

Antwort

Bestellung erfolgreich aktualisiert oder keine Änderungen erkannt

message
string

Menschenlesbare Statusmeldung; Keine Änderungen signalisiert, dass keine Mutation durchgeführt wurde.

Beispiel:

"Die aktualisierte Bestellung wurde an das Bauunternehmen gesendet."

error
string | null

Fehlermeldung, sofern aufgetreten (sonst null)

Beispiel:

null