Krajowy Rejestr Długów | Portal Informacyjny

Dlaczego powstało nasze API?

Protokoły wymiany danych powstały w odpowiedzi na potrzeby naszych Klientów m.in.: banków, firm pożyczkowych, leasingodawców, telekomów czy towarzystw ubezpieczeniowych. Za pośrednictwem naszych usług web (tzw. WebService-ów) udostępniamy wszystkie wiodące usługi Krajowego Rejestru Długów BIG S.A. – dzięki temu pomogliśmy zautomatyzować obsługę zleceń w kilkuset firmach. Nasze API jest stale rozwijane przez kilkudziesięciu programistów i dostosowywane do potrzeb naszych partnerów.

Jakie korzyści płyną z wdrożenia protokołów KRD API?

Wykorzystanie protokołów wymiany danych automatyzuje proces oceny ryzyka i pozwala dokładnie profilować przyszłych i obecnych Klientów. Jednocześnie usługi web KRD to narzędzia, które pozwolą Ci wytworzyć skuteczne mechanizmy odzyskiwania należności, tym samym zwiększając ROI Twojego wdrożenia.

KRD API – Opis techniczny protokołów

KRD API umożliwia kompleksową integrację z systemem informatycznym KRD. Integracja możliwa jest poprzez protokoły:

Chase – sprawdzanie firm (po NIP-ie) i konsumentów (po PESEL-u),
Nicci – sprawdzanie firm i konsumentów, zarządzanie informacjami gospodarczymi, zarządzanie monitoringami oraz inne operacje,
Rastin – sprawdzenie w rejestrze PESEL i Rejestrze Dowodów Osobistych (RDO) Ministerstwa Cyfryzacji poprawności danych przesłanych w zapytaniu,
API Solvig – sprawdzanie wyniku analizy wiarygodności płatniczej podmiotu niebędącego konsumentem w KRD (po NIP-ie) – Scoring KRD oraz opcjonalnie (oprócz scoringu) sprawdzanie maksymalnej kwoty, do jakiej rekomendowana jest sprzedaż usług lub towarów z odroczonym terminem płatności konkretnemu kontrahentowi – Limit Kupiecki KRD,
API Amnell – sprawdzanie aktualnego na moment zapytania statusu zastrzeżenia PESEL w Rejestrze Zastrzeżeń Numerów PESEL Ministerstwa Cyfryzacji,
API Wexler – sprawdzanie firm (po NIP-ie) w Bazie Sprawozdań Finansowych KRS.

Protokoły KRD API realizowane są za pośrednictwem osobnych WebService’ów; technologicznie różnią się w następujących obszarach:

Protokół Chase:
- udostępniany jest poprzez WebService Chase,
- wymaga wytworzenia przez programistów Klienta zintegrowanej aplikacji,
- jest synchroniczny – wynik jest natychmiastowo zwracany przez wywołaną metodę interfejsu usługi,
- umożliwia uwierzytelnienie dedykowanym certyfikatem klienckim zabezpieczonym dodatkowym hasłem,
- umożliwia także uwierzytelnienie za pomocą loginu i hasła użytkownika systemu KRD.
Protokół Nicci:
- udostępniany poprzez WebService Siddin,
- wymaga uwierzytelnienia za pomocą loginu i hasła użytkownika systemu KRD,
- przyjmuje żądania w formacie XML o ustalonym schemacie XSD mogące zawierać zlecenia wykonania wielu operacji w systemie – są to tzw. transze,
- jest asynchroniczny: przekazane transze trafiają do kolejki FIFO; każda transza ma swój status przetworzenia – użytkownik może sprawdzać, czy jego transza została już przetworzona, jeśli tak, może pobrać wyniki w postaci tzw. transzy wynikowej (również w postaci XML),
- umożliwia zarówno pełną integrację programistyczną z istniejącym systemem Klienta, jak i wysyłkę przygotowanych transz Nicci przy użyciu istniejącej aplikacji klienckiej Sabar (dowiedz się więcej o programie Sabar).
Protokół Rastin:
- udostępniany jest poprzez WebService Rastin,
- wymaga wytworzenia przez programistów Klienta zintegrowanej aplikacji,
- jest synchroniczny – wynik jest natychmiastowo zwracany przez wywołaną metodę interfejsu usługi,
- umożliwia uwierzytelnienie dedykowanym certyfikatem klienckim zabezpieczonym dodatkowym hasłem,
- umożliwia także uwierzytelnienie za pomocą loginu i hasła użytkownika systemu KRD.
API Solvig:
- udostępniane jest poprzez WebService Solvig,
- wymaga wytworzenia przez programistów Klienta zintegrowanej aplikacji,
- jest synchroniczne – wynik jest natychmiastowo zwracany przez wywołaną metodę interfejsu, ale umożliwia także odpytania asynchroniczne: przekazane transze trafiają do kolejki FIFO; każda transza ma swój status przetworzenia – użytkownik może sprawdzać, czy jego transza została już przetworzona, jeśli tak, może pobrać wyniki w postaci tzw. transzy wynikowej (w formacie JSON),
- dostęp do API wymaga autoryzacji przez Reference Token i odpowiednich uprawnień do produktu Scoring KRD i Limit Kupiecki KRD,
- metoda token pozwala na uzyskanie tokena, który jest wymagany do autoryzacji dostępu do naszych usług.
API Amnell:
- udostępniane jest poprzez WebService Amnell,
- wymaga wytworzenia przez programistów Klienta zintegrowanej aplikacji,
- jest asynchroniczne: przekazane transze trafiają do kolejki FIFO; każda transza ma swój status przetworzenia – użytkownik może sprawdzać, czy jego transza została już przetworzona, jeśli tak, może pobrać wyniki w postaci tzw. transzy wynikowej (w formacie JSON),
- dostęp do API wymaga autoryzacji przez Reference Token i odpowiednich uprawnień,
- metoda token pozwala na uzyskanie tokena, który jest wymagany do autoryzacji dostępu do naszych usług.
API Wexler:
- udostępniane jest poprzez WebService Wexler,
- wymaga wytworzenia przez programistów Klienta zintegrowanej aplikacji,
- dostępne jest w dwóch wersjach:
  - Pojedynczej (synchroniczna) – system KRD umożliwia wysłanie pojedynczego zapytania o sprawozdania finansowe za pomocą API, poprzez podanie konkretnego, pojedynczego numeru NIP oraz opcjonalnie informacji, czy zapytanie ma dotyczyć wszystkich dostępnych sprawozdań, czy tylko ostatniego (domyślnie zwracane są wszystkie sprawozdania),
  - Masowej (asynchroniczna) – system KRD umożliwia wysłanie masowego zapytania o sprawozdania finansowe za pomocą API, poprzez podanie wielu wybranych numerów NIP oraz opcjonalnie informacji, czy zapytanie ma dotyczyć wszystkich dostępnych sprawozdań, czy tylko ostatniego (domyślnie zwracane są wszystkie sprawozdania),
- dostęp do API wymaga autoryzacji przez Reference Token i odpowiednich uprawnień,
- metoda token pozwala na uzyskanie tokena, który jest wymagany do autoryzacji dostępu do naszych usług.