Kredyty i cache

DeliverIQ rozlicza walidację w kredytach. Koszt zależy od wybranego trybu oraz od tego, ile pracy system faktycznie wykonał.

• Walidacja Szybka: 1 kredyt za sprawdzony adres.
• Walidacja Dokładna z wykonaną próbą SMTP albo pełnym wynikiem z cache: 3 kredyty.
• Walidacja Dokładna zakończona wartościowym wynikiem lokalnym albo DNS bez SMTP: 1 kredyt.
• Walidacja Dokładna zatrzymana przez limiter systemowy, reputację próby walidacyjnej albo problem infrastrukturalny przed użyteczną pracą: 0 kredytów.

Każdy wynik walidacji pokazuje liczbę faktycznie rozliczonych kredytów oraz krótkie wyjaśnienie. Ponowienie tego samego requestu z tym samym kluczem idempotencji nie nalicza kredytów drugi raz.

W walidacji masowej system najpierw rezerwuje maksymalny koszt zadania. Dzięki temu zadanie może działać w tle bez ryzyka, że zabraknie kredytów w połowie przetwarzania.

• Dostępne kredyty: środki, które możesz od razu wykorzystać na kolejne walidacje.
• Zarezerwowane kredyty: część salda czasowo odłożona na trwające zadanie walidacji masowej.
• Faktycznie zużyte kredyty: suma kosztów terminalnych wyników po zakończeniu zadania.

Po zakończeniu walidacji masowej następuje rozliczenie: system pobiera rzeczywisty koszt wynikający z rekordów, a niewykorzystaną część rezerwacji zwalnia z powrotem do dostępnego salda. W pliku wynikowym każdy rekord zawiera credits_spent oraz credits_explanation.

Cache pozwala szybciej zwrócić niedawno ustalony wynik i ograniczyć powtarzanie pracy sieciowej, szczególnie dla adresów sprawdzanych ponownie w tym samym trybie walidacji. Light i Deep mają osobne wpisy cache.

Cache hit nie oznacza bezpłatnej walidacji. Jeżeli wykonujesz nowe płatne sprawdzenie, odpowiedź z cache jest rozliczana według aktualnej polityki produktu dla danego trybu. Wyjątkiem jest techniczne ponowienie tego samego requestu z tym samym kluczem idempotencji, które odtwarza wynik bez drugiego obciążenia.

Do cache trafiają tylko deterministyczne statusy: valid, invalid i risky. System wymaga też poprawnego, kompletnego payloadu zgodnego z aktualnym modelem odpowiedzi.

Do cache nie trafiają pozostałe wyniki, w szczególności temporary_failure, unknown, blocked i no_mx, ponieważ mogą odzwierciedlać stan przejściowy, ograniczenie bezpieczeństwa albo aktualny stan infrastruktury domeny. Podobnie pomijane są przejściowe powody DNS i SMTP, takie jak timeout, odmowa zapytania, błąd resolvera, blokada reputacyjna albo pominięcie kontroli SMTP.

Dzięki temu kolejna walidacja wyniku przejściowego wykonuje świeże sprawdzenie zamiast odtwarzać stan, który mógł wynikać z chwilowej polityki dostawcy lub awarii zewnętrznej.

Stan adresów i polityki providerów zmieniają się w czasie. Nowa walidacja ma sens szczególnie przed ważną wysyłką, po dłuższej przerwie w kontakcie z listą, po imporcie danych z nowego źródła albo gdy poprzedni wynik był tymczasowy, zablokowany lub nierozstrzygający.

Dla dużych list używaj Walidacji masowej, aby widzieć jednocześnie postęp zadania, zarezerwowane kredyty, faktycznie zużyte kredyty oraz gotowe eksporty wyników.