Kupiłem API do zdjęć stockowych. Miesiąc później wciąż czekam na odpowiedź supportu

Wpisałem numer karty, kliknąłem „kup subskrypcję" i poczułem tę przyjemną iskrę, którą zna każdy, kto lubi automatyzować. Za chwilę mój blog miał sam dobierać sobie zdjęcia. Koniec z grzebaniem w bibliotekach stocka, koniec z „a może to, nie, za bardzo korporacyjne". Algorytm bierze tytuł artykułu, odpytuje API, ściąga najlepsze ujęcie i wstawia. Pięknie.

Trzy dni później siedziałem przed terminalem, patrzyłem na kod, który technicznie działał idealnie, i przyjmowałem do wiadomości, że właśnie zapłaciłem za coś, co nie robi tej jednej rzeczy, dla której to kupiłem. API odpowiadało. Zwracało dane. Tylko nie zdjęcia. Napisałem do supportu. Dziś, miesiąc później, wciąż na tę odpowiedź czekam. Tę historię chcę ci opowiedzieć nie po to, żeby ponarzekać na 123RF - to akurat przyjemny dodatek - tylko dlatego, że jest w niej lekcja, która kosztuje firmy znacznie więcej niż mnie kosztowała subskrypcja. Prowadzę agencję AI dla małych i średnich firm i właśnie na tym polega moja praca: testować to na sobie, zanim polecę komuś. Tym razem sparzyłem się ja.

Spis treści

• Po co w ogóle automatyzować dobór zdjęć?
• Co właściwie kupiłem i czego się spodziewałem?
• Gdzie to pękło? Bo „jest API" to nie to samo co „API robi, co trzeba"
• Dlaczego support milczy i co to mówi o całej usłudze?
• Jak sprawdzić API ZANIM zapłacisz?
• Kiedy ręcznie bije automat?
• Czego mnie ta wtopa naprawdę nauczyła
• Słownik pojęć

Po co w ogóle automatyzować dobór zdjęć?

Piszę na bloga regularnie i każdy artykuł potrzebuje grafiki. Obrazka głównego, czasem dwóch ilustracji w środku. Wydaje się to drobiazgiem, ale spróbuj policzyć. Wejść do biblioteki stocka, wpisać frazę, przejrzeć dwie strony wyników, odrzucić te z ludźmi w garniturach przybijającymi piątkę, znaleźć coś, co nie wygląda jak reklama z 2012 roku, pobrać, przyciąć do proporcji, opisać alt. Dziesięć minut. Czasem dwadzieścia, gdy temat jest trudny do zobrazowania.

Przy jednym artykule to nic. Przy dwóch tekstach tygodniowo, miesiąc po miesiącu, to kilka godzin rocznie wydanych na klikanie w miniaturki. A ja mam zasadę, którą opisywałem już w tekście o pięciu narzędziach AI, których używam codziennie: jeśli robię coś powtarzalnie i nudno, to jest kandydat do automatyzacji. Dobór zdjęć pasował idealnie. Powtarzalne, schematyczne, pożerające czas, a wynik i tak prawie zawsze „wystarczająco dobry". Wymarzony fragment do oddania maszynie.

Pomysł był prosty. Mam już skrypt, który zna tytuł i temat każdego nowego artykułu. Niech sam wyciągnie z tego dwa - trzy słowa kluczowe, odpyta o nie bibliotekę zdjęć, pobierze najlepiej pasujące ujęcie i przygotuje mi je do wstawienia. Ja tylko rzucam okiem i akceptuję. Z dwudziestu minut robi się trzydzieść sekund. Klasyczne, zdrowe wdrożenie - takie, jakie sam polecam klientom.

Co właściwie kupiłem i czego się spodziewałem?

Padło na 123RF. Duży bank zdjęć, miliony plików, rozsądny cennik, no i - co najważniejsze - na stronie wyraźnie napisane: API. Dla mnie to był zielony przycisk. „Ma API" oznaczało w mojej głowie: mogę programowo wyszukać zdjęcie i programowo je pobrać. Tak działa większość API, do których jestem przyzwyczajony. Pytasz, dostajesz, używasz.

Wykupiłem dostęp, dostałem klucz API, przeczytałem dokumentację. Wyglądała sensownie. Był endpoint do wyszukiwania - podajesz frazę, dostajesz listę pasujących obrazów wraz z ich identyfikatorami, tytułami, miniaturkami. Był też cały zestaw pól w odpowiedzi. Usiadłem, napisałem integrację w jakieś dwie godziny. Pierwsze odpytanie poszło gładko. Wpisałem „automatyzacja firma", dostałem ładną listę kilkudziesięciu wyników. Pomyślałem: to było łatwe. To zawsze powinno zapalić lampkę.

Bo łatwa była część, którą API faktycznie potrafiło - wyszukiwanie. A całe wyszukiwanie jest mi do niczego, jeśli na końcu nie ma realnego pliku, który mogę wstawić do artykułu. I tu zaczęła się prawdziwa historia.

Gdzie to pękło? Bo „jest API" to nie to samo co „API robi, co trzeba"

Search API zwracało wszystko poza tą jedną rzeczą, której potrzebowałem: pełnego, gotowego do użycia zdjęcia. Dostawałem metadane - identyfikator, tytuł, rozmiary, kategorię. Dostawałem URL do podglądu. I tu cię zaskoczę, choć w sumie nie powinno: ten podgląd to miniaturka ze znakiem wodnym, wielkim napisem „123RF" przez środek. Próba pobrania większej wersji przez ten sam adres? Serwer odpowiadał `403 Forbidden`. Hotlinkowanie zablokowane, czyli nie wolno wyświetlić tego obrazka spoza ich własnej strony.

Usiadłem i przeczytałem dokumentację jeszcze raz, wolniej, szukając metody, której nie zauważyłem. Endpoint typu „pobierz plik", „download", „get full image", cokolwiek, co oddaje czysty obraz w zamian za identyfikator. Nie było. Search API, które kupiłem w pakiecie, służy do przeszukiwania katalogu i pokazywania znakowanych podglądów - na przykład po to, żeby zbudować własną wyszukiwarkę, która i tak odsyła użytkownika do 123RF po zakup. Realne pobranie odbywa się gdzie indziej, w innym trybie, prawdopodobnie przez osobny mechanizm licencjonowania, do którego mój pakiet nie dawał wejścia.

Krótko mówiąc: zbudowałem automat, który potrafił znaleźć idealne zdjęcie i pokazać mi je przekreślone wodnym napisem, że to nie moje. Jak kelner, który recytuje całe menu, opisuje smaki, podsuwa kartę pod nos, a potem oznajmia, że kuchnia akurat nieczynna. Technicznie wszystko zadziałało. Praktycznie - zero wartości. To jest dokładnie ta pułapka, którą chcę, żebyś zapamiętał: „usługa ma API" mówi ci, że istnieją jakieś drzwi. Nie mówi, że prowadzą do pokoju, do którego chcesz wejść.

Najgorsze, że to nie był błąd. Nic się nie zepsuło. API działało dokładnie tak, jak zaprojektowano - tylko zaprojektowano je do czegoś innego, niż ja założyłem. A założyłem, bo widziałem słowo „API" i dopowiedziałem sobie resztę. Szczerze? Miałem dość samego siebie bardziej niż 123RF.

Dlaczego support milczy i co to mówi o całej usłudze?

Napisałem grzecznego maila. Opisałem, czego potrzebuję, pokazałem, że Search API zwraca tylko znakowane podglądy, zapytałem wprost: czy istnieje endpoint do pobierania pełnych plików dla mojego typu subskrypcji, a jeśli tak, jak go aktywować. Konkretne pytanie, konkretny problem, płacący klient.

Dostałem automatyczne potwierdzenie z numerem zgłoszenia. I cisza. Tydzień, drugi. Ponowiłem. Cisza. Miesiąc minął i nic - poza tym samym automatem, który zapewnia, że moja sprawa jest dla nich ważna. Nie mam o to nawet specjalnej pretensji emocjonalnej, bo dawno przestałem oczekiwać cudów od supportu dużych platform. Ale wyciągnąłem z tego wniosek, który jest ważniejszy niż samo zdjęcie na blogu.

Cisza supportu to też informacja o produkcie. Jeśli przy etapie, na którym jeszcze chcę im dać pieniądze i potrzebuję tylko jednej odpowiedzi technicznej, nie potrafią się odezwać przez miesiąc - to jak będzie wyglądało wsparcie, gdy zbuduję na ich API coś, od czego zależy mój proces, a ono pewnego dnia przestanie działać? Pisałem o tym przy okazji prawdziwych kosztów AI w firmie - najdroższe nigdy nie jest to, co widać w cenniku. Najdroższy jest dzień, w którym coś, na czym oparłeś firmę, milczy, a po drugiej stronie nie ma nikogo, kto odbierze. Subskrypcję, którą kupiłem, da się odpisać w straty bez bólu. Proces produkcyjny oparty na takim dostawcy - już nie.

Jak sprawdzić API ZANIM zapłacisz?

Gdybym cofnął te trzy godziny i dwie pomyłki, zrobiłbym to inaczej. Wyciągam z tej wtopy listę, której teraz trzymam się sam i którą daję klientom, zanim oprą cokolwiek na cudzym interfejsie.

Najpierw napisz dokładnie jedno zdanie, co API ma dla ciebie zrobić. Nie „mam dostęp do zdjęć", tylko „dostanę plik JPG w pełnej rozdzielczości, bez znaku wodnego, na podstawie identyfikatora". Im konkretniej, tym szybciej zobaczysz, czy dokumentacja faktycznie to obiecuje, czy ty sobie to dopowiedziałeś.

Potem przeczytaj dokumentację, szukając tej konkretnej operacji, a nie ogólnego potwierdzenia, że API istnieje. Znajdź endpoint, który robi twoją jedną rzecz. Sprawdź, co dokładnie zwraca - nie „obraz", tylko czy to plik, czy URL, czy znakowany podgląd, jaki format, jakie ograniczenia. Diabeł siedzi w polu odpowiedzi, nie w nagłówku rozdziału.

Zanim wpiszesz numer karty, przetestuj na darmowym poziomie albo na kluczu próbnym. Większość poważnych dostawców daje sandbox albo limit testowy właśnie po to. Jeśli nie daje - to też informacja. Zrób jedno realne odpytanie i fizycznie zobacz wynik na ekranie. Nie czytaj, że „zwraca obraz". Pobierz ten obraz i otwórz go. Gdybym zrobił to przed zakupem, zobaczyłbym wodny znak w trzy minuty, a nie po opłaceniu subskrypcji.

Sprawdź rate limit i warunki użycia, zanim zbudujesz cokolwiek poważnego. Ile zapytań na minutę, czy wolno cache'ować, czy wolno wyświetlać pliki na własnej stronie. To rzeczy, które wyłażą boleśnie dopiero pod obciążeniem, gdy już jesteś uzależniony.

I ostatnie, najważniejsze: wyślij supportowi jedno pytanie testowe jeszcze przed zakupem. Nawet błahe. Czas i jakość odpowiedzi powiedzą ci o tej firmie więcej niż cała strona z funkcjami. Gdybym napisał do 123RF przed opłaceniem, a nie po, dostałbym swoją odpowiedź - tę samą ciszę - za darmo i z zachowanym budżetem.

Kiedy ręcznie bije automat?

Tu przychodzi część, którą lubię najmniej, bo uderza w moją branżową dumę. Po tygodniu walki usiadłem, zrobiłem rachunek i przyznałem coś, czego automatyzatorowi trudno powiedzieć na głos: w tym akurat przypadku ręczne robienie tego było tańsze niż automat. Wróciłem do klikania w miniaturki.

Policz ze mną na chłodno. Ręczny dobór zdjęcia to u mnie jakieś dziesięć minut na artykuł. Przy moim tempie publikacji to kilka godzin rocznie. Nieprzyjemnych, nudnych, ale godzin tanich. Zbudowanie i utrzymanie automatu, który działa - znalezienie dostawcy z właściwym API, integracja, obsługa licencji, pilnowanie, czy nic się nie zmieniło po ich stronie - to dni pracy plus stała zależność od kogoś, kto, jak właśnie zobaczyłem, potrafi milczeć miesiąc. Automatyzacja na siłę bywa droższa i bardziej kłopotliwa niż problem, który miała rozwiązać.

Nie mówię, że tej automatyzacji nie da się zrobić dobrze. Da się - z dostawcą, który ma realny endpoint pobierania i licencję do publikacji, albo z modelem generującym grafikę pod artykuł. Pewnie do tego wrócę. Mówię coś innego, ważniejszego: automatyzacja, która kosztuje więcej niż ręczna robota, którą zastępuje, to nie postęp, tylko zabawka. A granica między jednym a drugim biegnie dokładnie tam, gdzie powtarzalność i wolumen spotykają się z kosztem błędu. Przy dwóch artykułach tygodniowo i grafice, która i tak musi mi się spodobać, ta granica jeszcze nie została przekroczona. Przy stu artykułach miesięcznie odpowiedź byłaby inna.

Najtrudniejsza dyscyplina w mojej pracy to nie zbudować automat. To umieć przyznać, kiedy go nie budować.

Czego mnie ta wtopa naprawdę nauczyła

Zostały mi z tego trzy rzeczy, które trzymam teraz bliżej niż wcześniej.

Po pierwsze, każda zależność od cudzego API to cichy współudziałowiec w twoim procesie - taki, którego nie kontrolujesz. Może zmienić zasady, podnieść cenę, zamknąć endpoint albo po prostu przestać odpowiadać. Im ważniejszy fragment firmy na nim opierasz, tym poważniej trzeba podejść do pytania „a co, jeśli on jutro zniknie". Przy zdjęciach na blogu odpowiedź brzmi „nic, kliknę ręcznie". Przy fakturowaniu albo obsłudze klienta brzmiałaby zupełnie inaczej i wtedy lekka decyzja staje się decyzją strategiczną.

Po drugie, słowo „API" jest dziś takim samym znaczkiem na pudełku jak „eko" czy „smart". Mówi, że coś jest, nie mówi, że to coś robi, czego potrzebujesz. Sprawdzaj operację, nie etykietę.

Po trzecie - i to wynoszę najdalej - czasem najmądrzejszą automatyzacją jest ta, której świadomie nie zrobiłeś. Straciłem trzy godziny i koszt jednej subskrypcji, którą i tak wykorzystam inaczej. Tanio jak na lekcję, którą teraz oddaję klientom za darmo, zanim sami wpiszą numer karty pod słowem, które brzmiało jak rozwiązanie.

Support 123RF, gdy w końcu odpisze, pewnie wskaże mi właściwą furtkę. Ale do tego czasu zdjęcia do tego artykułu wybrałem ręcznie. W dziesięć minut. I szczerze - było szybciej.

Słownik pojęć

• API - „drzwi służbowe" programu, przez które inne aplikacje mogą z nim rozmawiać bez klikania w ekran. Pozwala jednemu narzędziu poprosić drugie o dane albo o wykonanie czynności. Sama obecność API nie mówi jednak, jakie dokładnie operacje są dostępne - to zależy od tego, co dostawca w nim udostępnił.
• Hotlinking - wyświetlanie pliku (np. zdjęcia) bezpośrednio z cudzego serwera na własnej stronie, bez pobierania go do siebie. Banki zdjęć często to blokują, oddając zamiast pliku błąd `403 Forbidden`, żeby chronić swoje obrazy przed darmowym użyciem.
• Rate limit - górny limit zapytań, jakie wolno wysłać do API w danym czasie (np. 100 na minutę). Po jego przekroczeniu serwer przestaje odpowiadać na chwilę. Trzeba go znać, zanim zbudujesz coś, co odpytuje API intensywnie.
• Stock / bank zdjęć - serwis sprzedający licencje na gotowe zdjęcia, grafiki i wideo (np. 123RF, Shutterstock). Płacisz za prawo użycia pliku, nie za sam plik - dlatego pobieranie i licencjonowanie bywa oddzielone od zwykłego przeglądania katalogu.

Więcej o tym, jak wygląda współpraca ze mną - od pierwszej rozmowy po wdrożenie.