> For the complete documentation index, see [llms.txt](https://docs.sportradar.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sportradar.com/live-data/introduction/information-per-sport/mma/mma-integration-guide-imga-ufc-feed-vs.-sportradar-live-data-ld.md).

# MMA Integration Guide: IMGA / UFC Feed vs. Sportradar Live Data (LD)

## MMA Integration Guide: IMGA / UFC Feed vs. Sportradar Live Data (LD)

***

### 1. Overview & Architectural Philosophy

This document outlines the architectural and conceptual differences between the legacy **IMGA UFC feed** (hosted on DDE) and the standard **Sportradar Live Data (LD)** delivery model for MMA.

Historically, the IMGA MMA feed blended static metadata, scheduling, live state, and detailed post-fight results into a fragmented set of specialized REST and live [UFC customer documentation](https://docs.sportradar.com/ufc). Under Sportradar’s unified sports architecture, MMA is aligned with all other **Sportradar Live Data (LD)** sports (such as Soccer, Tennis, Basketball, and Ice Hockey), enforcing a strict and clean **Domain Split**:

#### MMA Data Ecosystem

| Sportradar Live Data (LD Feed)                                                                                                                                                                           | Sportradar Sports Data (REST API)                                                                                                                                                               |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <ul><li>In-play / real-time</li><li>Match booking (matchlist)</li><li>Push via XML socket</li><li>Events, clocks, and rounds</li><li>Live strikes / actions</li><li>Fight results and verdicts</li></ul> | <ul><li>Static / editorial</li><li>Pre-match and post-match</li><li>Pull via RESTful HTTP</li><li>Fighter profiles and bios</li><li>Official rankings</li><li>Historical head-to-head</li></ul> |

***

### 2. Core Architectural Principles & Domain Split

#### 1. Unified Sports Alignment

* **Standardized Protocol:** The MMA LD feed is integrated into the same socket-based XML streaming architecture used across all Sportradar Live Data products.
* **Minimal Overhead over Socket:** Sportradar minimizes static/reference data transmitted through socket connections. The stream delivers strictly what is necessary to follow and settle the live contest in real time.

#### 2. Match-Centric Schedule Model ("Fights as Matches")

* **IMGA Paradigm:** IMGA treated the whole event night as a parent Fightcard, requiring consumers to query separate Fightcards and Fightcard Schedule endpoints to locate individual bouts in the [UFC customer documentation](https://docs.sportradar.com/ufc).
* **Sportradar LD Paradigm:** In Sportradar LD, **each individual fight is modeled and booked as a standalone "Match"**.
* **The Matchlist:** The equivalent of fight card schedules is the standard Sportradar **matchlist**. Fights appear as standard bookable fixtures containing essential fixture metadata:
  * Fixture ID / Sportradar Event ID
  * Scheduled Date & Start Time
  * Competitors (Fighter Red Corner vs. Fighter Blue Corner)
  * Category / Organization / Tournament (e.g., UFC, PFL, Dana White's Contender Series)
  * Weight Class / Title Fight designation

***

### 3. Real-Time Coverage: Unified XML Stream vs. Disjointed IMGA Endpoints

In the legacy IMGA architecture, live fight consumption was fragmented across multiple REST polling and live connection mechanisms (e.g., Live Events, Fight Details, Fight Stats, and Fight Actions) in the [UFC customer documentation](https://docs.sportradar.com/ufc):

* **Live Status & State:** Current round, round time elapsed/remaining, stoppage state, referee interventions, and round breaks.
* **Live Actions & Events:** Significant strikes, knockdown events, takedowns, submission attempts, reversals, and point deductions.
* **Live Match Statistics:** Running punch/kick strike volume landed/attempted, control time, and octagon positioning.
* **Fight Results & Verdicts:** Official decision type (KO/TKO, Submission, Unanimous/Split/Majority Decision, Disqualification, No Contest), winning fighter, round, and exact time of stoppage.

Clients no longer need to manage multiple HTTP polling intervals alongside socket streams to construct an in-play state described in the [UFC customer documentation](https://docs.sportradar.com/ufc); the XML feed delivers the authoritative live source from walkout to official decision.

***

### 4. Master & Reference Data: Delegated to Sports Data API

A key change from the IMGA feed is that **static reference data and historical statistics are decoupled from the Live Data pipeline**, as described in the [UFC customer documentation](https://docs.sportradar.com/ufc).

#### What is NOT included in the Sportradar Live Data (LD) Feed:

* ❌ **No Fighter Endpoints / Deep Biographies:** Fighter age, reach, leg reach, fighting style, stance, gym affiliation, and past fight logs are not served over LD sockets.
* ❌ **No Fighter Rankings:** Official division rankings and pound-for-pound rankings are not published in the live stream.
* ❌ **No Historical or Per-Round Retrospective Archives:** Post-fight deep statistical archives and past event scorecards do not belong to the live engine.

#### Where to Find It: Sportradar Sports Data API (REST)

All contextual, biographical, and archival data are queried on demand via the **Sportradar Sports Data API (MMA)**:

* **Fighter Profile & Career Records:** Complete profiles, physical measurements, and historical bout-by-bout logs.
* **Weight Class Dictionaries:** Comprehensive metadata for recognized divisions (Flyweight through Heavyweight, catchweights, unified rules specifications).
* **Official Rankings:** Periodic updates per division and pound-for-pound tables.
* **Detailed Post-Fight Analytics:** Complete per-round analytics, judge scorecards, and historical fight cards.

***

### 5. Comparative Mapping Table

| IMGA UFC / DDE Endpoint ([UFC customer documentation](https://docs.sportradar.com/ufc)) | IMGA Feed Nature ([UFC customer documentation](https://docs.sportradar.com/ufc)) | Sportradar Equivalent Service | Sportradar Delivery Method | Description / Key Differences                                                                                    |
| --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------- | -------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Fightcards Endpoint**                                                                 | Static REST (every 5 min)                                                        | **Sports Data API**           | REST API                   | Season / Tournament / Event schedule covering fight card metadata.                                               |
| **Fightcards Schedule Endpoint**                                                        | Static REST (every 30 sec)                                                       | **Live Data: matchlist**      | Live Data HTTP / XML Feed  | Fights are exposed as standard matches available for booking with competitors, scheduled time, and weight class. |
| **Live Events Endpoint**                                                                | Live REST                                                                        | **Live Data: XML Stream**     | XML Socket Stream          | Embedded directly within match status events in the live stream; no separate endpoint required.                  |
| **Fight Details**                                                                       | Live (<1s latency)                                                               | **Live Data: XML Stream**     | XML Socket Stream          | Real-time fight events (round transitions, knockdowns, fouls, stoppages).                                        |
| **Fight Stats**                                                                         | Live (5s latency)                                                                | **Live Data: XML Stream**     | XML Socket Stream          | Live strike counts, control time, and basic statistical counters.                                                |
| **Fight Actions**                                                                       | Live (5s latency)                                                                | **Live Data: XML Stream**     | XML Socket Stream          | Detailed strike locations/targets delivered directly inside the XML stream.                                      |
| **Result Endpoint**                                                                     | Static REST (every 5 min)                                                        | **Live Data: XML Stream**     | XML Socket Stream          | Instant official fight settlement/verdict published upon bout conclusion.                                        |
| **Detailed Results Endpoint**                                                           | Static REST                                                                      | **Sports Data API**           | REST API                   | Deep round-by-round statistics, judges' cards, and archival records.                                             |
| **Fighters / Fighter Endpoints**                                                        | Static REST (every 5 min)                                                        | **Sports Data API**           | REST API                   | Not in LD feed. Complete fighter profiles, career history, records, and bios.                                    |
| **Rankings Endpoint**                                                                   | Static REST (hourly)                                                             | **Sports Data API**           | REST API                   | Not in LD feed. Division and pound-for-pound rankings.                                                           |
| **Weightclasses Endpoint**                                                              | Static REST                                                                      | **Sports Data API**           | REST API                   | Not in LD feed. Division metadata and limits.                                                                    |

***

### 6. Integration Checklist for Existing IMGA Consumers

1. **Adopt Match-Level Booking:** Transition from querying fightcard schedules in the [UFC customer documentation](https://docs.sportradar.com/ufc) to consuming the Sportradar Live Data matchlist. Subscribe to individual fight IDs (sr:sport\_event:xxxxx) like any other Sportradar sport.
2. **Consolidate Real-Time Ingestion:** Replace concurrent polling of IMGA's Fight Details, Fight Stats, and Fight Actions in the [UFC customer documentation](https://docs.sportradar.com/ufc) with a single Sportradar XML socket feed listener.
3. **Shift Reference Queries to Sports Data API:** Point existing queries for fighter profiles, divisional rankings, and pre-fight bios in the [UFC customer documentation](https://docs.sportradar.com/ufc) to Sportradar’s RESTful Sports Data endpoints rather than attempting to discover them via the live channel.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sportradar.com/live-data/introduction/information-per-sport/mma/mma-integration-guide-imga-ufc-feed-vs.-sportradar-live-data-ld.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.