REST vs GraphQL

Deal Engine’s API is built with GraphQL. If you’ve worked with traditional REST APIs before, this section will help you understand what’s different and what you should expect.

REST in brief

REST (Representational State Transfer) is a common style of API design. In REST, you typically:

  • Send requests to multiple endpoints (e.g., /users/123, /bookings/456/payments).
  • Receive predefined responses, often with more or less data than you actually need.
  • Make multiple calls to gather related information.

This works well in many cases, but can become inefficient when your application needs very specific slices of data or when you want to reduce the number of network requests.

How GraphQL changes the experience

With GraphQL, instead of calling many different endpoints, you send all requests to a single endpoint (e.g., /graphql) and describe exactly the data you want in your query. The server responds with a JSON object matching your request shape.

For example:

  • If you only need a booking’s id and status, you can request just those fields.
  • If you also need the related user’s name and email, you can include those in the same query.
  • No extra data, no chaining multiple REST calls — just one request, one response.

What This Means for You

  • One Endpoint: All your integration work happens against a single GraphQL endpoint.
  • Schema as a Guide: Deal Engine publishes a strongly typed schema that defines all available types, fields, and operations. Your IDE or tooling can use this for auto-complete and validation.
  • Flexible Queries: You shape the response to your needs. This makes integrations easier to optimize for performance, especially for mobile or bandwidth-sensitive applications.
  • Real-Time Data: GraphQL also supports subscriptions, which we use for certain events where you may want live updates instead of polling.

Why We Use GraphQL

We chose GraphQL because our customers integrate with a variety of systems — each with different data needs. GraphQL lets you decide what to fetch, so you can build integrations that are efficient, predictable, and resilient without waiting for us to add new endpoints.