Jak wybrać API SMS w Polsce. 7 kryteriów dla deweloperów
Wybór API SMS to decyzja na lata — koszt migracji w trakcie projektu jest znacznie wyższy niż dobre wybranie na początku. W tym przewodniku omawiamy 7 kryteriów które warto sprawdzić przed integracją: cztery techniczne (REST, webhooki, onboarding, SDK) i trzy biznesowe (cennik, wsparcie, SLA). Skupiamy się na uniwersalnych zasadach — nie porównujemy poszczególnych dostawców z nazwy, bo dynamika rynku zmienia się szybciej niż artykuł nadąży.
Dla kogo ten przewodnik: dla deweloperów, CTO i tech leadów wybierających dostawcę SMS API dla aplikacji w Polsce. Niezależnie od skali — od MVP po system bankowy.
Kryterium 1: REST z JSON vs SOAP/XML-RPC
1. Protokół i format danych
SOAP to dziedzictwo lat 2000-2010 — wymaga generowania klas z WSDL, jest verbose (10× większy payload niż JSON), trudno debugować w przeglądarce i większość nowych bibliotek HTTP nie wspiera go natywnie. REST z JSON to standard branżowy w 2026 roku.
Test: spróbuj wysłać przykładowy SMS jednym curl. Jeśli wymaga to generowania kodu z WSDL lub bindings, dostawca jest stary szkoły.
Kryterium 2: Webhooki DLR jako natywny mechanizm
2. Raporty doręczenia
Po wysłaniu SMS-a chcesz wiedzieć, czy dotarł. Trzy typowe podejścia:
- Webhook push (DLR) — dostawca POSTuje JSON na Twój URL przy każdej zmianie statusu. Idealne.
- Polling — Ty co X minut pytasz GET /status/:id. Marnuje rate limit i opóźnia.
- Brak DLR — wysyłasz w ciemno. Niedopuszczalne dla 2FA, banków, e-commerce.
Test: sprawdź payload webhooka. Idealny zawiera: message_id, status (z enumami: delivered/failed/expired), done_at i Twój idempotency key (np. idx) — żebyś łatwo skojarzył raport z encją w bazie.
Kryterium 3: Onboarding — sandbox vs manualna weryfikacja
3. Czas i sposób startu
To kryterium, gdzie nie ma uniwersalnie lepszego wyboru — zależy od priorytetu:
| Sandbox | Manualna weryfikacja (24-72h) | |
|---|---|---|
| Czas startu | Natychmiast | 24-72h |
| Antyfraud | Słaby — anonim może spamować | Mocny — KYC przed aktywacją |
| Reputacja nadawcy | Słaba — operatorzy filtrują | Dobra — ruch zweryfikowany |
| Delivery rate | Niższy | Wyższy |
| Dla kogo | Prototypy, hackathony | Produkcja, bankowość, 2FA, e-commerce |
Sandbox dobry na pierwszy POC. Dla produkcji wybieraj dostawców z weryfikacją — wyższe delivery rate to większy ROI z każdej kampanii.
Kryterium 4: Cennik — pay-as-you-go vs abonament
4. Model rozliczeniowy
Pay-as-you-go ma trzy zalety:
- Brak ryzyka niewykorzystanego pakietu — jeśli w lipcu pojechałeś tylko 30% planowanego wolumenu, nie tracisz reszty.
- Skalowanie liniowe — kampania w Black Friday nie wymaga zmiany planu.
- Predykcja kosztów — wiesz dokładnie ile zapłacisz: cena × liczba SMS-ów.
Abonament ma sens tylko dla bardzo dużych, przewidywalnych wolumenów (100k+ SMS/mies.) gdzie negocjowana stawka per-SMS jest niższa od pay-as-you-go.
Ukryte opłaty których pilnuj: rejestracja sender ID (powinna być w cenie), opłata za webhooki (niedopuszczalne), opłata miesięczna za "utrzymanie konta" (red flag).
Kryterium 5: Wsparcie w języku polskim
5. Wsparcie i dokumentacja
Wysyłka SMS w Polsce ma swoje specyfiki: polskie znaki diakrytyczne (utf-8 vs gsm encoding), regulacje UKE, sender ID dla numerów polskich, RODO. Polski support reaguje w tych obszarach znacznie szybciej niż międzynarodowy.
Test: napisz przed integracją prosty email z pytaniem technicznym. Sprawdź:
- Czy odpowiedź przyszła w ciągu 24h? (Dla produkcji wymagaj < 4h.)
- Czy odpowiedź jest merytoryczna, czy to copy-paste z FAQ?
- Czy odpowiada żywy człowiek czy bot?
Kryterium 6: SDK i integracje no-code
6. Ekosystem narzędzi
Dedykowane SDK to nice-to-have, nie must-have. API z 6 endpointami można wywołać klientem HTTP w 5-10 liniach kodu. Ważniejsze są:
- Code samples w dokumentacji (curl, Python, Node.js, ewentualnie PHP, Go). Jeśli są — kopiujesz i jedziesz.
- OpenAPI 3.x spec — importujesz do Postman, Insomnia, generujesz klienta w dowolnym języku w 30 sekund.
- Integracje no-code — Zapier, Make, n8n. Dla zespołów które nie chcą pisać kodu na każdą drobną automatyzację.
SDK ma sens dla bardziej egzotycznych języków (Elixir, Rust) lub gdy SDK dodaje wartość (retry logic, idempotency, async).
Kryterium 7: SLA i transparentność statusu
7. Niezawodność i SLA
SMS używa się tam gdzie inne kanały zawodzą — przypomnienia o wizytach, 2FA, krytyczne notyfikacje. Awaria dostawcy oznacza realne koszty (no-show, blokady kont, frustracja klientów).
Co sprawdzić:
- Czy jest publiczny status page (np. status.dostawca.pl)?
- Jakie SLA jest w umowie? 99% = ~7h downtime/mies., 99.9% = ~45 min/mies., 99.99% = ~4 min/mies.
- Czy SLA pokrywa też dostarczalność (nie tylko dostępność API)?
- Czy jest mechanizm rekompensaty za przekroczenie SLA?
Dla większości firm 99% SLA wystarczy. Dla bankowości i high-stakes 2FA — 99.9%+.
Tabela podsumowująca — sprawdź swojego dostawcę
| Kryterium | Idealnie | Akceptowalnie | Czerwona flaga |
|---|---|---|---|
| 1. Protokół | REST + JSON | REST + XML | SOAP, własny format |
| 2. DLR | Webhook JSON z idx | Webhook XML | Brak DLR / tylko polling |
| 3. Onboarding | Manualna weryfikacja 24h | Sandbox + KYC przed produkcją | Sandbox bez kontroli |
| 4. Cennik | Pay-as-you-go bez minimum | Pakiet bez wygasania | Abonament z karami, ukryte opłaty |
| 5. Wsparcie | Polski, < 4h response | Polski, < 24h | Tylko EN, bot, brak SLA |
| 6. SDK | Code samples + OpenAPI + no-code | Code samples + PDF | Tylko PDF z 2018 |
| 7. SLA | 99.9%+ z status page | 99% z status page | Brak SLA i status page |
Jak Przypominamy.com wypada w tej tabeli
Skoro to nasz blog — uczciwie. Sprawdź sam i porównaj:
- Kryterium 1 (REST + JSON): ✓ — 6 endpointów REST, JSON, Bearer token. Zobacz openapi.json.
- Kryterium 2 (DLR): ✓ — webhook DLR + incoming SMS jako native, z polem idx.
- Kryterium 3 (Onboarding): Manualna weryfikacja 24h. Bez sandboxa — świadomy wybór dla jakości ruchu.
- Kryterium 4 (Cennik): ✓ — pay-as-you-go od 100 zł, bez abonamentu, sender ID w cenie.
- Kryterium 5 (Wsparcie): ✓ — polski support, dokumentacja po polsku.
- Kryterium 6 (SDK): ✓ — Redoc z code samples (curl/Python/Node), OpenAPI 3.1, integracje Zapier/Make/n8n.
- Kryterium 7 (SLA): 99% dla wszystkich planów. SLA wyższe (99.9%) negocjowane indywidualnie w Enterprise.
Nie pasujemy do każdego use case'u — jeśli potrzebujesz instant sandboxa bez weryfikacji, wybierz innego dostawcę. Jeśli zależy Ci na jakości ruchu i polskim wsparciu — sprawdź nas.
FAQ
REST czy SOAP — co wybrać dla nowego projektu?
REST z JSON. SOAP to dziedzictwo, REST jest standardem branżowym w 2026.
Czy webhook DLR jest wystarczający czy lepiej pollować status?
Webhook wystarczy dla 99% zastosowań. Polling marnuje rate limit i opóźnia. Polling rozważ tylko gdy nie masz publicznego endpointu.
Czym różni się sandbox od manualnej weryfikacji konta?
Sandbox = szybki start, słaba reputacja nadawcy. Manualna weryfikacja = 24h start, dobra reputacja, wyższe delivery rate. Wybór zależy od priorytetu.
Czy abonament jest lepszy niż pay-as-you-go?
Pay-as-you-go lepszy dla większości. Abonament tylko dla bardzo dużych przewidywalnych wolumenów (100k+ SMS/mies.).
Czy potrzebuję dedykowanego SDK?
Dla popularnych języków (Python, Node.js, Go, PHP) klient HTTP wystarczy. Ważniejsze są code samples i OpenAPI spec niż dedykowane SDK.
Sprawdź sam — pełna specyfikacja API
Strona dla deweloperów z 6 endpointami, dokumentacja Redoc, openapi.json, code samples i FAQ. Wszystko bez rejestracji.
Zobacz API