Konsola deweloperska FOTOhub rozrasta się w pełną warstwę infrastruktury kreatywnej

Konsola API FOTOhub pod adresem fotohub.app/console przestała w ostatnich tygodniach przypominać stronę z ustawieniami. Coraz bardziej wygląda na coś bliższego małemu dostawcy chmury: prawdziwe magazynowanie w AWS S3 z kontrolkami klasy enterprise, routing wyników generacji wprost do własnego bucketu klienta, system webhooków z podpisywanymi dostawami i znacznie rozbudowana dokumentacja, która to wszystko wyjaśnia. Nic z tego nie zastępuje narzędzi generacyjnych, które użytkownicy znają z panelu FOTOhub. To warstwa pod nimi, adresowana do deweloperów, agencji i zespołów produktowych budujących na FOTOhub, a nie tylko klikających w jego interfejs.

Ze strony ustawień do konsoli z dziewięcioma zakładkami

Stara wersja konsoli API to była strona z kluczem i przyciskiem do kopiowania. To, co dziś znajduje się pod /console, jest podzielone na trzy grupy: Developer API, Storage i Compute Resources, każda z własnym zestawem zakładek. Sam Developer API obejmuje panel statystyk, zarządzanie kluczami, dostęp do modeli, limity taryfowe, webhooki, analitykę użycia, historię zadań i logi żądań. Storage ma własną parę zakładek na buckety i miejsca docelowe dostaw. Compute Resources odsłania instancje GPU, katalog sprzętu i monitoring dla tych, kto wynajmuje surową moc obliczeniową, a nie tylko woła endpoint generacji.

Sam panel statystyk zasługuje na wzmiankę z powodu tego, czego nie robi. Czyta z jednego zagregowanego endpointu, który liczy liczbę żądań, percentyle opóźnień, wydatki i rozbicie na poszczególne modele w jednym przebiegu po danych, więc liczby widoczne na ekranie zawsze się zgadzają z sumami stojącymi za nimi. Brakujący pomiar wyświetla się jako pole puste, nie jako zero, bo zero żądań i zero milisekund znaczą zupełnie inne rzeczy, a mylenie ich to sposób, w jaki panele statystyk zaczynają okłamywać ludzi.

Klucze API, które robią więcej niż samo uwierzytelnianie

Klucze tworzone w konsoli mają teraz strukturę, która kiedyś wymagała zgłoszenia do supportu. Każdy klucz ma typ: tylko do odczytu, do zapisu albo administracyjny, opcjonalną listę dozwolonych adresów IP, opcjonalną listę dozwolonych referrerów, własny limit żądań i własne okno przechowywania wyników. Klucz może domyślnie kierować każdą wygenerowaną treść do konkretnego miejsca docelowego, a flaga keepLocalCopy pozwala zespołom, które ufają już swojemu pipeline'owi, zatrzymać obiekt tylko we własnym buckecie bez dodatkowej opłaty za duplikat w magazynie FOTOhub. Rotacja klucza to jedno wywołanie, więc wyciekły klucz da się zastąpić bez regenerowania wszystkich zależnych od niego danych uwierzytelniających po drodze.

Klucze produkcyjne zaczynają się od fh_live_ i dotykają realnego salda kredytów oraz trwałego magazynu. Drugi prefiks, fh_test_, wydaje klucze sandboksowe, które zwracają odpowiedzi testowe i przechowują wynik nie dłużej niż 24 godziny, co jest różnicą między testowaniem integracji na koncie stagingowym a bezpiecznym testowaniem bez konta stagingowego w ogóle.

Prawdziwy AWS S3, nie owijka wokół niego

To jest część, która zmienia znaczenie słowa "storage" w FOTOhub. Kupienie bucketu przez konsolę uruchamia prawdziwy bucket AWS S3 w jednym z szesnastu regionów na czterech kontynentach, razem z dedykowanym użytkownikiem IAM przypisanym wyłącznie do tego bucketu. Nikt po stronie klienta nigdy nie widzi i nie trzyma danych uwierzytelniających AWS, a konsola nigdy o nie nie prosi. Provisioning to krótka wieloetapowa operacja pod maską: bucket, szyfrowanie, blokada publicznego dostępu, użytkownik IAM, więc niepowodzenie w połowie procesu wycofuje wszystkie kroki i zwraca rezerwację środków, zamiast zostawić kogoś właścicielem połowicznie działającego bucketu.

To, co faktycznie uzasadnia nazywanie tego "klasą enterprise", to lista kontrolek podłączonych aż do samego API AWS, nie zatrzymujących się na interfejsie konsoli. Reguły lifecycle przenoszą obiekty między klasami magazynowania i wygaszają je według harmonogramu, ze wsparciem dla czyszczenia starszych wersji obiektów i automatyczną regułą sprzątania po nieudanych przesyłaniach wieloczęściowych. Konfiguracja CORS, polityki bucketu, wersjonowanie, szyfrowanie po stronie serwera z AES256 albo własnym kluczem KMS klienta oraz Object Lock w wersji odwracalnej governance albo nieodwracalnej compliance to realne wywołania na realnych zasobach AWS, weryfikowalne przez odczyt i zapis konfiguracji, a nie przełącznik w ustawieniach, którego nic dalej nie czyta.

Powiadomienia to uczciwy sposób opisania tego, co dzieje się przy uploadzie. Bucket można podłączyć tak, żeby publikował zdarzenia S3 do tematu SNS, kolejki SQS, funkcji Lambda albo EventBridge, filtrowane po prefiksie i sufiksie, w momencie gdy obiekt się pojawia. To, co własna funkcja Lambda klienta zrobi z takim zdarzeniem, zależy wyłącznie od niego, co jest istotnie inną deklaracją niż "platforma automatycznie uruchamia AI na przesłanych plikach", i bardziej użyteczną: oznacza, że bucket może zasilać jakikolwiek pipeline, który klient już ma, a nie tylko ten jeden, który FOTOhub akurat zbudował pierwszy.

Bucket może też mieć publiczny hostname pod etykieta.s3point.fotohub.app, z pojedynczymi folderami opublikowanymi do anonimowego odczytu, podczas gdy reszta tego samego bucketu zostaje prywatna. Publikacja jest właściwością aliasu, nie pojedynczych obiektów, więc wycofanie publicznego dostępu to jedno wywołanie, które działa natychmiast na wszystko pod danym prefiksem, a nie porządki plik po pliku.

Routing wyników: mówienie generacjom, gdzie mają wylądować

Funkcja, która łączy magazyn z API generacji, to miejsca docelowe i reguły wyjścia, i odpowiada na pytanie, które kiedyś wymagało ściągnięcia pliku i wgrania go gdzie indziej. Miejsce docelowe wskazuje na bucket zapewniony przez konsolę albo zewnętrzny: Cloudflare R2, Backblaze B2, MinIO, DigitalOcean Spaces, Wasabi, cokolwiek mówiące protokołem S3, weryfikowane przy tworzeniu prawdziwym zapisem, odczytem i usunięciem. Reguła wyjścia dopasowuje wzorzec identyfikatora modelu do miejsca docelowego i szablonu ścieżki, więc wywołanie wideo do seedance-2-0-mini może wylądować w private/2026/08/{job_id}.mp4 w jednym buckecie, podczas gdy wywołanie obrazu do innego modelu trafia do zupełnie innego folderu albo zupełnie innego dostawcy, bez konieczności wzajemnej wiedzy o istnieniu drugiego żądania.

```bash

curl -X POST "https://apis.fotohub.app/v1/auth/keys/$KEY_ID/output-rules" \

-H "Authorization: Bearer $FH_JWT" \

-H "Content-Type: application/json" \

-d '{

"modelPattern": "seedance-2-0-*",

"destinationId": "c47b8e91-2d5f-4a06-8b3c-1e9f7d602a58",

"pathTemplate": "private/{YYYY}/{MM}/{job_id}.{ext}",

"priority": 10

}'

```

Odpowiedź na wywołanie generacji zwraca ten sam podpisany URL FOTOhub, co zawsze, więc nic zbudowanego wcześniej na API się nie łamie. Nowość to blok delivery, nazywający dokładny key, na którym obiekt wyląduje, jeszcze przed zakończeniem transferu do zewnętrznego bucketu, bo układ ścieżek jest deterministyczny i policzalny z wyprzedzeniem. To właśnie na tym warto opierać sprawdzenie head request na własnym buckecie, nie na samej odpowiedzi API, bo dostawa jest z założenia odseparowana od wywołania generacji: wolny albo chwilowo niedostępny bucket nigdy nie blokuje i nie psuje generacji, którą ma odebrać.

Webhooki, podpisane i rozliczane

System webhooków obejmuje asynchroniczną stronę tego samego problemu: wiedzę, kiedy coś się zakończyło, bez odpytywania o to w kółko. Zdarzenia obejmują zakończenie i niepowodzenie generacji, niski i wyczerpany stan kredytów, zakończenie zadań wsadowych oraz rodzinę zdarzeń usuwania tła i pipeline'u e-commerce. Każda dostawa nosi podpis HMAC-SHA256 w nagłówku X-FotoHub-Signature, liczony na surowym ciele żądania, i to jest szczegół, który faktycznie ma znaczenie: weryfikacja względem ponownie zserializowanej kopii JSON daje inny podpis i fałszywe odrzucenie, więc implementacja musi sięgnąć po surowe bajty, zanim ktokolwiek ich dotknie.

```python

import hmac

import hashlib

def verify_signature(payload_bytes: bytes, signature: str, secret: str) -> bool:

expected = hmac.new(secret.encode("utf-8"), payload_bytes, hashlib.sha256).hexdigest()

return hmac.compare_digest(expected, signature)

```

Nieudana dostawa otrzymuje trzy próby z krótkim wykładniczym odczekaniem, po czym jest zapisywana w logach i odrzucana, a nie po cichu wyłączana i nie próbowana w nieskończoność. Logi dostaw są dostępne w konsoli dla każdego, kto chce sprawdzić, co dokładnie zwrócił jego endpoint i kiedy.

Dokumentacja na miarę

Wyjaśnienie tak szerokiej powierzchni wymagało prawdziwej strony dokumentacji, nie strony z przykładami curl, więc docs.fotohub.app rozrosło się razem z konsolą. Sama referencja API liczy dziś dziesiątki stron obejmujących generację, wideo, przetwarzanie zaawansowane i tematy platformowe, w tym storage, webhooki i limity żądań, z osobną sekcją przewodników prowadzącą przez pełne konfiguracje od początku do końca: routing generacji do własnego bucketu klienta, instalację CLI i obsługę webhooków głębiej, niż pozwala na to lista endpointów. Każdy przykład kodu na stronach storage i webhooków istnieje równolegle w Python, TypeScript, Go i czystym curl, bo deweloper oceniający integrację chce przeczytać przykład w języku, w którym za chwilę będzie pisał, nie tłumaczyć go samodzielnie.

Oficjalne SDK, fotohub na PyPI i fotohub na npm, oba dostarczają metody zarządzania webhookami, listowanie, tworzenie, aktualizację, usuwanie, test i odczyt logów, pod odpowiadającymi sobie nazwami w każdym języku. Storage to uczciwa dziura do zaznaczenia, nie do przemilczenia: API S3 jest wystarczająco głębokie, że SDK jeszcze nie owinęły całości, więc budowanie na najnowszych endpointach bucketów i miejsc docelowych dziś oznacza wywołanie REST API wprost, nie przez metodę klienta, co dokumentacja mówi jasno, nie sugerując pokrycia, którego jeszcze nie ma.

Dlaczego to ma znaczenie poza listą funkcji

Nic z tego nie jest nowym produktem doczepionym do FOTOhub. To ten sam Creative AI OS, generacja obrazu, wideo, audio, tekstu i 3D w ponad dwustu modelach od dziesięciu i więcej dostawców, zyskujący instalację, która zmienia "wywołaj API i odbierz plik" w "wywołaj API i odbierz wynik dokładnie tam, gdzie już działający system go oczekuje, z sygnałem w momencie, kiedy jest gotowy". Zespół marketingowy generujący wideo produktowe na dużą skalę może teraz mieć każdy render zapisywany wprost do bucketu, który jego CMS już czyta. Agencja obsługująca klientów na osobnych bucketach S3 może kierować ruch po modelu bez dotykania linii kodu pipeline'u dla każdego nowego klienta. Platforma integrująca generację FOTOhub we własnym produkcie może subskrybować webhooki zamiast odpytywać w kółko i weryfikować każdą dostawę przez podpis, zamiast ufać otwartemu endpointowi.

FOTOhub zebrał 8,6 miliona dolarów w pięciu rundach w 2026 roku, osiągając wycenę 180 milionów dolarów, z Amazon Web Services w gronie inwestorów, i obsługuje ponad 750 tysięcy użytkowników w ponad 40 krajach. Opisana tu praca w konsoli jest bezpośrednim produktem tej relacji z AWS: warstwa storage działa na realnej infrastrukturze AWS, uruchamianej i zarządzanej przez własną warstwę kontrolną FOTOhub, nie przez cienkie proxy przed czyimś cudzym panelem. To też zakład, że kolejny etap wzrostu platformy Creative AI prowadzi przez zespoły budujące na niej produkty, nie tylko przez ludzi generujących w niej bezpośrednio, i że platforma poważnie traktująca tę grupę odbiorców potrzebuje infrastruktury, która wygląda jak infrastruktura, nie jak flaga funkcji.

O FOTOhub. FOTOhub to platforma kreatywnej AI łącząca wielodostawczy katalog modeli obejmujący generację obrazu, wideo, audio, tekstu i trójwymiarową z systemem marki, silnikiem automatyzacji i udokumentowanym API, dostępnym przez oficjalne SDK, realny magazyn AWS S3 i podpisywaną warstwę webhooków.

Kontakt dla mediów. FOTOhub Press Team, FOTOhub.app

Więcej: Konsola deweloperska · Dokumentacja API · Relacje inwestorskie · Crunchbase