API Reference
中文

Activity Status API (Recommended)

The Activity Status API is a key functionality of the TD system aimed at ensuring the accuracy and timeliness of retrieving user identity information.

Through the Activity Status API, we are able to accurately identify more cunning fraudsters who cleverly use normal identities and behaviors to evade detection at critical business checkpoints, thereby deceiving the system. Relying solely on individual business behaviors often proves difficult in revealing the true intentions of fraudsters.

Additionally, the application of the Activity Status API enhances our ability to accurately identify occasional abnormal behaviors of legitimate users, thus reducing false positive rates and improving activity conversion rates. We perform seamless data reporting on users at regular business checkpoints and make decisions at critical business checkpoints. This design helps minimize user interference and enhances user experience.

Through the Activity Status API, we ensure that the TD system consistently receives the latest user identity information, thereby enhancing system security and reliability.

API Format

Base URL

API

URLRequest MethodsContent-TypeOutput FormatCharacter Set
api-base-url?partner_code=xxx&partner_key=xxxPOSTapplication/jsonJSONUTF-8

example: https://sg-event.apitd.net/activity/v3?partner_code=test_code&partner_key=test_key

Authentication
ParameterTypeDescriptionRequired/OptionalNotes
partner_codeStringPartner Coderequiredassigned by TD
partner_keyStringPartner Keyrequiredassigned by TD

Request

A complete request parameter typically consists of two parts:

  1. Basic Parameter: These fields contain fundamental information related to the request itself, aiming to ensure the validity and security of the request.
  2. Event Parameter: These fields are related to the activity status, such as marketing, get_coupon, and other events. Through these fields, we can pass data related to specific events, such as marketing information, coupon information, and so on.

By combining the basic fields and event fields, a complete set of request parameters is formed. This design allows us to effectively transmit and process event data related to the activity status, ensuring the accuracy and security of activity information.

Basic Parameter

ParameterTypeDescriptionRequired/OptionalNotes
channelStringChannel Identifierrequiredassigned by TD
session_idStringSession IDrequiredThe session ID is a unique identifier assigned by the website server to a specific user during the visit, which is usually stored in the form of a cookie, form parameter, or URL
account_idStringAccount IDconditionally required: required when account registration/creation is finishednot required when the account doesn't exist
event_timeStringThe Actual Time of the EventrequiredISO 8601, format YYYY-MM-DDTHH:mm:ss.sssZ, example: 2021-10-12T14:20:50.521+07:00
event_typeStringEvent Typerequiredenumeration:
marketing
marketing_code
marketing_exchange
send_gift
get_coupon
withdraw
invite
sms
browse
activate
lookup
like
comment
favorite
terminalTerminalDevice Informationrequired
extExtExtended Fieldoptionalextended field registered in the TD system

Event Parameter

Our API design restricts each request to only involve data related to a single event. This means that you cannot simultaneously initiate multiple different event data requests, such as marketing and withdraw.

To ensure data accuracy and system reliability, we recommend that you send separate requests for each event, considering the independence of each event. By handling each event separately, we can better manage and track the data processing process, avoiding confusion and conflicts.

Adhering to this rule will help improve system performance and reliability, ensuring that each event is correctly processed. If you need to handle multiple different events simultaneously, we suggest sending separate requests for each event to ensure data integrity and consistency.

EventEvent TypeRequired/Optional
Marketingmarketingoptional (strongly recommended), but if marketing information have already been passed through the verification API, they should be ignored
MarketingCodemarketing_codeoptional (strongly recommended), but if code information have already been passed through the verification API, they should be ignored
MarketingExchangemarketing_exchangeoptional (strongly recommended), but if exchange information have already been passed through the verification API, they should be ignored
SendGiftsend_giftoptional (strongly recommended), but if gift information have already been passed through the verification API, they should be ignored
GetCouponget_couponoptional (strongly recommended), but if coupon information have already been passed through the verification API, they should be ignored
Withdrawwithdrawoptional (strongly recommended), but if withdraw information have already been passed through the verification API, they should be ignored
Inviteinviteoptional (strongly recommended), but if invite information have already been passed through the verification API, they should be ignored
SMSsmsoptional (strongly recommended), but if sms information have already been passed through the verification API, they should be ignored
Browsebrowseoptional (strongly recommended), but if browse information have already been passed through the verification API, they should be ignored
Activateactivateoptional (strongly recommended), but if activate information have already been passed through the verification API, they should be ignored
Lookuplookupoptional (strongly recommended), but if lookup information have already been passed through the verification API, they should be ignored
Likelikeoptional (strongly recommended), but if like information have already been passed through the verification API, they should be ignored
Commentcommentoptional (strongly recommended), but if comment information have already been passed through the verification API, they should be ignored
Favoritefavoriteoptional (strongly recommended), but if favorite information have already been passed through the verification API, they should be ignored

Request Example

Let's take the example of a get_coupon event.

{
    "channel": "test",
    "session_id": "abc0123456789",
    "account_id": "123456789",
    "event_time": "2021-10-12T14:20:50.521+07:00",
    "event_type": "get_coupon",
    "terminal": {
        "black_box": "aGPH1658920283672ropYaFxT7",
        "ip": "210.20.10.33"
    },
    "ext": {
        "ext_book_id": "LFOUHOFHOHFNOUH",
        "ext_book_num": 10
    },
    "coupon": {
        "coupon_id": "NOHF08938",
        "coupon_name": "Limited Time Discount Coupon",
        "coupon_count": 1,
        "begin_time": 1596358039000,
        "expire_time": 1616358039000,
        "coupon_type": "discount",
        "coupon_rate": 0.85,
        "coupon_threshold": "10",
        "cash_back_amount": {
            "currency": "USD",
            "amount_local": 68,
            "amount_usd": 10,
            "amount_cny": 6.8
        }
    }
}

Response Parameter

ParameterTypeDescriptionRequired/OptionalNotes
codeIntegerAPI Status Coderequired
messageStringStatus Messagerequiredspecific abnormal reasons will be provided when the API is abnormal
sequence_idStringUnique ID of ResponserequiredA unique ID used to track each request

API Status Code

codeDescription
200Success
9001{Parameter} empty
9002{Parameter} check error
9003{Parameter} length or size exceeds 1024
9004Either black_box or ip exists
9200System error
9201Unknown error
9202Illegal Content-Type

Response Example

{
    "code": 200,
    "message": "",
    "sequence_id": "1648777165770866F82AC7F326307055"
}