Niezależny od rejestratora silnik pod spodem
W naszej logice biznesowej nie występuje żaden SDK rejestratora. Każdy rejestrator znajduje się za interfejsem adaptera i jest wybierany na podstawie możliwości, a nie nazwy, co oznacza, że platforma może dodać rejestrator, wymienić go lub skierować TLD do innego bez dotykania procesu składania zamówienia, edytora DNS czy zapisanych ustawień. Jeśli masz już własne konto rejestratora, jego poświadczenia są pobierane z Vault dla każdej organizacji, a domena jest rejestrowana na Twoim koncie zamiast na naszym.
Rejestracja, transfer, odnowienie i przywrócenie działają jako trwała infrastruktura Temporal workflows zamiast długich zapytań HTTP. Każdy krok to idempotentna aktywność wyposażona w klucz idempotencji, a błędy kompensują się wstecz – rejestracja, która nie powiedzie się po ustawieniu serwerów nazw, cofa te zmiany, zamiast pozostawiać niedokończoną domenę. Płatność jest pobierana w ramach zamówienia przed rozpoczęciem realizacji, więc awaria u rejestratora oznacza czysty zwrot środków zamiast sporów.
Mieszane koszyki ulegają awarii niezależnie. Jeśli kupujesz hosting i domenę razem, a rejestracja domeny zostanie odrzucona – podbita w wyścigu, odrzucona przez rejestr, awaria rejestratora – pozycja hostingu nadal zostaje zrealizowana, a pozycja domeny jest zwracana do Twojego portfela osobno. Jedna nieudana pozycja nigdy nie wstrzymuje reszty Twojego zamówienia.
Wszystko na tej stronie jest oparte na architekturze API. Wyszukiwanie domen, rejestracja, transfery, rekordy DNS i serwery nazw to opublikowane punkty końcowe w naszej specyfikacji OpenAPI, co oznacza, że są one w równym stopniu dostępne z poziomu panelu sterowania, wygenerowanych pakietów SDK, interfejsu wiersza poleceń oraz naszego serwera MCP — dzięki temu narzędzie AI może zarządzać Twoim DNS-em dokładnie z takimi uprawnieniami, jakie mu przyznałeś.