0

Przykład wywołania REST API KSeF w Pythonie - dla tych co zaczynają

AlicjaKowal15 lut0 wyświetleń

Cześć,

Widzę że sporo osób pyta o integracje z KSeF przez API, więc pomyślałam że wrzucę prosty przykład w Pythonie jak to wygląda w praktyce. U nas w biurze to programista zrobił cały system, ale jak testowałam środowisko demo to właśnie takim skryptem sprawdzałam podstawowe rzeczy.

**Logowanie do API:**

```python

import requests

import hashlib

import base64

url = "https://ksef-demo.mf.gov.pl/api/online/Session/InitSigned"

headers = {

"Content-Type": "application/json"

}

token = "twoj-token-autoryzacyjny" # z podpisu kwalifikowanego

data = {

"contextIdentifier": {

"type": "onip",

"identifier": "1234567890" # NIP

}

}

response = requests.post(url, json=data, headers=headers)

print(response.json())

```

To jest uproszczona wersja bo prawdziwe logowanie wymaga podpisu kwalifikowanego (InitSigned), ale żeby zrozumieć strukturę zapytań to wystarczy.

**Wysyłka faktury:**

Po zalogowaniu dostajemy SessionToken i wtedy można wysłać XML z fakturą:

```python

session_token = "twoj-session-token-z-logowania"

url = "https://ksef-demo.mf.gov.pl/api/online/Invoice/Send"

headers = {

"Content-Type": "application/xml",

"SessionToken": session_token

}

with open("faktura_FA2.xml", "rb") as f:

xml_data = f.read()

response = requests.put(url, data=xml_data, headers=headers)

print(response.json())

```

Oczywiście w produkcji to wszystko jest bardziej skomplikowane - obsługa błędów, retry, logowanie, ale zasada działania taka właśnie jest.

Największym problemem jest właściwie wygenerowanie poprawnego XMLa w schemacie FA(2) - API samo w sobie jest dość proste, REST jak REST. Polecam najpierw wrzucić kilka faktur ręcznie przez demo żeby zobaczyc jak system reaguje na błędy.

Mamy u siebie wrapper w Pythonie który to wszystko opakowuje + kolejkowanie zadań (bo jak masz 50 klientów to nie będziesz ręcznie wysyłał), ale to już temat na osobny wątek.

Jak ktoś ma konkretne pytania to chętnie pomogę w miarę możliwości.

5 odpowiedzi

0
Dzięki za przykład, przydatne zwłaszcza to z SessionToken bo w dokumentacji MF jakoś tak pokrętnie to opisali że człowiek się gubi. Tylko mam pytanie - pisałaś że "wrapper w Pythonie który to wszystko opakowuje" - to jakaś wasza własna biblioteka czy używacie czegoś gotowego? Bo widzę że na GitHubie są już jakieś projekty tylko nie wiem czy warto na nie stawiać czy lepiej samemu napisać od zera. I jeszcze jedno - wspomniałaś o retry. Jak często się zdarza że API KSeF zwraca błędy typu timeout albo 500? Bo jak to ma być obowiązkowe od lutego to ciekawe jak będzie wyglądała stabilność jak wszyscy naraz zaczną walić requestami... U nas na razie nawet nie zaczęliśmy testów, księgowa mówi że "poczekamy jak inni przetestują" ale ja się obawiam że jak będziemy zwlekać to potem będzie panika w ostatniej chwili.
0
Co do wrappera - my mamy własny napisany przez programistę, który u nas pracuje. Testowałam kilka gotowych bibliotek z GitHuba ale szczerze mówiąc poziom był różny, część nie była aktualizowana od miesięcy, a jak wiadomo MF lubi zmieniać specyfikację więc wolałam nie ryzykować. Poza tym nasz wrapper jest dostosowany do naszego workflow - mamy integrację z systemem księgowym, automatyczne kolejkowanie w godzinach nocnych (żeby nie obciążać API w szczycie), logowanie do bazy wszystkich operacji itd. Jeśli macie programistę in-house to moim zdaniem lepiej napisać coś własnego, przynajmniej będziecie wiedzieć co się dzieje pod maską. Odnośnie stabilności API - no i tutaj jest temat rzeka. W środowisku demo błędy 500 zdarzają się sporadycznie, może raz na kilkaset requestów, ale timeouty to już częstsza sprawa, szczególnie jak się testuje w godzinach 10-14 gdy pewnie wszyscy księgowi próbują. Mamy ustawione retry z exponential backoff - czyli pierwsza próba po 2 sekundach, druga po 4, trzecia po 8 itd. maksymalnie 3 próby. W 90% przypadków druga próba przechodzi. Ale powiem szczerze - jestem sceptyczna jak to będzie wyglądać w lutym 2026 gdy wszyscy będą musieli używać. Teraz środowisko demo ma pewnie ułamek ruchu który będzie w produkcji. U nas mamy około 400 faktur dziennie dla wszystkich klientów łącznie, więc jesteśmy przygotowani na to że czasem trzeba będzie poczekać albo wysłać ponownie. Ale jak sobie wyobrażam wielkie korporacje z tysiącami faktur dziennie... Co do czekania - zdecydowanie odradzam podejście "poczekamy". My zaczęłyśmy testy pół roku temu i dobrze bo wyszło mnóstwo problemów które w dokumentacji nie były jasne. Sam proces wdrożenia u klientów to też sprawa minimum 2-3 miesięcy bo trzeba przeszkolić ludzi, prz
0
Wdrozeniowiec3 dni temu
Z perspektywy architekta IT mogę potwierdzić to co pisze Beata - własny wrapper to zdecydowanie lepsza opcja jeśli macie zasoby. My u siebie poszliśmy w podobną stronę ale trochę inaczej podeszliśmy do tematu skalowania. Zrobiliśmy całą integrację jako microservice z message queue (RabbitMQ), gdzie aplikacje biznesowe wrzucają faktury do koejki a nasz serwis KSeF pobiera je asynchronicznie i wysyła. Dzięki temu mamy pełną kontrolę nad throughputem - możemy regulować ile requestów na minutę wysyłamy, mamy dead letter queue dla błędów, monittoring, retry policy itp. Plus łatwo możemy saklować horyzontalne jeśli trzeba będzie. Co do stabilności - testowaliśmy pod różnym obciążeniem i faktycznie, API KSeF ma swoje momenty. Szczególnie problematyczne są godziny 9-11 i 14-16. Dlatego u nas większość faktur leci w nocy lub wcześnie rano. Mamy też circuit breaker pattern - jak API zwraca za dużo błędów to automatycznie przerywamy na jakiś czas i próbujemy później. Jedna rzecz którą bym dodał do przykładu - warto implementować idempotency. KSeF ma swoje mechanizmy ale lepiej mieć własne ID dla każdej operacji żeby uniknąć duplikatów jak coś się popsuje w trakcie retry. Robert, jeśli chodzi o gotowe biblioteki to rzezcywiście są różnej jakości. Widziałem kilka projektów które wyglądają obiecująco ale problem jest taki że jak coś nie działa to siedzisz i debugujesz czyjś kod zamiast swój. A przy integracji z systemem krytycznym jak fakturowanie to wolę mieć pełną kontrol.ę
0
Świetny przykład! Właśnie takich praktycznych reczy potrzeba na forum. **Jedna uwaga do kodu** - w prawdziwej integraji polecam doadć walidację response'a przed próbą parsowania JSON: ```python if response.status_code == 200: result = response.json() session_token = result.get('sessionToken', {}).get('token') else: print(f"Błąd logowania: {response.status_code}") print(response.text) ``` Bo jak API zwróic błąd to `response.json()` może wywali exception. **Co do gotowych bbiliotek** - zgadzam się z Beatą. Testowałem kilka z GitHuba ale większość nie radzi sobie z edge cases'ami. Na przykład jedna biblioteka nie obsługiiwała poprawnie faktur korygujących, inna miała problemy z kodowaniem polskich znaków. Jak masz programisę to lepiej napisać swoje - przynajmniej wiesz co robi każda linijka. **Dodatkowo polecam:** - Zawsze testuj na środowisku demo z prawdziwymi danymi (ale zanonimizowanymi) - Loguj każdy request/response - jak coś nie działa to będziesz miał materiał do analizy - Zrób sobie prosty dashboard żeby monitorować ile faktur przeszło/nie przeszło Robert, nie czekajcie do ostatniej chwili. Już teraz środowisko demo czasem "leży" przez kilka godzin, a jak wszyscy naraz zaczną testować w grudniu 2025 to będzie masakra.
0
VATreturns_PL3 dni temu
Bardzo przydatny przykład! Właśnie takiej praktycznej wiedzy brakuje w oficjalnej dokumentacji MF. Dodałbym jeszcze jedą rzecz do przykładu - **obsługę błędów walidacji XML**. U nas w integracji to największy problem bo KSeF zwraa błędy które nie zawsze są czytelne: ```python if response.status_code == 400: error_details = response.json() if 'validationErrors' in error_details: for error in error_details['validationErrors']: print(f"Błąd walidacji: {error['message']} w ppolu {error['path']}") ``` Robert, co do retry - u nas statystyki wyglądają tak że około 5-8% reqeustów wymaga ponowienia, głównie timeouty. Najgorsze godziny to rzeczywiście 10-14 jak pisała Beata. Mamy ustaione maksymalnie 3 próby z delays 2s, 5s, 10s. **Ważne:** jeśli implementujecie własny wrapper to pamiętajcie o **idempotency**. KSeF ma wbudowane mechanizmy ale lepiej mieć własny UUID dla każdej operacji: ```python headers = { "Conten-tType": "application/xml", "SessionToken": session_token, "Request-Id": str(uuid.uuid4()) # unikalny ID operacji } ``` Dzięki temu jak request się powtórzy to nie będziecie mieli duplikatów w systemie. Co do gotowych bilbiotek - zgoda z kolegami. Testowałem kilka projektów z GitHuba ale poziom jest różny, a jak coś nie działa to debugowanie cudzego kodu to koszmar. Leipej napisać swoje 200 linijek kodu które rozumiesz niż męczyć się z biblioteką która ma 2000 linijek ale nie wiadomo co robi w edge cases.

Twoja odpowiedź

Zaloguj się, aby odpowiedzieć w tej dyskusji.