generated: '2026-09-06'
method: searched
source: https://dsg-api.com/introduction/
docs: https://dsg-api.com/introduction/
versioning:
  scheme: document-level
  current: '3.0'
  in_url: false
  in_header: false
  docs: https://dsg-api.com/introduction/
  note: >-
    "The current API version is 3.0." The version is not selectable by the caller - it is not in the
    path, not in a header, and not a query parameter. Every response echoes it in the
    <datasportsgroup> envelope node as `version`.
  mixed_versions: true
  mixed_versions_evidence: >-
    Individual operation pages carry their own version badge and they are not all on 3. get_matches
    (https://dsg-api.com/doc/soccer/get_matches/1/) is marked v3; get_news_rss
    (https://dsg-api.com/doc/soccer/get_news_rss/743/) is marked v2. So a client on "3.0" is calling a
    surface that still contains v2 operations, and DSG publishes nothing describing how or when those
    are brought forward.
deprecation:
  policy_url: null
  policy_published: false
  sunset_header: false
  deprecation_header: false
  deprecated_operations: []
  note: >-
    No deprecation policy, no advance-notice commitment, and no RFC 8594 Sunset/Deprecation header
    support is documented. No operation in the reference is marked deprecated. Because nothing is
    published, no `Deprecation` pointer is emitted in apis.yml.
changelog:
  url: https://dsg-api.com/changelogs/
  public: false
  status: 200
  note: >-
    dsg-api.com carries a "Changelogs" item in its documentation navigation, but the page is not
    public. GET https://dsg-api.com/changelogs/ returns HTTP 200 whose body is byte-for-byte identical
    to https://dsg-api.com/introduction/ (182,107 bytes) - the changelog content is served only to a
    signed-in client. It is a soft-404 to an anonymous reader, so no ChangeLog artifact and no
    ChangeLog pointer is emitted; a pointer here would advertise a page the public cannot read.
    /packages/ behaves identically.
sla:
  url: null
  uptime_target: null
  published: false
  note: >-
    No SLA, uptime target or credit schedule is published. DSG markets "Round the Clock Technical
    Support" on https://datasportsgroup.com/products-api/ but attaches no contractual target to it.
status_page:
  url: null
  published: false
  note: >-
    No status page was found. Probed status.dsg-api.com, status.datasportsgroup.com and the standard
    hosted-status vendors; nothing resolves, and neither the docs nor the marketing site links one. No
    `StatusPage` pointer is emitted.
support:
  channels:
    - type: email
      value: sales@datasportsgroup.com
    - type: form
      value: https://datasportsgroup.com/contact/
    - type: phone
      value: '+49 1573 348 5626'
  note: Support and sales share the same contact surface; no developer-specific support channel,
    forum, or ticketing system is published.
data_freshness:
  last_updated_fields: true
  note: >-
    Rather than a lifecycle policy, DSG publishes freshness at the record level - most entity nodes
    (competition, season, match, team, people, venue) carry a `last_updated` field documented as
    "When record was last updated. Format YYYY-MM-DD HH:MM:SS in CET timezone." The delta operations
    (get_matches_updates, get_peoples_updates, get_deleted) are the supported way to track change.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com