Loading Optiviera...

REST API

Dokumentacja REST API Optiviera

JSON · Uwierzytelnianie JWT · Multi-tenant

Zintegruj dowolny system z Optivierą przez w pełni udokumentowane REST API. Wszystkie punkty końcowe wymagają tokena JWT Bearer i są automatycznie ograniczone do Twojego tenanta.

Szybki start

Od zera do pierwszego wywołania API w trzech krokach

1

Uwierzytelnij się

Wyślij dane logowania do POST /api/auth/login. Odpowiedź zawiera token JWT ważny przez 24 godziny.

2

Dodaj nagłówek Auth

Dołącz token do każdego żądania: Authorization: Bearer [token]

3

Wywołaj API

Wszystkie punkty końcowe działają pod https://optiviera.com/api i odpowiadają JSON. Kontekst tenanta jest automatycznie pobierany z tokena.

Uwierzytelnianie

Każde żądanie musi zawierać prawidłowy token JWT Bearer uzyskany z punktu końcowego logowania

Jak to działa

  • POST do /api/auth/login z adresem email i hasłem
  • Przechowuj token bezpiecznie (httpOnly cookie lub w pamięci)
  • Dołącz Authorization: Bearer [token] do każdego kolejnego żądania
  • Tokeny wygasają po 24 godzinach — odśwież za pomocą POST /api/auth/refresh
Żądanie logowaniabash
curl -X POST https://optiviera.com/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","password":"••••"}'
Pomyślna odpowiedźjson
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expiresIn": 86400,
  "tokenType": "Bearer"
}
Użycie tokenahttp
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Bazowy URL i Format

Wszystko, co musisz wiedzieć przed pierwszym wywołaniem

Bazowy URL: https://optiviera.com/api — Wszystkie punkty końcowe są względne do tego bazowego URL. Zawsze używaj HTTPS.

Format JSON

Wszystkie żądania i odpowiedzi używają application/json. Ustaw Content-Type: application/json dla operacji zapisu.

Zakres tenanta

Dane są automatycznie filtrowane do Twojej organizacji za pomocą TenantId osadzonego w JWT.

Paginacja

Punkty końcowe listy obsługują ?page=1&pageSize=20. Odpowiedź zawiera totalCount, page i pageSize.

Filtrowanie i Sortowanie

Większość punktów końcowych listy akceptuje parametry zapytania jak ?status=Open&sortBy=createdAt&sortDir=desc.

Grupy punktów końcowych API

12 grup zasobów obejmujących wszystkie moduły platformy

Uwierzytelnianie

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

Zgłoszenia i HelpDesk

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

Finanse i Księgowość

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

HR i Pracownicy

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

Płace

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

Sprzedaż i Zamówienia

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

Zakupy

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

Magazyn

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

CRM i Leady

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

Zlecenia pracy

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

Raporty i Analizy

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

Ustawienia

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

Kody statusu HTTP

Standardowa semantyka HTTP jest konsekwentnie stosowana w całym API

200OK

Żądanie pomyślne. Treść zawiera wynik.

201Utworzono

Zasób utworzony. Treść zawiera nowy obiekt z ID.

204Brak treści

Żądanie pomyślne. Brak treści odpowiedzi (używane dla DELETE).

400Błędne żądanie

Nieprawidłowo sformułowane żądanie lub brakujące wymagane pola.

401Nieautoryzowany

Brakujący, wygasły lub nieprawidłowy token JWT.

403Zabroniony

Prawidłowy token, ale niewystarczające uprawnienia dla tej akcji.

404Nie znaleziono

Zasób nie istnieje lub należy do innego tenanta.

422Błąd walidacji

Walidacja danych wejściowych nie powiodła się. Zobacz tablicę details w treści odpowiedzi.

500Błąd serwera

Nieoczekiwany błąd serwera. Skontaktuj się z pomocą techniczną podając ID żądania.

Format odpowiedzi błędów

Wszystkie odpowiedzi błędów mają spójną strukturę JSON

Gdy żądanie nie powiedzie się, API zwraca ustrukturyzowaną treść JSON. Użyj tablicy details do informacji zwrotnej walidacji na poziomie pól.

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

Gotowy do integracji?

Zapoznaj się z pełną interaktywną dokumentacją Swagger lub skontaktuj się z naszym zespołem.