Changelog

Zmiany niekompatybilne dostają nową wersję w ścieżce. Nowe pola dodajemy bez zapowiedzi — parsuj odpowiedzi tolerancyjnie i ignoruj nieznane klucze.

25 października 2026 — boty czatu w serwerze MCP

Zmiana kompatybilna wstecz: nowe pola i jedno nowe narzędzie. Istniejące klucze i trasy zostają.

Dodane channelSettings w GET i PATCH /bots/{botId}/config oraz w wynikach narzędzi MCP get_bot_config i update_bot_config. To ustawienia czatu na stronie: powitanie, komunikat przekazania i tekst blokady. Zapis tego pola działał już wcześniej; odczyt go pomijał.
Dodane narzędzie MCP update_bot — to samo co PATCH /bots/{botId}: nazwa, aktywność, kanały i numer. Działa od razu, nie jest wersją roboczą. Nowy kanał można dodać tylko wtedy, gdy organizacja może z niego korzystać.
Zmienione GET /bots/{botId}/readiness i get_bot_readiness są świadome kanałów. readyForWebChat mówi, czy widget czatu jest podpięty. Bot tylko czatowy nie wymaga numeru (readyForOutbound: false nie jest wtedy usterką). Przy włączonych rezerwacjach na czacie pojawiają się kontrole WEB_CHAT_BOOKING_WIDGET_MISSING i WEB_CHAT_BOOKING_SMS_MISSING.
Zmienione get_prompting_guidance zwraca też blok chat z zasadami dla czatu na stronie.
Widget (domeny i kolory), podgląd czatu, crawl strony do bazy wiedzy i przełączniki Terminarza zostają w aplikacji — serwer MCP o tym mówi, ale ich nie wykonuje.

19 października 2026 — modele botów konfiguruje Mediflo; bez kosztów i tokenów w odpowiedziach

Ścieżki i zakresy bez zmian. Zmienia się zawartość kilku odpowiedzi i to, które pola konfiguracji bota możesz zmieniać. Klucz działa z uprawnieniami osoby, która go utworzyła (przy połączeniu przez OAuth — osoby zalogowanej); poniższe ograniczenia nie dotyczą kluczy pracowników Mediflo.

Zmienione modele bota konfiguruje zespół Mediflo. PATCH /bots/{botId}/config odrzuca zmianę modelConfig, remarksLlmModelId i dawnych agentLlmModelId / agentSttModelId / agentTtsModelId błędem 403 BOT_MODEL_CONFIG_STAFF_ONLY (w details.fields — które pola); narzędzie MCP update_bot_config odmawia tak samo. Odesłanie niezmienionej, odczytanej wartości nadal działa. Te pola zniknęły z opublikowanego schematu wejścia. POST /bots i create_bot nadal zapisują w nowym bocie rekomendowane modele.
Zmienione GET /bots/{botId}/config, odpowiedzi PATCH /bots/{botId}/config i POST /bots/{botId}/config/rollback oraz narzędzia MCP get_bot_config, update_bot_config i rollback_bot_config nie zawierają klucza modelConfig.
Zmienione GET /model-catalog zwraca tylko recommendedDefaults, bez modelConfig i extraction; models, recommendedChains i extractionModels nie są zwracane. Narzędzie MCP get_recommended_defaults działa tak samo, a list_extraction_models odmawia.
Zmienione narzędzie MCP get_prompting_guidance zwraca ogólne zasady pisania promptu (general.guidance), bez wskazówek dla konkretnych modeli i bez listy źródeł.
Zmienione GET /bot-sessions/{dispatchId}/telemetry i narzędzie MCP get_bot_session_telemetry: pipelineMetrics zawiera tylko opóźnienia i liczniki żądań (np. avg_ttft_s, avg_ttfb_s, avg_eou_delay_s, request_count, cancelled_count). Liczby tokenów, sekundy audio rozpoznawania mowy i liczba znaków syntezy nie są zwracane.
Zmienione żadna odpowiedź API ani narzędzia MCP nie zawiera pól kosztów, tokenów ani jednostek rozliczeniowych dostawców (np. cost, usage, inputTokens, total_tokens, total_characters). Ceny Twoich usług (price, priceAmount) bez zmian.
Zmienione narzędzia MCP trunków: ustawienie redukcji szumów w kierunku przychodzącym nazywa się noiseReduction (dotąd enableKrisp) — w odpowiedziach (inbound.noiseReduction) i na wejściu create_carrier_trunk oraz update_carrier_trunk_direction. Stara nazwa jest nadal przyjmowana na wejściu.

13 października 2026 — sprawy klientów w API i w serwerze MCP

Nowa rodzina tras i narzędzi, dwa nowe zakresy. Istniejące trasy i klucze bez zmian — także klucze z * nie dostają spraw, bo oba zakresy trzeba nadać wprost. Dostępne w organizacjach biznesowych, które mają włączone sprawy. Szczegóły: sprawy.

Dodane zakresy cases.read i cases.write (zapis obejmuje odczyt). Przy logowaniu asystenta przez OAuth wynikają z uprawnień cases.view i cases.manage.
Dodane trasy GET /cases, POST /cases, GET /cases/{caseId}, PATCH /cases/{caseId}, GET i POST /cases/{caseId}/comments, POST /cases/{caseId}/links, DELETE /cases/{caseId}/links/{linkId}.
Dodane narzędzia MCP list_cases, get_case, create_case, update_case.
Dodane webhooki case.created, case.updated (z polem changed) i case.deleted. Treść notatek nigdy nie trafia do webhooka. Typy zdarzeń widzą tylko organizacje z włączonymi sprawami.

12 października 2026 — profil taksonomii w `call.analysis.completed`

Zmiana kompatybilna wstecz: nowe pole w zdarzeniu, kształt pozostałych pól bez zmian.

Dodane insights.profile w zdarzeniu call.analysis.completed — taksonomia, z której pochodzą wartości primaryIntent, category, payer i booking: medical, commercial, b2b albo b2c (lista może się wydłużyć). null oznacza, że profil nie jest znany — na przykład dla rozmów przeanalizowanych przed wprowadzeniem profili.
Zmienione organizacje z branżą inną niż medyczna albo bez ustawionej branży dostają wartości z taksonomii commercial, b2b lub b2c (np. category równe order_status, service_request albo quote_pricing) zamiast medycznych, a payer ma u nich zawsze wartość null. W organizacjach medycznych wartości się nie zmieniają.

12 października 2026 — neutralna nazwa osoby w terminie rozmowy bota

Zmiana kompatybilna wstecz: dotychczasowe pole działa jak dawniej.

Dodane context.appointment.staffName (alias doctorName) w POST /bot-sessions i narzędziu MCP create_bot_session — osoba, z którą jest umówiony termin (pracownik, specjalista, konsultant). Trafia do tej samej zmiennej {{appointment_doctor_name}}. doctorName nadal działa; oba pola naraz są przyjmowane tylko z tą samą wartością.

1 października 2026 — telefonia Twojej organizacji przez MCP: trunki SIP, drzewka IVR i kolejki

Nowe narzędzia MCP do konfiguracji telefonii Twojej organizacji i sześć nowych zakresów. Powierzchnia REST bez zmian. Istniejące klucze — także z * — nie dostają tych narzędzi: zakresy trzeba nadać wprost, a zakresy zapisu nadaje tylko administrator (nigdy logowanie asystenta przez OAuth). Szczegóły: zakresy.

Dodane zakresy trunks.read, trunks.write, ivr-flows.read, ivr-flows.write, queues.read, queues.write. Zakres zapisu obejmuje odpowiadający mu odczyt.
Dodane trunki SIP: list_trunk_providers (obsługiwani operatorzy i to, jak operator ma się z nami łączyć), list_trunks, get_trunk (z prostą diagnostyką: stan rejestracji, synchronizacja z bramką SIP, lista kontrolna gotowości, liczba połączeń z ostatnich 24 h i 7 dni), create_carrier_trunk, update_carrier_trunk, update_carrier_trunk_direction, set_trunk_phone_numbers. Hasło trunka można tylko zapisać — nigdy nie wraca w odpowiedzi; zamiast podawać je w rozmowie, można je wpisać w Portalu pod adresem portalUrl z odpowiedzi. Trunki z rejestracją centrali (peer) narzędzia tylko odczytują.
Dodane drzewka IVR: list_ivr_flows, get_ivr_flow, get_ivr_flow_schema, list_ivr_audio_assets, validate_ivr_flow, create_ivr_flow, create_ivr_flow_version, save_ivr_flow_draft, activate_ivr_flow_version, assign_ivr_flow_to_phone_number, detach_ivr_flow_from_phone_number. Narzędzia edytują wyłącznie wersje robocze; aktywacja i przypisanie numeru działają od następnego połączenia, a aktywacja zwraca identyfikator poprzedniej wersji do wycofania jednym wywołaniem.
Dodane kolejki: list_queues, get_queue, list_queue_member_candidates, create_queue, update_queue, add_queue_member, update_queue_member, remove_queue_member, set_queue_member_schedules, set_user_external_phone_number. Prywatne numery, na które dzwoni kolejka zewnętrzna, w odpowiedziach są zawsze zamaskowane.
Zmienione przypisanie do trunka numeru, który jest aktywny w innej organizacji, kończy się błędem PHONE_NUMBER_UNAVAILABLE. Adres IP operatora musi być publiczny i nie szerszy niż /24 (IPv4) lub /64 (IPv6).

29 września 2026 — webhooki bez pracowników wsparcia Mediflo

Kształt zdarzeń bez zmian — zmienia się tylko to, kogo mogą wskazywać.

Zmienione webhooki task.created, task.updated i call.completed nie wskazują pracowników wsparcia Mediflo pracujących w Twoim workspace — tak jak odpowiedzi API od 28 września. Gdy zadanie jest przypisane lub sugerowane takiej osobie albo taka osoba obsłużyła rozmowę, assignedTo, suggestedAssignee lub agent ma wartość null. Samo zdarzenie, zadanie i rozmowa zostają.

28 września 2026 — mniej danych wewnętrznych w odpowiedziach

Powierzchnia API bez zmian w ścieżkach i zakresach. Zmienia się zawartość kilku pól — parsuj je tolerancyjnie, jak zawsze.

Zmienione GET /bot-sessions/{dispatchId}/telemetry i narzędzie MCP get_bot_session_telemetry: other zawiera wyłącznie wybrany zestaw dodatkowej diagnostyki — czasy połączenia, liczniki ciszy i rozpoznawania mowy, wynik detektorów (np. poczty głosowej) oraz ścieżkę przez przepływ rozmowy (węzły, bez zebranych wartości). Komunikaty błędów zgłaszanych przez środowisko wykonawcze bota są skracane do typu błędu; krótkie, sklasyfikowane komunikaty (np. status SIP) zostają bez zmian. Pełną treść widzi wsparcie Mediflo.
Zmienione odpowiedzi nie pokazują pracowników wsparcia Mediflo pracujących w Twoim workspace. W połączeniach (GET /calls, list_calls, get_call) i zadaniach (GET/POST /tasks, GET/PATCH /tasks/{taskId}, list_tasks, create_task) w miejscu ich danych jest null, a ich wpisy w assignees znikają — sam rekord, połączenie czy zadanie, zostaje. GET /users ich nie zwraca, a statystyki zadań (get_task_statistics) nie mają dla nich wiersza.
Zmienione aggregate_calls (wymiar disconnect_reason) i get_ivr_statistics: zakończenia rozmowy po stronie platformy są zgrupowane jako SYSTEM_ENDED.
Zmienione odmowy POST /bot-sessions (create_bot_session) zwracają w details tylko reason, pola kraju (phone_country, default_country, allowed_countries) i dispatchId.

26 września 2026 — MCP `get_call`: komunikaty IVR na jednej rozmowie

Dodane narzędzie MCP get_call (zakres calls.read). Zwraca jedną rozmowę — te same pola co wiersz list_calls — oraz tablicę announcements: przybliżona rekonstrukcja z osi czasu IVR rozmowy, aktualnej flowDefinition przypiętej wersji przepływu i tabeli audio_assets. Węzły: audio, menu, hangup (tylko gdy węzeł ma plik audio) i intent. Gdy wersja przepływu się nie wczyta (brak ivr_flow_version_id albo usunięta wersja), hangup bez pliku audio i tak pojawia się w wyniku.
Zdarzenie ivr.node.entered powstaje, zanim silnik rozwiąże albo odtworzy audio. enteredAt to znacznik czasu tego zdarzenia, a niepotwierdzony początek ani koniec odsłuchu. Wynik nie jest dowodem, że rozmówca usłyszał ten zasób.
ivr_flow_version_id wskazuje wiersz, którego flowDefinition nadal można nadpisać w miejscu. Historyczne get_call może więc pokazać późniejszą edycję tej wersji, a nie zamrożony obraz tego, co poszło na linii. v1 zostawia to złączenie jako best-effort. Trwałe rozwiązanie to zapis audioAssetId i durationSeconds na zdarzeniu osi czasu w chwili emisji — poza tym wydaniem.
content to tekst TTS zasobu audio, gdy kolumna text jest uzupełniona; w przeciwnym razie nazwa wyświetlana zasobu (albo name); dla węzła intent bez treści i nazwy zasobu — promptText; na końcu etykieta węzła. contentSource mówi, które źródło zostało użyte (tts_text, display_name, node_label) albo jest null. To nie jest transkrypcja wypowiedzi rozmówcy.
durationSeconds pochodzi z audio_assets.duration, gdy złączenie z zasobem się uda. Rozmowa bez ivr_flow_version_id, z usuniętą wersją albo z węzłem, którego nie ma w tej wersji, nadal zwraca wpisy z osi czasu: treść z etykiety węzła, a durationSeconds równe null.
Bez zmian list_calls i GET /api/external/v1/calls — lista nie dostaje tych pól. Nie ma odpowiednika REST. serverVersion zostaje 0.6.0. Wersje przepływu IVR nie stają się niemutowalne.

Przykład announcements:

[
  {
    "nodeId": "audio-welcome",
    "nodeType": "audio",
    "nodeLabel": "Powitanie",
    "audioAssetId": "44444444-4444-4444-8444-444444444444",
    "content": "Dzień dobry, tu rejestracja.",
    "contentSource": "tts_text",
    "durationSeconds": 4.2,
    "enteredAt": "2026-09-26T08:00:01.000Z"
  },
  {
    "nodeId": "menu-main",
    "nodeType": "menu",
    "nodeLabel": "Menu główne",
    "audioAssetId": "55555555-5555-4555-8555-555555555555",
    "content": "Menu główne",
    "contentSource": "display_name",
    "durationSeconds": 8,
    "enteredAt": "2026-09-26T08:00:06.000Z"
  }
]

25 września 2026 — serwer MCP 0.6.0: nowe SDK i protokół `2026-07-28` per organizacja

Serwer MCP działa na nowej wersji SDK. Wersję protokołu 2026-07-28 włączamy per organizacja, na prośbę — bez tego żądanie w tej wersji dostaje, jak dotąd, 400 i -32000, a klient wraca do 2025-11-25. Powierzchnia REST bez zmian.

Dodane wersja protokołu MCP 2026-07-28, włączana per organizacja: koperta params._meta w każdym żądaniu (protocolVersion i clientCapabilities), nagłówek Mcp-Method, a przy tools/call także Mcp-Name, opcjonalne sondowanie server/discover, bez rundy initialize i bez sesji. Strumień subscriptions/listen nie jest obsługiwany (404, -32601) — serwer jest bezstanowy i ogłasza listChanged: false. Szczegóły: instalacja.
Bez zmian wersje 2025-11-25, 2025-06-18 i 2025-03-26 (oraz starsze, od 2024-10-07) działają jak dotąd. Istniejące połączenia nie wymagają ponownego łączenia ani zmian konfiguracji, a narzędzia, ich opisy i schematy wejściowe (JSON Schema draft-07) są te same.
Zmienione wywołanie nieznanego narzędzia (także takiego, na które połączenie nie ma zakresu) zwraca błąd JSON-RPC -32602 zamiast wyniku z flagą isError, w każdej wersji protokołu i w każdej organizacji. Biblioteki klienckie — np. ClientSession.call_tool w SDK dla Pythona i callTool w SDK TypeScript v1 — zgłaszają teraz wyjątek, zamiast zwrócić wynik z błędem.
Zmienione tools/call bez pola arguments wykonuje narzędzie (argumenty są sprawdzane jak {}); dotąd kończyło się wynikiem z isError.
Zmienione tools/call w wersji 2025-11-25 z parametrem task wykonuje narzędzie; dotąd serwer odmawiał kodem -32603.
Zmienione tools/list nie zwraca już pola execution ({"taskSupport": "forbidden"}) — brak pola znaczy to samo. Komunikaty walidacji argumentów mają inny format tekstu.
Zmienione w organizacjach z włączoną wersją 2026-07-28 żądanie w wersji 2025, które ma w _meta klucz io.modelcontextprotocol/protocolVersion, jest odrzucane (400, -32022); bez włączenia działa jak dotąd.
Zmienione get_server_info raportuje serverVersion: "0.6.0", a latestProtocolVersion i supportedProtocolVersions wymieniają 2026-07-28 tylko w organizacjach, które ją mają.

7 września 2026 — dokumentacja przeniesiona na `docs.mediflo.ai`

Zamiast jednego pliku Markdown masz renderowaną, przeszukiwalną stronę po polsku. Powierzchnia API bez zmian.

Dodane katalog narzędzi MCP i katalog zdarzeń webhook publikowane jako JSON: /api/mcp-tools.json i /api/webhook-events.json. Generuje je ten sam przebieg, co openapi.json, więc nie mogą się rozjechać z kodem.
Zmienione stary plik rest-api.md przestał istnieć; jego treść żyje tutaj, a poprzedni adres przekierowuje na /api/.
Bez zmian /api/openapi.json i /api/llms.txt serwują dokładnie te same bajty pod tymi samymi adresami.

1.7.0 — 6 września 2026

Dodane GET /bot-sessions/{dispatchId}/recording (zakres bot-calls.read). Zwraca podpisany adres URL do nagrania rozmowy, ważny przez 15 minut; available: false, gdy sesja nie ma zapisanego nagrania. Webhook bot_call.completed już wcześniej podawał tę ścieżkę w links.recording — dotąd odpowiadała 404.
Dodane links.recording w GET /bot-sessions/{dispatchId} (i w narzędziu MCP get_bot_session, które zwraca ten sam obiekt). Zmiana addytywna — dotychczasowe telemetry i transcript bez zmian.
Nagranie nie ma narzędzia MCP: podpisany adres audio to nie jest coś, na czym agent może działać, ani coś, co chcemy przepuszczać przez kontekst modelu. Użyj endpointu REST.

1.6.1 — 6 września 2026

Powitania zależne od kierunku rozmowy. Bot może inaczej otwierać rozmowy przychodzące i wychodzące, a każde z powitań da się wyłączyć.

Dodane opcjonalne greetingConfig.byDirection: { inbound?, outbound? } w GET/PATCH /bots/{botId}/config oraz w get_bot_config / update_bot_config. Każdy wpis to static, llm albo { "type": "off" } (bot czeka na rozmówcę, a po ok. 4 s ciszy improwizuje otwarcie); brakujący klucz zachowuje wspólne powitanie. Zmiana addytywna — istniejące konfiguracje bez zmian.
Zmienione ostrzeżenie gotowości ai_disclosure sprawdza teraz wspólne powitanie i powitanie każdego kierunku, więc powitanie przychodzące bez ujawnienia AI jest zgłaszane nawet wtedy, gdy wspólne je zawiera.

1.6.0 — 6 września 2026

Połączenia wychodzące zlecane przez partnera. Twój system może zlecić rozmowę bota z pacjentem, zamiast wysyłać SMS — patrz POST /bot-sessions.

Zmienione get_server_info raportuje teraz serverVersion: "0.4.0".
Dodane POST /bot-sessions oraz narzędzie MCP create_bot_session, oba pod nowym zakresem bot-calls.write. Dzwoni od razu (bez planowania), wymaga idempotencyKey (powtórka → 200 z istniejącą sesją, nigdy drugie połączenie), odmawia poza 08:00–20:00 czasu tenanta (OUTSIDE_CALL_WINDOW) i przyjmuje typowaną kopertę context (reason, message, appointment, variables) renderowaną w prompcie bota.
Dodane kody błędów OUTSIDE_CALL_WINDOW, IDEMPOTENCY_KEY_REUSED, BOT_INACTIVE, BOT_SESSION_LINE_BUSY, BOT_SESSION_CREATE_FAILED.
Zmienione GET /bot-sessions raportuje status: FAILED dla sesji, które zostały przyjęte, ale nigdy się nie połączyły — wcześniej czytały się jako COMPLETED, podczas gdy webhook bot_call.completed mówił failed.
Sesje zlecone tą drogą noszą attemptId w formacie ext-<dispatchId>.

1.5.0 — 20 sierpnia 2026

Pętla wsparcia przez MCP. Wszystko, co 1.4.0 dodało do REST, jest teraz dostępne jako narzędzia MCP — agent może zdiagnozować rozmowę i ją zgłosić bez przeglądarki.

Dodane list_bot_sessions, get_bot_session, get_bot_session_telemetry i get_bot_session_transcript (zakres bot-calls.read). Telemetria i transkrypcja zostają dwoma osobnymi narzędziami z tego samego powodu, dla którego są dwoma endpointami: diagnostyka nigdy nie niesie treści rozmowy.
Dodane create_support_ticket, attach_sessions_to_ticket, list_support_tickets i get_support_ticket (zakresy tickets.read / tickets.write). Zgłoszenia założone tą drogą są oznaczane reportedVia: "mcp" i — o ile wywołujący nie poda reportedByUserId — nie mają zgłaszającego.
Zmienione get_server_info raportuje serverVersion: "0.3.0".

1.4.0 — 20 sierpnia 2026

Sesje botów i zgłoszenia do wsparcia — headless pętla wsparcia.

Dodane GET /bot-sessions, GET /bot-sessions/{dispatchId}, GET /bot-sessions/{dispatchId}/telemetry i GET /bot-sessions/{dispatchId}/transcript (zakres bot-calls.read). Telemetria i transkrypcja są osobnymi endpointami celowo: diagnostyka nigdy nie niesie treści rozmowy, więc można debugować rozmowę bez wyciągania wypowiedzi pacjenta.
Dodane GET /tickets, POST /tickets, GET /tickets/{ticketId} i POST /tickets/{ticketId}/sessions (zakresy tickets.read / tickets.write). Zgłoszenie może nieść sesje botów, które SĄ problemem, jako pełnoprawne odnośniki, a nie URL w komentarzu.
Zmienione zgłaszający jest teraz opcjonalny. Ticket.reportedByUserId może być null, a nowy znacznik reportedVia zapisuje, którymi drzwiami przyszło zgłoszenie (external_api, mcp, albo null dla Portalu). Podaj reportedByUserId, kiedy wiesz, kto zgłasza; pomiń go, a zgłoszenie powstanie bez zgłaszającego, zamiast być przypisane komuś, kto go nie założył. Żadne istniejące zgłoszenie się nie zmieniło.

1.3.0 — 20 sierpnia 2026

Dodane narzędzia MCP do zarządzania botami — headless powierzchnia botów jest dostępna przez MCP tak samo jak przez REST: boty, wersje robocze konfiguracji, przepływy (razem z szablonami po stronie serwera i bezstanową walidacją), źródła wiedzy, gotowość i publikacja z wersjonowanym wycofaniem (publish_bot_config, list_config_versions, rollback_bot_config).
Dodane get_recommended_defaults i list_extraction_models — odpowiedniki recommendedDefaults i extractionModels z GET /model-catalog, serwowane z tego samego źródła, żeby headless klient nigdy nie musiał wymyślać stosu modeli ani zgadywać, skąd wziąć poprawne remarksLlmModelId.
Bot utworzony przez MCP przychodzi wstępnie skonfigurowany: create_bot od razu wypełnia rekomendowany modelConfig, turnTakingMode i model ekstrakcji.
Narzędzia są ogłaszane w kolejności konfiguracji, a te modyfikujące zwracają tablicę nextSteps z nazwą wywołania, które logicznie następuje dalej. Obowiązuje reguła: zmiany konfiguracji — również to, co odtwarza podgląd bota — działają dopiero po publikacji.

1.2.1 — 20 sierpnia 2026

Dodane GET /model-catalog zwraca teraz extractionModels — listę wyboru modelu ekstrakcji pouwagowej (remarks), z której remarksLlmModelId bierze identyfikatory. To pole jest wymagane do publikacji bota, a katalog za nim nie miał zewnętrznej powierzchni, więc headless klient mógł skonfigurować bota, ale nigdy go opublikować. Lista zawiera wyłącznie modele obsługujące structured output.
POST /bots/{botId}/config/publish dołącza teraz details.hint do 400 BOT_CONFIG_INCOMPLETE, kiedy brakuje remarksLlmModelId, wskazując endpoint, z którego bierze się identyfikator. details.missingFields bez zmian.

1.2.0 — 19 sierpnia 2026

Dodane serwer MCP pod POST /api/external/mcp — bezstanowy streamable HTTP, uwierzytelniany tymi samymi kluczami mflo_…, z narzędziami filtrowanymi po zakresach klucza. Wystartował z get_server_info, list_calls, list_tasks i create_task; pełna powierzchnia narzędzi przyszła w 1.3.0. Jedna wiadomość na żądanie — wsadowe JSON-RPC jest odrzucane, a ciała są ograniczone do 1 MB.

1.1.0 — 19 sierpnia 2026

Dodane

Limity zapytań — 600 odczytów / 120 zapisów na klucz na minutę, 429 z Retry-After.
Rotacja klucza API z konfigurowalnym oknem karencji (1–168 h), żeby wymieniać poświadczenia bez przestoju.
Udokumentowane endpointy, które istniały, ale brakowało ich w opisie: GET /calls, GET /contact-requests, POST /contact-requests.
Audyt — każde zewnętrzne żądanie trafia do dziennika audytu workspace (nigdy ciała żądań ani odpowiedzi).

Zmienione

GET /tasks zwraca teraz totalPages; pages zostaje jako przestarzały alias i zniknie w kolejnej wersji głównej. Arytmetyka bez zmian: totalPages to ceil(total / limit), więc pusty wynik nadal daje 0.
GET /contact-requests i POST /contact-requests zwracają teraz jawny, udokumentowany zestaw pól — pola spoza kontraktu nie są już zwracane. Obiekty prób są przycięte do id, status, result, startedAt, completedAt, a obiekt paginacji ma wyłącznie pola opisane w Paginacji.
Awaria backendu podczas weryfikacji klucza zwraca teraz 503 EXTERNAL_API_UNAVAILABLE zamiast 401 — ponów zamiast rotować poświadczenia.
VALIDATION_ERROR.details jest konsekwentnie tablicą { field, message }, również przy sprawdzaniu formatu identyfikatora zadania na /tasks/{taskId}.
Przykład niewystarczającego zakresu pokazuje prawdziwe klucze payloadu (requiredScope / availableScopes).
Nieznane zakresy są odrzucane przy tworzeniu klucza. users.write i tags.write nigdy nie zostały zaimplementowane i nie da się ich już przyznać.

1.0.0 — luty 2026

Pierwsze wydanie

Operacje CRUD na zadaniach.
Endpoint listujący użytkowników (tylko odczyt).
Endpoint listujący tagi (tylko odczyt).
Uwierzytelnianie kluczem API z HMAC-SHA256.
Uprawnienia oparte na zakresach.
Spójna obsługa błędów.

Wsparcie

Coś nie działa? Załóż zgłoszenie przez POST /tickets razem z identyfikatorami sesji, które nie zadziałały — wtedy nie musimy pytać, o którą rozmowę chodzi.

Na tej stronie