SportAPI Documentation
EN
C Product documentationCoupon API
v1
Service & pricing ↗ Get access ↗
Coupon API / Changelog

Changelog

This page lists changes to the public Client API contract. New entries are added at the top and published together with the corresponding OpenAPI update.

1.2.0 — July 31, 2026

  • New POST /api/partner/login distinguishes invalid credentials (1003), a disabled account (1004), expired access (1006), and an exhausted balance (1007). Legacy login preserves the common code 99.
  • Coupon creation atomically deducts the amount from the client account balance. With multi = true, the amount of every single created is deducted. An insufficient balance returns 507 and creates no partial data.
  • settlement_reason_code and settlement_reason were added to bets in the complete model and callbacks. They provide a stable code and explanatory text for the reason for settlement or return.

1.1.2 — July 30, 2026

  • Compatible POST /bet/place preserves the legacy feed-validation error contract: common error_code = 501 and a direct array of reasons in body.
  • change_type is definitively specified as 1, 2, or null.
  • String values increase and decrease are not used.

1.1.1 — July 30, 2026

The calculate_date field was standardized: it is null before settlement and a Unix timestamp in milliseconds after settlement. The value 0 is no longer used.

1.1.0 — July 29, 2026

Fields opp_icon1 and opp_icon2 were added. They match team1_id and team2_id, respectively.

1.0.0 — July 25, 2026

  • The new /api/partner/** Client API was defined.
  • Compatible legacy routes were preserved.
  • Secure retrieval of the client’s own coupons was added.
  • The complete coupon model was added.
  • The signed HMAC-SHA256 callback was defined.
  • Public coupon_code was separated from the internal ID and represented as a 12-digit string.

Versioning Rules

Versions use the MAJOR.MINOR.PATCH format:

  • MAJOR — incompatible changes to the public contract;
  • MINOR — new backward-compatible capabilities;
  • PATCH — fixes and clarifications without intentional compatibility breaks.

Editorial text changes that do not alter API behavior do not require a separate API version.

To migrate from legacy routes, use the standalone Migrating from the Legacy API guide.