WordPress REST API dla marketerów — cheat sheet

WordPress REST API marketing to tematyka, która dla developerów jest oczywista, a dla większości marketerów — czarną skrzynką. W 2026 roku około 40% polskich firm korzysta z WordPressa jako CMS, a jednocześnie tylko 8–12% marketingowców w tych firmach rozumie, jak zintegrować WP z resztą stacku: GA4, HubSpot, Mailchimp, AI do generacji treści, scheduling social media. W efekcie ręcznie wklejają to, co REST API mogłoby zrobić w tle.

Ten artykuł to cheat sheet, który umożliwia marketerowi (niekoniecznie developerowi) zrozumienie i zlecenie integracji REST API w sposób, który nie wyprodukuje „projektu na 3 miesiące” za 40 000 zł. Pokażemy endpoint-y, authentication, 10 typowych scenariuszy marketingowych, narzędzia no-code do łączenia się z WP API, najczęstsze pułapki i koszty realistyczne dla polskich firm.

Tekst jest częścią klastra stack marketingowy 2026. Dla szerszego kontekstu API zobacz API GA4, Search Console, Ads. Jeżeli integrujesz WP z CRM, przeczytaj integracje CRM.

Spis treści

1. Podstawy REST API — jak to działa
2. Autoryzacja: Application Passwords, JWT, OAuth
3. Endpoint-y, które warto znać
4. 10 scenariuszy marketingowych
5. No-code: Make, n8n, Zapier
6. Custom fields, CPT, taxonomy
7. Meta SEO (Yoast, RankMath, AIOSEO) przez API
8. Batch publishing i wydajność
9. Bezpieczeństwo i rate limits
10. Typowe pułapki wdrożeniowe
11. Koszty i ROI
12. FAQ
13. Co dalej

Podstawy REST API — jak to działa

Jeśli chcesz pogłębić temat, sprawdź API GA4, Search Console, Ads. Przydatne będzie też integracje CRM — oba materiały dobrze uzupełniają powyższy artykuł.

Autoryzacja: Application Passwords, JWT, OAuth

Bez autoryzacji REST API pozwala tylko na GET publicznych danych (opublikowanych postów, kategorii). Żeby tworzyć/modyfikować, potrzebujesz uwierzytelnienia.

Application Passwords — standard 2026

Od WordPress 5.6 (grudzień 2020) wbudowane. Najbezpieczniejsza i najprostsza metoda:

1. Admin WP → Users → Your Profile.
2. Sekcja „Application Passwords” → nazwij aplikację (np. „Make.com integration”).
3. Kliknij „Add New Application Password”.
4. WordPress generuje 24-znakowe hasło (jednorazowo widoczne). Skopiuj je od razu.
5. Używasz go jako hasło w Basic Auth razem z nazwą użytkownika.

Przykład request-u:

• Header: Authorization: Basic BASE64(user:app_password)
• Endpoint: POST https://example.pl/wp-json/wp/v2/posts
• Body JSON z danymi posta.

JWT Auth (plugin)

Alternatywa, szczególnie dla aplikacji mobilnych. Wymaga pluginu „JWT Authentication for WP REST API”. Plus: tokeny, które można odwołać centralnie, lepsza kontrola sesji. Minus: dodatkowy plugin do utrzymania, więcej złożoności. Dogłębną analizę znajdziesz w Ahrefs vs Semrush vs Sistrix 2026.

OAuth 1.0a

Legacy, ale wciąż używane dla integracji B2B z bankami, systemami ERP. Skomplikowane, wymaga dedykowanej konfiguracji. Dla typowego marketingu nie potrzebne.

Ważne: nigdy nie używaj Basic Auth z hasłem użytkownika

Nigdy nie używaj normalnego hasła użytkownika WP w REST API. To hasło daje dostęp też do loginu przez przeglądarkę — jedna kompromitacja = pełny hack. Zawsze Application Passwords lub JWT.

Endpoint-y, które warto znać

10 najczęściej używanych endpoint-ów dla marketingu:

Endpoint	Metoda	Zastosowanie
/wp/v2/posts	GET, POST	Lista postów, tworzenie
/wp/v2/posts/{id}	GET, PUT, DELETE	Jeden post
/wp/v2/pages	GET, POST	Strony (Landing Pages)
/wp/v2/media	GET, POST	Upload obrazów, plików
/wp/v2/categories	GET, POST	Kategorie
/wp/v2/tags	GET, POST	Tagi
/wp/v2/users	GET, POST	Użytkownicy / autorzy
/wp/v2/comments	GET, POST	Komentarze
/wc/v3/products	GET, POST	WooCommerce produkty
/wc/v3/orders	GET, POST	Zamówienia WooCommerce

Query parameters

Filtrowanie, sortowanie, paginacja:

• ?per_page=50 — 50 rezultatów per strona (max 100).
• ?page=2 — druga strona.
• ?orderby=date&order=desc — sortowanie.
• ?categories=3,5 — tylko z kategoriami 3 i 5.
• ?search=marketing — szukanie tekstu.
• ?after=2026-01-01T00:00:00 — tylko od daty.
• ?status=draft — tylko szkice.

10 scenariuszy marketingowych

1. Batch publishing z arkusza Google Sheets

Arkusz z kolumnami: tytuł, content, kategoria, tag, data publikacji, featured image URL. Make/n8n iteruje po wierszach, tworzy posty przez POST /wp/v2/posts. Używane dla migracji ze starego CMS, wstępnej migracji contentu, masowych publikacji z AI generation. Szczegóły znajdziesz w stack marketingowy 2026.

2. Auto-update meta SEO po edycji artykułu

Pracownik edytuje artykuł w WP. Webhook wysyła dane do API AI (OpenAI, Claude). API zwraca nowy meta title i description. Make PATCH-uje meta przez API RankMath/Yoast. Bez wchodzenia do edytora.

3. Sync contentu z Notion/Airtable do WP

Zespół redakcyjny pisze w Notion. Kiedy karta w Notion zmienia status na „Approved”, Make pobiera treść, konwertuje z Notion blocks do HTML, POST-uje post w WP jako draft z uzupełnionymi kategoriami i tagami.

4. Export nowych postów do Mailchimp/Brevo jako newsletter

Po publikacji posta Make: (a) pobiera post przez GET /wp/v2/posts/{id}, (b) konwertuje do email template, (c) tworzy kampanię w Mailchimp API, (d) planuje wysyłkę na następny dzień rano. Manualne „zbuduję newsletter” znika.

5. Lead capture z Gravity Forms do HubSpot/Pipedrive

User wypełnia formularz. Gravity Forms webhook wysyła dane do Make. Make: (a) tworzy kontakt w HubSpot, (b) dodaje notatkę z UTM source, (c) taguje w Mailchimp, (d) powiadamia sales w Slack. Forma → CRM → sales w 30 sekund bez pracy ręcznej.

6. Auto-tagging artykułów na podstawie content

Po publikacji posta Make: (a) pobiera content przez API, (b) wysyła do OpenAI z promptem „wyciągnij 5 tagów z listy X”, (c) assignuje tagi przez POST /wp/v2/posts/{id} z polem tags. Spójna taksonomia bez ręcznej pracy redaktora.

7. Scheduled publishing z content calendar

Content calendar w Airtable. Gdy status „Ready to publish” i data dzisiejsza, Make: (a) tworzy post w WP przez POST, (b) ustawia status „publish” z datą, (c) powiadamia social media manager w Slack, (d) dodaje event do Google Calendar.

8. Repurposing: artykuł → 5 postów LinkedIn

Po publikacji posta Make: (a) pobiera treść, (b) prompt AI: „z artykułu wyciągnij 5 tez, każda jako post LinkedIn z CTA”, (c) planuje 5 postów w Buffer/Hootsuite rozłożonych na 10 dni, (d) zwraca link do artykułu do tracking.

9. Content audit — report co 90 dni

Cron raz na kwartał: Make pobiera wszystkie posty z ostatnich 90 dni (GET /wp/v2/posts?after=…&per_page=100&page=N), enrichuje ruchem z GA4 API, pozycjami z Search Console API. Generuje raport „top performers, underperformers, to-refresh” w Google Sheets.

10. Auto-generate product descriptions (WooCommerce)

Po dodaniu nowego produktu w WooCommerce: Make pobiera dane (nazwa, kategoria, atrybuty), wysyła do AI z promptem „napisz description 150 słów zgodnie z brand voice”, PUT-uje description przez /wc/v3/products/{id}. Przy 500+ SKU to oszczędność kilkudziesięciu godzin miesięcznie.

No-code: Make, n8n, Zapier

Nie musisz umieć kodować. Trzy najpopularniejsze narzędzia obsługują WP REST API natywnie.

Make.com

Najpopularniejszy w PL w 2026. Moduły WordPress z autouzupełnianiem pól. Plus: wizualny flow editor, wbudowana obsługa błędów, retry mechanisms. Minus: drogi przy dużej liczbie operations. Cennik: Core 99 zł/miesiąc (10k ops), Pro 159 zł/miesiąc (10k ops + nielimitowane scenariusze).

n8n

Self-hosted open source. Plus: darmowy (po hostingu), kontrola danych, wielka biblioteka nodes. Minus: wymaga ogarnięcia serwera. Dla firm, które mają zespół DevOps, n8n na Digital Ocean/Hetzner (40–80 zł/miesiąc) to najtańszy sposób na zaawansowane automatyzacje.

Zapier

Globalny lider, dobre UI, świetna dokumentacja. Ale: drogi dla marketingu PL (pricing w USD), mniej opcji WP niż Make. Rekomendacja: zostań na Zapier, jeśli już go używasz; zacznij od Make, jeśli startujesz.

Direct coding (dla zespołów technicznych)

Python + requests, Node.js + axios, PHP. Szybkie dla one-off scripts. Dla powtarzalnych flow no-code tools są szybsze w wdrożeniu i utrzymaniu.

Custom fields, CPT, taxonomy

Custom Fields (ACF, Meta Box)

Wiele sklepów i stron używa Advanced Custom Fields. Są dostępne przez REST API, ale wymagają konfiguracji — domyślnie ACF nie exponuje pól w API. Wystarczy zaznaczyć „Show in REST API” w ACF field group.

Po konfiguracji pole widoczne w response pod acf.{field_name}. PUT/POST: wysyłasz jako część body w polu acf.

Custom Post Types (CPT)

Własne typy postów (np. „Produkty”, „Case Studies”, „Webinary”) potrzebują rejestracji z show_in_rest => true. Po tym endpoint: /wp/v2/{cpt_slug}.

Custom taxonomies

Własne taksonomie (np. „Tematyka”, „Poziom zaawansowania”) analogicznie — show_in_rest w rejestracji, endpoint /wp/v2/{taxonomy_slug}.

Zakres pól (fields parameter)

Dla wydajności: ?_fields=id,title,date,link — zwraca tylko te pola. Zmniejszenie response body o 80% przy 500 postach = szybsza integracja, mniejsze koszty transferu.

Meta SEO (Yoast, RankMath, AIOSEO) przez API

Większość SEO pluginów ma własne endpoint-y lub rozszerza standardowe.

Yoast SEO

Od wersji 14+ Yoast dodaje pola do standardowego /wp/v2/posts. W response widzisz yoast_head i yoast_head_json z meta title, description, OG, Twitter card, schema. Dla edycji: pole meta w POST/PUT. Częstsze w 2026 — Yoast ma dedykowane endpoint-y pod /yoast/v1/.

RankMath

Rozszerza post meta pod polami rank_math_title, rank_math_description, rank_math_focus_keyword. Edycja: POST/PUT z tymi polami w meta. Plugin nie ma dedykowanego REST namespace, ale standardowe pola działają.

AIOSEO

Podobnie — pola aioseo_title, aioseo_description. Plugin ma też własny REST endpoint pod /aioseo/v1/ dla zaawansowanych operacji.

SEOPress

Pola _seopress_titles_title, _seopress_titles_desc. Ukryte meta — wymagają ustawienia show_in_rest lub użycia dedykowanego API /seopress/v1/.

Praktyczna uwaga

Nie wszystkie pola SEO pluginów są automatycznie dostępne w REST API. Zawsze przetestuj GET na konkretnym poście — sprawdź, co jest w response. Jeśli pól brakuje, dodaj filter w functions.php (10-linijkowy) lub poproś developera o 30-minutową konfigurację.

Batch publishing i wydajność

Tworzenie 50+ postów przez API wymaga optymalizacji. Nie POSTuj ich sekwencyjnie jeden po drugim.

Limity wydajności

• Pojedynczy POST /wp/v2/posts na standardowym hostingu: 0,8–3 sekund. Przy 500 postach sekwencyjnie: 7–25 minut.
• Parallel (4–8 równoczesnych): redukcja do 2–6 minut, ale ryzyko rate limiting.
• Media upload: 2–8 sekund per image (w zależności od wielkości i hosting).

Rate limiting

Standard WordPress nie ma wbudowanego rate limitu, ale:

• Niektóre hostingi (WP Engine, Kinsta, Flywheel) limitują do 100 requests/minute.
• CloudFlare i inne WAF-y limitują podejrzany traffic.
• Security pluginy (Wordfence, iThemes) mogą limitować po kilkunastu requests z tego samego IP.

Best practice: puszczaj 4–8 requests równolegle, sleep 200–500ms między batchami, retry z exponential backoff przy 429/503.

Wtyczka dla batch (rozszerzenia)

Dla ekstremalnych wolumenów (1000+ postów/godz) rozważ custom endpoint z własnym „bulk insert”:

1. Developer pisze endpoint /custom/v1/bulk-posts.
2. Endpoint przyjmuje array 50 postów naraz.
3. Używa wp_insert_post() w pętli — szybsze niż 50 oddzielnych HTTP requests.

Koszt developera: 3–8 tys. zł, ale zwrot przy pierwszej dużej migracji (5000+ postów).

Bezpieczeństwo i rate limits

REST API otwarte bez ograniczeń = ryzyko bezpieczeństwa. Najczęstsze wektory ataku:

• Wyciek listy użytkowników — GET /wp/v2/users domyślnie zwraca listę (bez haseł, ale z nazwami). Wyłącz to w functions.php filtrem rest_endpoints.
• Brute force Application Password — ogranicz nieudane próby (Wordfence, Limit Login Attempts).
• DDoS na endpoint-ach — CloudFlare, AWS WAF, lub plugin „REST API Rate Limits”.
• Wstrzyknięcia przez content — sanityzuj content przed POST, nie ufaj automatycznie danym z AI.

Checklist produkcyjnego REST API

1. Application Passwords dla każdej integracji, NIE hasło userskie.
2. HTTPS obowiązkowo — REST API nad HTTP wysyła hasła jako base64 (odczytywalne w transit).
3. Rate limiting na poziomie WAF lub pluginu.
4. Monitoring nieudanych auth attempts (Slack/email alert przy 10+ failures/min).
5. Rotacja application passwords co 90 dni.
6. Logging wszystkich POST/PUT/DELETE do audit trail.

Typowe pułapki wdrożeniowe

1. CORS errors

Próbujesz wywołać WP REST API z aplikacji JavaScript na innej domenie. Browser blokuje z CORS policy. Fix: plugin „CORS” lub w functions.php dodaj nagłówek Access-Control-Allow-Origin dla swoich domen. Nigdy nie ustawiaj * na produkcji.

2. Encoding znaków polskich

POST z polskim tekstem przychodzi jako „â”. Przyczyna: encoding content-type. Zawsze Content-Type: application/json; charset=utf-8, baza danych MySQL skonfigurowana z utf8mb4.

3. Featured image nie ustawia się

POST posta nie ustawia featured_media. Fix: featured image to osobne ID — najpierw upload /wp/v2/media, weź ID, potem PATCH posta z featured_media: {id}.

4. Categories/tags nie znajdują się

POST posta z categories: ['Marketing'] — nie działa. REST API przyjmuje ID kategorii, nie nazwy. Najpierw GET /wp/v2/categories, znajdź ID, potem POST posta z categories: [5, 8].

5. Cache na GET-ach

Po POST nowego posta, GET /wp/v2/posts nadal zwraca starą listę. Fix: CloudFlare page rules z pominięciem /wp-json/*, lub cache plugin WP z wykluczoną ścieżką.

6. Status 500 bez informacji

Typowy problem: PHP memory limit za niski (szczególnie dla batch upload media). Fix: zwiększyć memory_limit w wp-config.php do 256–512 MB.

7. Data publikacji w UTC vs lokalnej

WordPress przechowuje dwie daty: date (lokalna) i date_gmt (UTC). Jeśli POSTuje tylko date, WP interpretuje ją jako lokalną i dodaje offset w zapisie. Dla automatyzacji z innych stref czasowych zawsze używaj date_gmt z formatem ISO 8601 (2026-04-15T12:00:00). Pozwoli to na poprawne schedulowanie niezależnie od strefy serwera WP.

8. Slug vs ID dla kategorii

Niektóre biblioteki klienckie zwracają listę kategorii jako slugi, nie ID. REST API WP akceptuje tylko ID — najpierw musisz zrobić lookup. Best practice: cache mapy slug→ID lokalnie, odświeżaj co 24 h. Dla dużych stron z 500+ kategoriami lookup ad hoc zwiększa czas operacji o 30–60%.

9. Revisions blokują UPDATE

Każdy PUT/PATCH tworzy revision. Przy 10 updates dziennie w 500 postach w ciągu roku masz 1,8 mln rekordów wp_posts. Baza spowalnia. Fix: define('WP_POST_REVISIONS', 5) w wp-config.php ogranicza liczbę revisions per post. Dla integracji automatyzacyjnych rozważ też define('WP_POST_REVISIONS', false) lub cleanup plugin typu WP-Optimize uruchamiany co tydzień.

Koszty i ROI

Self-service (marketingowiec z Make)

• Koszt: Make 99–159 zł/miesiąc + application password setup (15 min).
• Czas wdrożenia: 4–10 godzin dla pierwszych 3 scenariuszy.
• Oszczędność: 10–30 godzin/miesiąc w zespole marketingowym.
• ROI: zwrot w 1. miesiącu.

Freelancer (2–10 scenariuszy, custom)

• Koszt: 2–8 tys. zł jednorazowo + utrzymanie 200–600 zł/miesiąc.
• Czas wdrożenia: 2–6 tygodni.
• Oszczędność: 40–100 godzin/miesiąc.
• ROI: 3–6 miesięcy.

Agencja (pełny stack z CRM, AI, social)

• Koszt: 15–40 tys. zł jednorazowo + 1 500–4 000 zł/miesiąc utrzymania.
• Czas wdrożenia: 4–10 tygodni.
• Oszczędność: 120–400 godzin/miesiąc (dla większych firm z 3+ osobami marketing).
• ROI: 4–8 miesięcy.

FAQ

Czy REST API jest dostępne dla każdej instalacji WordPress?

Tak — od WordPress 4.7 (grudzień 2016) REST API jest wbudowane w core i nie wymaga wtyczek. Wyjątki: (a) niektóre hostingi security wyłączają endpoint-y domyślnie dla ochrony przed automatyzowanymi atakami (np. niektórzy shared hosting providers w PL); sprawdź w panelu hostingowym lub zapytaj supportu; (b) WordPress z security pluginem typu Wordfence Premium ma opcję „Disable XML-RPC and REST API” dla niezalogowanych userów; w takim wypadku potrzebujesz auth dla każdego request; (c) self-hosted enterprise setup (Pantheon, WP VIP) może mieć swoje custom auth. Dla 95% standardowych instalacji WP w PL REST API działa out-of-the-box bez dodatkowej konfiguracji — wystarczy Application Passwords dla uwierzytelnienia.

Czy REST API zastępuje XML-RPC?

Tak, w praktyce zastąpiło. XML-RPC (/xmlrpc.php) był poprzednikiem — wciąż działa, ale jest uważany za mniej bezpieczny (częstszy wektor ataków brute-force). W 2026 większość nowoczesnych integracji używa REST API. XML-RPC nadal jest potrzebny dla: (a) starszych narzędzi (np. niektóre wersje MarsEdit, Open Live Writer), (b) trackbacków i pingbacków. Jeśli nie używasz żadnego z powyższych, wyłącz XML-RPC dla bezpieczeństwa — Wordfence ma taką opcję, albo dodaj w .htaccess blok <Files xmlrpc.php> deny from all </Files>. REST API jest wszechstronnejsze, bezpieczniejsze (HTTPS + Application Passwords) i lepiej udokumentowane — pełne przejście na REST to best practice 2026.

Ile obrazów mogę upload-ować przez REST API naraz?

Teoretycznie nieograniczenie, praktycznie ograniczają Cię trzy rzeczy: (1) upload_max_filesize i post_max_size w PHP (standardowo 8–64 MB; pytaj hosting o zwiększenie); (2) max_execution_time — dla dużych plików (video) może się wyzerować przy 30s default (zwiększ do 120–300s); (3) memory_limit — przy batch 20+ obrazów z procesowaniem thumbnails potrzeba 256+ MB. Best practice: upload pojedynczo (jedno media per request), z parallel-ingiem 2–4 (nie więcej). Dla sklepu z 1000 nowymi produktami miesięcznie: 3–4 godziny batch upload z automatycznym assigning do produktów przez PATCH. Uwaga na koszty storage (S3, WP Engine multi-site) i CDN (CloudFlare, BunnyCDN) — przy skali kilkuset GB miesięcznie koszty transferu mogą być istotne.

Czy mogę uruchomić AI-wspomagane publikowanie (ChatGPT → WP) bez developera?

Tak — Make/n8n mają natywne moduły OpenAI i WordPress. Scenariusz przykładowy: (1) trigger cron co tydzień, (2) OpenAI module z promptem „napisz artykuł 1500 słów o temacie X zgodnie z brand voice Y”, (3) optional: drugi call OpenAI dla meta title i description, (4) WordPress Create Post z wygenerowaną treścią, status „draft” (żeby człowiek zaakceptował), (5) Slack notification do redaktora. Koszt: Make 99 zł + OpenAI API 20–100 zł/miesiąc (w zależności od wolumenu) + Twoja godzina miesięcznie na utrzymanie. Warning: AI content bez edycji człowieka jest ryzykiem SEO (duplicate content z tysięcy podobnych promptów) i brand voice (czuć AI). Użyj jako „draft 0″ — człowiek edytuje przed publish. W 2026 Google ma wyraźne helpful content updates celujące w nieweryfikowany AI content, więc hybrid approach (AI draft + human edit 30–60 min per artykuł) jest znacznie bezpieczniejsze.

Czy REST API wpływa na performance WordPress?

Minimalnie dla GET requests (cache’owane przez WP + CDN), zauważalnie dla POST/PUT/DELETE. Każdy POST nowego posta to: (a) zapis do bazy (wp_posts, wp_postmeta, wp_terms_relationships), (b) uruchomienie hooks (pluginy SEO, cache invalidation, social share), (c) media processing (jeśli attached), (d) potencjalnie trigger innych automatyzacji. Dla typowej instalacji WP pojedynczy POST to 0,8–3 sekundy CPU + I/O. Przy 100 POSTs/godzinę obciążenie jest zauważalne, ale manageable. Przy 500+/godzinę rozważ: (1) osobny server lub większy plan hostingu; (2) custom bulk endpoint (jedna baza transakcja dla N postów); (3) delay między requests. Monitorring: obserwuj loady serwera, czas response, 500 errors. Performance problemy typowo nie dotyczą małych kampanii (kilka postów tygodniowo), tylko dużych migracji i scale-up operacji.

Jakie są realistyczne ROI integracji REST API dla średniej firmy?

Dla firmy 20–50 osobowej z 3-osobowym zespołem marketing w PL 2026: (a) typowy koszt wdrożenia „3 kluczowych scenariuszy” (publishing z calendarza, SEO meta auto-update, newsletter z nowych postów): 5–15 tys. zł jednorazowo + 500–1 500 zł/miesiąc utrzymania; (b) oszczędność czasu: 30–80 godzin miesięcznie w zespole marketing (przeciętny koszt godziny 80–150 zł brutto) = 2 400–12 000 zł/miesiąc wartości odzyskanego czasu; (c) dodatkowe korzyści jakościowe (mniej błędów, szybsza dystrybucja, lepszy SEO follow-through) — trudne do kwantyfikacji, ale realne. ROI netto: zwrot w 2–5 miesięcy dla firm z aktywnym content production (10+ artykułów miesięcznie). Dla firm publikujących 2–4 artykuły miesięcznie integracja REST API jest często „overkill” — rekomendacja: zacznij od 1–2 scenariuszy (Make setup), oceń po 3 miesiącach, skaluj jeśli widzisz wartość.

Co dalej

Jeśli chcesz pogłębić temat, sprawdź API GA4, Search Console, Ads. Warto też przejrzeć integracje CRM — oba materiały dobrze uzupełniają powyższy artykuł.