Cashout

In development. Cashout has not yet completed full testing. Do not use it in production until SportAPI separately confirms that it is ready.

The current endpoint and response format may change after development and testing are complete.

Current state

At present:

• there is no new /api/partner/** Cashout endpoint;
• only an experimental legacy API endpoint is available;
• the method calculates a possible Cashout value;
• the method does not sell the coupon;
• the method does not change the coupon status;
• the method does not debit or credit funds;
• a final Cashout confirmation contract has not yet been published.

The current method therefore cannot be used as a complete financial flow.

What the current method does

Experimental endpoint:

GET /coupons/cashout?coupon_code={coupon_code}

It returns a calculated estimate for an active coupon at the time of the request.

It only retrieves a calculated offer:

request estimate → response with calculated values

The current public contract does not include a subsequent API step that confirms the sale of the coupon.

Experimental request conditions

To retrieve an estimate:

• provide a client-account Bearer JWT;
• the coupon must belong to the JWT owner;
• the coupon must be active;
• coupon_code must consist of exactly 12 digits.

Store and submit the coupon code as a string to preserve leading zeros.

Request example

The following example is intended only for coordinated testing, not for production.

GET /coupons/cashout?coupon_code=000000000272 HTTP/1.1
Host: coupon-api.example.com
Authorization: Bearer <token>
Accept: application/json

BASE_URL="https://coupon-api.example.com"
TOKEN="<jwt-token>"
COUPON_CODE="000000000272"

curl --request GET \
  --url "$BASE_URL/coupons/cashout?coupon_code=$COUPON_CODE" \
  --header "Accept: application/json" \
  --header "Authorization: Bearer $TOKEN"

The partner receives the actual test BASE_URL from the manager.

Current experimental response

{
  "code": 1,
  "body": {
    "amount": 1,
    "old_coef": 2.5,
    "old_win": 2.5,
    "new_coef": 1.4,
    "new_win": 1.4,
    "events_data": [
      {
        "uuid": "912",
        "old_coef": 2.5,
        "new_coef": 1.4,
        "has_change": true
      }
    ]
  },
  "error_code": null,
  "error_message": null,
  "date": 1784970000000
}

Current response fields

Overall calculation

One bet in events_data

Field names and purposes reflect the current experimental implementation. Do not treat them as stable until the contract is confirmed.

Current endpoint errors

Example business error:

{
  "code": 0,
  "body": null,
  "error_code": 565,
  "error_message": "<Cashout unavailability description>",
  "date": 1784970000000
}

As with other legacy endpoints, a business error may be returned with HTTP 200. Check code and error_code.

What the response must not trigger

A successful current response does not mean that the coupon was sold.

After receiving new_win, do not automatically:

• treat Cashout as confirmed;
• change the coupon status to final;
• credit new_win to the user;
• stop waiting for regular coupon settlement;
• assume that the SportAPI Coupon Settlement System recorded a financial operation.

The method does not change the coupon or balance. It returns only a calculated value at the time of the request.

Why it must not be used in production

The following have not yet been confirmed as a stable public contract:

• final calculation formula;
• offer validity period;
• rules for value changes between requests;
• complete restrictions for different coupon types;
• coupon confirmation or sale flow;
• financial idempotency of the operation;
• final fields and error codes;
• new /api/partner/** endpoint.

The documentation will be updated after these rules are confirmed.

If the partner participates in testing

Testing must be agreed with the manager in advance.

We recommend:

1. using only the test environment;
2. not associating the response with a real user balance;
3. logging the request, coupon_code, and complete response;
4. checking results for different coupon types;
5. not building production code on the assumption that the current fields will remain unchanged;
6. discussing all discovered discrepancies separately with the manager.

What will be documented after development

After the feature is ready, the documentation must separately confirm:

• the recommended new API endpoint;
• retrieval of a current offer;
• offer validity period;
• Cashout confirmation;
• coupon status change;
• financial action;
• protection against repeated confirmation;
• complete error set;
• callback and polling behavior after Cashout.

Until these rules are published, treat the feature as unavailable for production integration.

Current-state checklist

• Cashout is in development.
• The feature has not yet completed full testing.
• No new /api/partner/** endpoint exists.
• The current /coupons/cashout is an experimental legacy endpoint.
• The method returns only a calculated estimate.
• The method does not sell the coupon or change the balance.
• The current contract may change.
• Production use is not recommended.

Next section: Single-bet integration.