Loading Optiviera...

REST API

Optiviera REST API Referenz

JSON · JWT Auth · Mandantenfähig

Integrieren Sie jedes System mit Optiviera über eine vollständig dokumentierte REST API. Alle Endpunkte erfordern ein JWT Bearer-Token und werden automatisch auf Ihren Mandanten beschränkt.

Schnellstart

In drei Schritten zum ersten API-Aufruf

1

Authentifizieren

Senden Sie Ihre Zugangsdaten an POST /api/auth/login. Die Antwort enthält ein JWT-Token, das 24 Stunden gültig ist.

2

Auth-Header hinzufügen

Fügen Sie das Token jeder Anfrage hinzu: Authorization: Bearer [token]

3

API aufrufen

Alle Endpunkte befinden sich unter https://optiviera.com/api und antworten mit JSON. Der Mandantenkontext wird automatisch aus Ihrem Token abgeleitet.

Authentifizierung

Jede Anfrage muss ein gültiges JWT Bearer-Token vom Login-Endpunkt enthalten

So funktioniert es

  • POST an /api/auth/login mit E-Mail und Passwort
  • Token sicher speichern (httpOnly-Cookie oder im Speicher)
  • Authorization: Bearer [token] bei jeder Folgeabfrage mitsenden
  • Token läuft nach 24 Stunden ab — mit POST /api/auth/refresh erneuern
Login-Anfragebash
curl -X POST https://optiviera.com/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","password":"••••"}'
Erfolgreiche Antwortjson
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expiresIn": 86400,
  "tokenType": "Bearer"
}
Token verwendenhttp
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Basis-URL & Format

Alles was Sie vor Ihrem ersten Aufruf wissen müssen

Basis-URL: https://optiviera.com/api — Alle Endpunkte sind relativ zu dieser Basis-URL. Verwenden Sie immer HTTPS.

JSON-Format

Alle Anfragen und Antworten verwenden application/json. Setzen Sie Content-Type: application/json bei Schreiboperationen.

Mandanten-Scoping

Daten werden automatisch auf Ihre Organisation gefiltert, basierend auf der TenantId in Ihrem JWT.

Paginierung

Listenendpunkte unterstützen ?page=1&pageSize=20. Die Antwort enthält totalCount, page und pageSize.

Filtern & Sortieren

Die meisten Listenendpunkte akzeptieren Query-Parameter wie ?status=Open&sortBy=createdAt&sortDir=desc.

API-Endpunktgruppen

12 Ressourcengruppen für alle Plattformmodule

Authentifizierung

  • POST/api/auth/login
  • POST/api/auth/refresh
  • POST/api/auth/logout

Tickets & HelpDesk

  • GET/api/tickets
  • POST/api/tickets
  • GET/api/tickets/{id}
  • PUT/api/tickets/{id}
  • DELETE/api/tickets/{id}
  • POST/api/tickets/{id}/comments

Finanzen & Buchhaltung

  • GET/api/invoices
  • POST/api/invoices
  • GET/api/journal-entries
  • POST/api/journal-entries
  • GET/api/balance-sheet
  • GET/api/trial-balance

HR & Mitarbeiter

  • GET/api/employees
  • POST/api/employees
  • GET/api/employees/{id}
  • PUT/api/employees/{id}
  • GET/api/positions
  • GET/api/departments

Lohnabrechnung

  • GET/api/payroll
  • POST/api/payroll/run
  • GET/api/payroll/{id}
  • PUT/api/payroll/{id}/approve

Vertrieb & Aufträge

  • GET/api/orders
  • POST/api/orders
  • GET/api/quotations
  • POST/api/quotations
  • GET/api/customers
  • POST/api/customers

Beschaffung

  • GET/api/purchase-orders
  • POST/api/purchase-orders
  • GET/api/suppliers
  • POST/api/suppliers
  • GET/api/purchase-orders/{id}

Lagerverwaltung

  • GET/api/products
  • POST/api/products
  • GET/api/stock-movements
  • POST/api/stock-movements
  • GET/api/warehouses

CRM & Leads

  • GET/api/leads
  • POST/api/leads
  • GET/api/contacts
  • POST/api/contacts
  • GET/api/pipeline-stages

Arbeitsaufträge

  • GET/api/work-orders
  • POST/api/work-orders
  • GET/api/work-orders/{id}
  • PUT/api/work-orders/{id}
  • DELETE/api/work-orders/{id}

Berichte & Analysen

  • GET/api/reports/tickets
  • GET/api/reports/finance
  • GET/api/reports/hr
  • GET/api/reports/sales
  • GET/api/reports/inventory

Einstellungen

  • GET/api/settings/tenant
  • PUT/api/settings/tenant
  • GET/api/settings/users
  • GET/api/sla-configs
  • POST/api/sla-configs

HTTP-Statuscodes

Standard HTTP-Semantik wird durchgehend konsistent verwendet

200OK

Anfrage erfolgreich. Antworttext enthält das Ergebnis.

201Erstellt

Ressource erstellt. Antworttext enthält das neue Objekt mit ID.

204Kein Inhalt

Anfrage erfolgreich. Kein Antworttext (bei DELETE).

400Ungültige Anfrage

Fehlerhaft formatierte Anfrage oder fehlende Pflichtfelder.

401Nicht autorisiert

Fehlendes, abgelaufenes oder ungültiges JWT-Token.

403Verboten

Gültiges Token, aber unzureichende Berechtigungen.

404Nicht gefunden

Ressource existiert nicht oder gehört einem anderen Mandanten.

422Validierungsfehler

Eingabevalidierung fehlgeschlagen. Siehe details-Array im Antworttext.

500Serverfehler

Unerwarteter Serverfehler. Kontaktieren Sie den Support mit der Anfrage-ID.

Fehlerantwortformat

Alle Fehlerantworten folgen einer einheitlichen JSON-Struktur

Bei fehlgeschlagenen Anfragen gibt die API einen strukturierten JSON-Body zurück. Nutzen Sie das details-Array für feldspezifisches Validierungs-Feedback.

  • status — HTTP status code
  • error — Error type identifier
  • message — Human-readable description
  • details — Field-level validation errors (array)
Beispiel-Fehlerantwortjson
{
  "status": 422,
  "error": "ValidationError",
  "message": "Request validation failed",
  "details": [
    { "field": "email", "message": "Email is required" },
    { "field": "password", "message": "Minimum 8 characters" }
  ]
}

Bereit zur Integration?

Erkunden Sie die vollständige interaktive Swagger-Dokumentation oder kontaktieren Sie unser Team.