DPP Registry API – jak przygotować integrację?

Co oficjalnie obsługuje API?

Rozporządzenie wykonawcze (UE) 2026/1778 wymienia API jako jeden z elementów architektury Registry. Kanał ten ma umożliwiać rejestrację DPP i odbieranie informacji z rejestru. Po pomyślnej walidacji unikalny identyfikator rejestracyjny jest zwracany w odpowiedzi API.

Komisja zapowiada również dokumentowane API do repozytorium semantycznego zawierającego maszynowo czytelne modele danych, definicje i słownictwo dla grup produktowych.

Aktualny publiczny User Guide dla operatorów koncentruje się na formularzu online i przesyłaniu plików JSON/XML. Nie publikuje pełnego kontraktu endpointów ani kompletnej procedury uwierzytelnienia integracji. Tych elementów nie należy zgadywać — źródłem prawdy musi być bieżąca dokumentacja techniczna dostępna w Registry.

Gdzie umieścić adapter Registry?

Registry powinno pozostać adapterem integracyjnym. Schemat Komisji ani format konkretnego ERP nie powinny stać się rdzeniem modelu produktu. Dzięki temu zmiana API, schematu produktowego albo systemu źródłowego nie wymusza przebudowy całej aplikacji.

Dane potrzebne przed wywołaniem

Zakres zależy od aktu dla grupy produktu, ale proces powinien umieć przygotować co najmniej:

• unikalny identyfikator produktu prowadzący do DPP
• identyfikatory modelu i partii, gdy dotyczą wybranej granularności
• właściwą grupę produktu i poziom model–partia–sztuka
• wymagane dane rejestracyjne i metadane wysokiego poziomu
• kod towarowy, gdy jest wymagany
• odniesienie do dostawcy usług DPP i backupu, gdy jest wymagane
• identyfikator zweryfikowanego operatora i kontekst uprawnień

Pełna treść produktu pozostaje w DPP utrzymywanym poza Registry. Integracja nie powinna wysyłać dodatkowych danych prywatnych tylko dlatego, że są dostępne w ERP.

Jak obsłużyć automatyczną walidację?

Adapter powinien rozróżniać błędy danych od awarii technicznych. Rozporządzenie przewiduje kontrole semantyki, spójności danych, granularności, kodu towarowego i linku backupu. Przewodnik pokazuje też błędy niezgodnego schematu, zduplikowanego UPI, niepoprawnego URL i chwilowej niedostępności walidacji semantycznej.

• błąd deterministyczny danych: oznacz wpis jako wymagający korekty i nie ponawiaj bez zmiany danych
• błąd przejściowy usługi: zastosuj kontrolowane ponowienie zgodnie z dokumentacją API
• wynik w toku: zachowaj correlation ID i odczytuj status w obsługiwany sposób
• sukces: zapisz identyfikator rejestracyjny przy konkretnej wersji DPP
• częściowa porażka: nie zakładaj częściowego sukcesu bez potwierdzenia kontraktu; w przepływie plikowym jeden błędny DPP odrzuca całe zgłoszenie

Idempotencja i duplikaty

Każdy DPP musi mieć jednoznaczny identyfikator. Ponowienie po timeoutcie nie może bez kontroli tworzyć kolejnego logicznego wpisu lub maskować wcześniejszego sukcesu.

Przed wdrożeniem ustal:

1. klucz idempotencji lub mechanizm równoważny opisany w dokumentacji API,
2. sposób sprawdzenia wcześniejszego wyniku po correlation ID,
3. regułę ponawiania tylko błędów przejściowych,
4. unikalność UPI w zakresie organizacji i katalogu,
5. powiązanie odpowiedzi Registry z niezmienną wersją opublikowanego DPP.

Jeżeli dokumentacja API nie definiuje danego mechanizmu, nie należy zakładać jego istnienia. Wtedy bezpiecznym minimum jest zatrzymanie automatycznego ponowienia do czasu ustalenia statusu wcześniejszego żądania.

Środowisko testowe

Komisja udostępnia odrębne środowisko do testowania enrolmentu i rejestracji. Operacje testowe nie wpływają na produkcję, nie są do niej migrowane i mogą zostać usunięte. Przewodnik wskazuje także konieczność użycia innego EU Login niż w środowisku produkcyjnym.

Testy integracji powinny objąć:

• prawidłowy i nieprawidłowy UPI HTTPS
• niezgodny schemat i brak wymaganych pól
• nieprawidłową granularność
• zduplikowany identyfikator
• brak dostępności semantycznej walidacji
• timeout po wysłaniu i bezpieczne ustalenie statusu
• zapis identyfikatora rejestracyjnego i pełnego śladu audytowego

Czego nie deklarować przed integracją?

DPP Compliance nie powinno komunikować „integracji z EU Registry” na podstawie samego eksportu JSON lub znajomości rozporządzenia. Funkcja jest wdrożona dopiero wtedy, gdy adapter działa na aktualnym kontrakcie Komisji, obsługuje uwierzytelnienie, walidację, statusy i błędy oraz przeszedł testy w udostępnionym środowisku.

Na obecnym etapie ta strona opisuje wymagania i architekturę przygotowania integracji, a nie potwierdza dostępności automatycznej rejestracji w produkcie DPP Compliance.