cmssy udostępnia treść przez dwie powierzchnie programistyczne. API dostawcze czyta opublikowaną treść, żeby Twój frontend mógł ją wyrenderować. Serwer MCP czyta i zapisuje całą resztę - i to do niego podłączają się klienci AI, tacy jak Claude.

API dostawcze

Każda opublikowana strona, layout i ustawienie serwisu są do odczytu przez jeden endpoint GraphQL:

https://api.cmssy.io/public/{org}/{workspace}/graphql

SDK składa tę ścieżkę z Twojego apiUrl, org i workspaceSlug, więc ustawiasz trzy wartości konfiguracyjne i nigdy nie sklejasz URL-a ręcznie. Ponieważ organizacja siedzi w ścieżce, slug workspace'u musi być unikalny tylko w obrębie swojej organizacji.

Zapytania pod korzeniem public nie wymagają tokenu - cmssy zwraca tam wyłącznie opublikowaną treść. Dokładnie to wywołuje @cmssy/next przy renderowaniu strony, więc rzadko odpytujesz je ręcznie. Sięgnij po nie wprost, gdy budujesz coś, czego SDK nie obsługuje: sitemapę, kanał RSS, indeks wyszukiwarki.

Operacje, z których faktycznie korzysta frontend:

• public.page.list - każda opublikowana strona: id, slug, updatedAt, publishedAt.
• public.page.get - jedna strona po slugu, z tytułem SEO, opisem i słowami kluczowymi.
• public.page.getById - publishedBlocks strony, czyli instancje bloków budujące jej treść.
• public.page.layouts - bloki layoutu (header i footer) dla strony.
• public.siteConfig - nazwa serwisu, język domyślny i włączone języki, branding.

Minimalne zapytanie - to samo, które stoi za static params i sitemapą w każdym froncie cmssy:

query PublicPages($workspaceSlug: String!) {
  public {
    page {
      list(workspaceSlug: $workspaceSlug) {
        id
        slug
        updatedAt
        publishedAt
      }
    }
  }
}

Treść bloku wraca jako JSON kluczowany językiem, więc content.pl.title to polski tytuł danej instancji bloku. Pola relacyjne przechowują id rekordów; API dostawcze rozwiązuje je do pełnych rekordów w czasie renderowania.

Zapis jest tu celowo wąski. Jedyna publiczna mutacja to wysłanie formularza:

mutation SubmitForm($formId: ID!, $input: SubmitFormInput!) {
  public {
    form {
      submit(formId: $formId, input: $input) {
        success
        message
        submissionId
      }
    }
  }
}

Serwer MCP

Tworzenie stron, edycja treści bloków, wgrywanie mediów, zarządzanie modelami i rekordami, publikacja - to wszystko idzie przez serwer MCP. Mówi protokołem Model Context Protocol, więc klient AI podłącza się do niego i edytuje treść bezpośrednio. Nigdy nie rusza Twojego kodu: schematy bloków zostają w repo, treść zostaje w cmssy.

Sprawdza się też jako cel dla skryptów, gdy AI w ogóle nie ma w grze - te same narzędzia wywołasz z dowolnego klienta MCP.

Czego kiedy używać?

• Renderowanie serwisu - API dostawcze, przez @cmssy/next.
• Sitemapy, kanały, indeksy wyszukiwania - API dostawcze wywoływane wprost.
• Tworzenie i edycja treści - serwer MCP.
• Migracje i skrypty na treści - serwer MCP z tokenem API.

Uwierzytelnianie

Publiczne odczyty nie wymagają żadnych danych logowania. Wszystko, co zapisuje albo czyta nieopublikowane wersje robocze, wymaga tokenu API workspace'u - zobacz Tokeny API, jak go utworzyć i ograniczyć.