Element ma API: rekrutacja podłączona do twoich systemów

28 maja 2026

Wprowadzenie

Element ma od dziś publiczne API w wersji v1-beta. To znaczy, że dział IT klienta albo jego integrator może połączyć nasz system rekrutacyjny z własnymi narzędziami: formularzem na stronie kariery, wewnętrznym dashboardem HR, hurtownią danych czy platformą do automatyzacji. Kandydat dodany w jednym miejscu pojawia się w drugim, a zmiana etapu w Element trafia tam, gdzie klient jej potrzebuje, bez ręcznego przepisywania. Pod tym interfejsem siedzi około 10 000 linii kodu, które powstały w sześć tygodni mojej pracy z modelem językowym. Jak zwykle zaznaczam, że nie jestem programistą.

To kolejny rozdział po mobilnych widokach Elementu, które wypuściłem zaledwie kilka dni wcześniej. Cała seria zaczęła się we wrześniu 2025 od tezy, którą powtarzam klientom na warsztatach: osoba bez wykształcenia inżynierskiego potrafi dowieźć poważną funkcję razem z AI, o ile trzyma się dyscypliny i ma kogoś, kto patrzy jej na ręce. Tym razem testem było API, czyli najbardziej techniczny element całego systemu.

Co API realnie daje klientom systemu rekrutacyjnego

API to zestaw drzwi, przez które inne programy rozmawiają z Elementem bez udziału człowieka klikającego w panelu. Do tej pory dane rekrutacyjne żyły głównie wewnątrz naszego systemu, a każda wymiana z innym narzędziem oznaczała eksport, import albo prośbę do nas o zbudowanie konkretnego połączenia. Publiczne API odwraca tę zależność, bo to klient decyduje, co i z czym łączy, i robi to w swoim tempie.

W praktyce otwiera to kilka scenariuszy, na które rekruterzy czekali najdłużej. Formularz aplikacyjny na firmowej stronie kariery może automatycznie tworzyć kandydata w Element, bez kopiowania danych z maila. Zmiana etapu w procesie może aktualizować wewnętrzny raport zarządu albo dashboard w narzędziu BI, z którego korzysta dział HR. Rekrutacje i ich statusy da się podłączyć do platform automatyzacji typu no-code, więc nawet zespół bez programistów ułoży własny przepływ. Każdy z tych scenariuszy wcześniej wymagał pracy po naszej stronie, a teraz jest po stronie klienta i jego integratora.

Wersja v1-beta wystawia 12 endpointów, czyli pojedynczych adresów do konkretnych operacji: pobierania i tworzenia kandydatów, listowania rekrutacji i ich etapów oraz odczytu statusów. Świadomie zaczęliśmy od rdzenia, który pokrywa najczęstsze potrzeby integracyjne, zamiast od dnia pierwszego odwzorowywać cały panel. Dla zespołu klienta, który zarządza danymi w naszym ATS, najważniejsza jest właśnie ta przewidywalność: stabilny, udokumentowany zestaw operacji, na którym można budować integracje z Elementem.

10 000 linii kodu w sześć tygodni i 21 pull requestów

Projekt zamknął się w sześciu tygodniach, około 10 000 liniach kodu i 104 commitach, czyli zapisanych po kolei porcjach zmian. Zgłosiłem 21 pull requestów, czyli paczek zmian oddawanych do wspólnego repozytorium, z których 17 trafiło do systemu, a 4 świadomie zamknąłem, gdy zawęziłem zakres projektu. Kod jest na produkcji w trybie beta, a to oznacza, że celowo zaprosiłem do niego pierwszych użytkowników, zanim uznam go za w pełni dojrzały.

Co poszło nie tak i czego mnie to nauczyło

Najwięcej wartości w tym projekcie jest nie w tym, co od razu zadziałało, tylko w trzech momentach, w których musiałem się cofnąć:

Kto właściwie wykonuje akcję?

Na starcie zaprojektowałem dostęp do API wokół abstrakcyjnego klucza integracji. Wydawało mi się to naturalne, bo z systemem rozmawia program, a nie konkretny człowiek. Reviewer z zespołu deweloperów pokazał mi lukę: każda operacja przez API i tak musi być przypisana do realnego użytkownika z realnymi uprawnieniami, bo inaczej tracimy ślad audytowy i nie wiadomo, kto i w czyim imieniu zmienił dane kandydata. Po trzech tygodniach przebudowałem fundament tak, żeby za każdą akcją stał konkretny użytkownik. Byłem przekonany do pierwszego pomysłu, ktoś z większym doświadczeniem pokazał mi, gdzie się mylę, i to była najlepsza godzina rozmowy w całym projekcie.

Wycięliśmy dwa endpointy, zamiast dowozić wszystko

Mniej więcej w połowie projektu wyciąłem z planu dwa endpointy, które miały obsługiwać w pełni konfigurowalne formularze aplikacyjne i odpowiedzi w nich. Wyglądały dobrze na liście funkcji, ale w wersji v1-beta dokładały złożoności bez proporcjonalnej korzyści dla pierwszych integracji. Zamknięcie tych czterech pull requestów było decyzją, nie porażką. Lepiej oddać spójny rdzeń, na którym klienci faktycznie zbudują połączenia, niż domknąć każdą pozycję z pierwotnej listy i wystawić interfejs, którego nikt nie ogarnia.

Automatyzacja nie zastępuje przeglądu kodu

Pod koniec projektu czekało na połączenie kilka wersji kodu, które powstawały obok siebie. Użyłem narzędzia, które miało automatycznie poskładać je w jedną spójną całość. Zadziałało, ale przy okazji po cichu skasowało kilka moich wcześniejszych poprawek i powieliło inny fragment. To trochę tak, jakby program do scalania kilku wersji dokumentu sam wyciął dwa akapity i skopiował trzeci, nie pytając nikogo o zdanie, a na końcu pokazał plik jako gotowy. Na tym polega problem: nic nie zgłosiło błędu, bo z zewnątrz wszystko wyglądało na skończone. Zauważył to dopiero człowiek, który usiadł i przejrzał wynik linijka po linijce. To najlepsza ilustracja granicy, o której mówię na każdym szkoleniu: AI i automatyzacja świetnie przyspieszają pracę, ale nie biorą odpowiedzialności za to, czy efekt jest poprawny. Ktoś przytomny musi spojrzeć na wynik.

Do tego doszedł drobiazg, który wykryty został w beta testach. W dniu uruchomienia szybki test złapał niespójność w tym, jak API zwraca komunikat o błędnym żądaniu. Poprawiłem to tego samego dnia. Beta z prawdziwymi integracjami znajduje prawdziwe usterki szybciej niż jakikolwiek plan testów przy biurku, i właśnie dlatego wypuszczam ją wcześnie, a nie chowam kod do szuflady aż do ideału.

Co z tego wynika dla zespołów bez własnego działu IT

Granica między pomysłem a wdrożeniem przesuwa się szybciej, niż wiele firm zdążyło zauważyć. API jeszcze niedawno było terytorium wyłącznie inżynierów, a dziś osoba zarządzająca produktem potrafi je dowieźć, jeśli pracuje z modelem językowym świadomie i odda kod do przeglądu senior deweloperem (dziękuję Wam!).

Co to znaczy pracuje z modelem świadomie? Z mojej perspektywy oznacza to działanie w małych krokach, z gotowością do cofnięcia złej decyzji architektonicznej, zaczynając od planu, kończąc na implementacjach i pełnym pokryciu testami automatycznymi i manualnymi.

Najczęstsze pytania

Czym jest API Elementu i do czego służy?

To publiczny interfejs, przez który inne programy łączą się z systemem ATS i wymieniają z nim dane bez ręcznego klikania w panelu. Służy do integracji: automatycznego tworzenia kandydatów, odczytu rekrutacji i ich etapów oraz przekazywania statusów do innych narzędzi klienta.

Czy do skorzystania z API trzeba być programistą?

Po stronie wdrożenia tak, integrację złoży dział IT klienta albo zewnętrzny integrator. Część prostszych scenariuszy da się jednak zbudować w platformach automatyzacji no-code, bez pisania kodu od zera.

Czy API jest już stabilne?

Działa na produkcji w wersji v1-beta. Rdzeń jest gotowy i udokumentowany, ale celowo nazywam go betą, bo pierwsze realne integracje wciąż dają mi sygnały, które dopinają szczegóły.

Czy AI naprawdę napisało kod API?

Kod wygenerował model językowy pod moim kierunkiem i pod przeglądem zespołu deweloperów. Moją rolą było prowadzenie projektu, decyzje architektoniczne i wyłapywanie błędów, a nie ręczne pisanie linijek.

Jeśli zarządzasz rekrutacją i masz w głowie integrację, której do tej pory nie dało się ułożyć, to jest dobry moment, żeby wrócić do tego pomysłu. A jeśli ciekawi cię, jak takie funkcje powstają bez etatowego zespołu inżynierów, zajrzyj do wcześniejszych wpisów z serii o vibe codingu.

Najczęściej czytane:

  1. Darmowe ogłoszenia o pracę i największa lista źródeł kandydatów – największa w Polsce lista bezpłatnych i płatnych źródeł kandydatów
  2. Praca w HR – najnowsze oferty pracy i aktualne średnie wynagrodzenia w branży HR
  3. Akademia Rekrutacji – zbiór wiedzy na temat rekrutacji oraz raporty z rynku pracy.
  4. Gowork – jak reagować na negatywne opinie o pracodawcach – Kompleksowy poradnik dla pracodawców.
  5. Jak napisać CV i profil LinkedIn – kompleksowy poradnik tworzenia CV i profilów LinkedIn
  6. RODO w rekrutacji – sourcing, direct search, ogłoszenia. Wszystko co musisz wiedzieć – kompleksowy poradnik RODO w rekrutacji z naciskiem na działania typu direct search / sourcing.
  7. Wszystko o systemach ATS – poradnik wyboru systemu rekrutacyjnego
  8. Umowy przedwstępne i listy intencyjne w procesach rekrutacyjnych – wszystko, co musisz wiedzieć o prawnych zabezpieczeniach zobowiązania do zatrudnienia.
Picture of Maciej Michalewski

Maciej Michalewski

Founder & CEO @ Element

Element cennik baner

Nasze artykuły przeczytasz także na Medium, LinkedIn, Substack, Reddit

Ostatnie wpisy: