Skip to content

Sportbook API - Get started

Welcome to the Sportbook API documentation.
This section covers all the APIs available for the Sportbook platform, providing information about endpoints, authentication, and integration patterns.

Overview

The Sportbook API is a suite of RESTful APIs designed to power sports betting applications.
It provides access to sports data, betting functionality, user management, and various supporting services.

Note

Different APIs can be used for different scenarios of integration.

Integration scenarios

  • IFrame integration - to integrate our Frontend and Platform as part of your existing site
  • Build own frontend - to build your custom frontend over our Platform
  • Use MTS - to build backend-to-backend integration to integrate your Platform with our Platform
  • Use BusinessObjects - to build backend-to-backend integration for reporting or other needs

Available APIs

  • GR8 API : Core API for the GR8 platform

    • Primary customer-facing API ready to use for browser application
    • Handles betting operations, line data, and user interactions

  • S2S API : Server-to-Server API

    • Backend integration API for system-to-system communication
    • Administrative and operational endpoints
  • RabbitMQ: this API is available only as part of MTS product

HTTP API versioning

Most HTTP endpoints in S2S API and GR8 API have relative path in the following format: /<PLATFORM_VERSION>/<PLATFORM_MODULE>/<MODULE_VERSION>/<API_COMPONENT>/<API_COMPONENT_ENDPOINT>

  • PLATFORM_VERSION and MODULE_VERSION - represents Platform's and Platform module's rarely changed versions.
  • PLATFORM_MODULE - represents the name of Platform's module. Like "sport" for SportBook module, "pam" - Player Account Management module etc
  • API_COMPONENT - represents component within the module that are delivered independently like "line" within "sport" module, "registration" within "pam" module
  • API_COMPONENT_ENDPOINT - identifies concrete endpoints within API_COMPONENT

Each endpoint within an API component can evolve independently:

  • Endpoint can change contract versions then it:
    • can change - if its part of new version of the module
    • can change if it's considered as new endpoint
    • can accept "Api-Version" header if new version of endpoint contracts is added (after this old one is considered as obsolete). Api-Version is version of contracts.
  • Endpoint can be updated without changing contracts. In this case
    • endpoint response can contain X-Endpoint-Version header (for example, X-Endpoint-Version: 0.9.0)
      • It identifies the backend service version serving the response. Its value is not in-sync with Api-Version that represents contract version
      • It helps determine if a specific feature is available — documentation will indicate the minimum required version when relevant.
      • Useful for debugging or tracking version-specific behavior.
      • Note: This header is informational only — it should not influence application logic.

Supporting Resources

  • Domain Description - Core domain concepts and values (for now described in MTS contracts)
  • Additional Resources - Additional documentation and resources
    • Market translation guides
    • Integration examples
    • Best practices and patterns
  • Changelog - Latest updates, new features, and breaking changes

General recommendations

  • For HTTP API if you have received 429 Too Many Requests - you are facing with rate limiting or throttling from our side. Such failed requests should be retried with some backoff pattern. Different endpoints have different rate limits. For details read endpoint documentation, otherwise contact company representative.