Working with GraphQL

Every Kesk data API is GraphQL. If you have used GraphQL before, there is nothing unusual here — this page covers the specifics.

One endpoint per surface

All requests are POST with Content-Type: application/json:

No subscriptions

None of the 12 schemas defines a subscription type. There is no GraphQL transport for live updates.

For event-driven integration use webhooks — that is the supported push mechanism. Every vendor vertical documents them on its own page; see Vendor APIs.

Introspection is open

You can introspect any endpoint without a token:

This makes GraphQL IDEs, editor plugins and codegen work without credentials. Executing a real query still requires a token.

You do not need to introspect for tooling, though — we publish the SDL. See Code generation.

Root type names differ per vertical

Each vertical has its own root types: FoodQuery/FoodMutation, TaxiQuery/TaxiMutation, AccommodationQuery, and so on.

This matters if you generate code for several verticals into one project — the root types will not collide, but the shared types (Webhook, Location, Order) are structurally identical across schemas and will collide — and since the Developer* prefix was dropped these names are short enough to collide with your own types too. Generate into separate namespaces or modules per vertical.

Requesting only what you need

Fragments keep a selection set in one place and let you reuse it:

Scalars

Beyond the built-ins, the schemas use:

Decimal is a string on purpose: monetary amounts must not go through a binary floating-point type. Parse it into a decimal type in your language (BigDecimal, decimal.Decimal, Prisma.Decimal), never float.

Next

• Errors — why HTTP 200 does not mean success
• Pagination — cursor connections and result counts
• Rate limits