Help Center/ KooGallery/ Access Guide/ SaaS Access Guide V2.0 (New Products)/ KooGallery Open APIs/ APIs/ Pushing the Pay-per-Use Resource Usage (New)
Updated on 2024-08-20 GMT+08:00
View PDF
Share

Pushing the Pay-per-Use Resource Usage (New)

Description

After a customer purchases and uses pay-per-use resources in KooGallery, call this API to upload the SDRs of the customer. After obtaining the SDRs, KooGallery charges the customer for the usage.

URI

POST https://mkt-intl.myhuaweicloud.com/api/mkp-openapi-public/global/v1/isv/usage-data

If mkt-intl.myhuaweicloud.com is unavailable, try mkt.myhuaweicloud.cn.

1. Pay-per-use specification/package purchase and use

2. Stop-before-excess package purchase and use

Request Message

The following table describes the request parameters.

Request method: POST

Parameter

Mandatory

Type

Maximum Length

Description

signature

Yes

String

1,000

@Header

API signature (base64(hmacSHA256(Seller interconnection key,ts={ts}&nonce={nonce}&body={body})))

The body is signed after being sorted naturally.

ts

Yes

String

20

@Header

Unix timestamp when an interface request is sent, in milliseconds.

nonce

Yes

String

64

@Header

Security random number.

usage_records

Yes

List<UsagePushData>

1,000

SDR list. A list contains up to 1,000 UsagePushData records.
Table 1 UsagePushData

Parameter

Mandatory

Type

Maximum Length

Description

instance_id

Yes

String

64

Pay-per-use instance ID. Use the instance ID returned by the pay-per-use subscription interface.

record_time

Yes

String

17

Time when a usage record is generated (UTC). Format:

yyyyMMdd'T'HHmmss'Z'

begin_time

Yes

String

17

Metering start time (UTC). Format:

yyyyMMdd'T'HHmmss'Z'

end_time

Yes

String

17

Metering end time (UTC). Format:

yyyyMMdd'T'HHmmss'Z'

usage_value

Yes

Double(12,4)

20

Usage value. The value is a positive number containing up to four significant decimal places.

metering_sn

Yes

String

64

Unique SDR ID. A random code is recommended.

relate_pkg_instance

No

String

64

This parameter is mandatory in SDRs of stop-before-excess packages. The package instance ID needs to be transferred.

Example request:

POST {domain}/api/mkp-openapi-public/global/v1/isv/usage-data 
Content-Type:application/json 
nonce: 6c63c221-1f6b-4141-8ff4-22f5dfe82b65 
ts: 1709690865879 
signature: gikLsIgimIscagwSamClFJ1CFT4QprHSDHW...
{  
    "usage_records": [  
        {  
            "instance_id": "7f141bf1-aec8-4859-8323-fb3a8ad50721",  
            "record_time": "20220809T091000Z",  
            "begin_time": "20220809T080000Z",  
            "end_time": "20220809T090000Z",  
            "usage_value": "99", 
            "metering_sn": "6c75c177b5fe4b8cbb6fc2aa33facfcd"  
        },  
        {  
            "instance_id": "7f141bf1-aec8-4859-8323-fb3a8ad50721",   
            "record_time": "20220809T091000Z",  
            "begin_time": "20220809T080000Z",  
            "end_time": "20220809T090000Z",  
            "usage_value": "999", 
            "metering_sn": "6c75c177b5fe4b8cbb6fc2aa33facfcb" 
        }  
    ]  
}

1. During SDR upload, if SDR data is abnormal, no error is reported at the API layer. The backend periodically verifies and processes the uploaded data and generates available SDR data. If the backend fails to process the data, report the data again.

You can view abnormal data on the Transaction Management > Service Detail Records page of the Seller Console.

2. Requirements for the SDR report period:

  • Hourly billing

    Report SDRs at least once an hour. It is recommended that SDRs be reported within the first 15 minutes of the next hour after a customer uses the resources. For example, if the customer uses resources at 13:25, report SDRs between 14:00 and 14:15. In this way, the customer can be charged in time. Otherwise, the fee deduction will be delayed. If you cannot report SDRs in real time, report them within 2 hours after resource consumption.

  • Daily billing

    Report SDRs to KooGallery every hour. If you can only report SDRs once a day, report them from 00:00 to 00:15. SDRs must be reported before 01:00. Otherwise, the fee will be deducted from customers on the next day.

3. Requirements for reporting SDRs:

  • When a resource is not closed:
  • SDR start time (begin_time) ≥ Resource start time
  • SDR start time (begin_time) ≤ SDR end time (end_time) ≤ SDR report time
  • When a resource is closed:
  • SDR end time (end_time) ≤ Resource close time

4. The time in the reported SDRs is the UTC time.

5. If the values of begin_time and end_time in a record are the same and the record is reported for multiple times, only the first record is processed. SDRs are collected at 01:00 every day for daily billing and fifteenth minute of every hour for hourly billing. Once SDRs are collected and formal bills are generated, SDRs cannot be corrected.

Duplicate SDRs are regarded as abnormal. You can view abnormal data on the Transaction Management > Service Detail Records page of the Seller Console.

6. The usage push interface uses the instance ID returned by the pay-per-use subscription interface instead of that returned by the pay-per-use package subscription interface.

7. If multiple SDRs (carrying usage_value) of an instance (instance_id) are reported during an SDR period, that is, the start time (begin_time) and end time (end_time) of these SDRs are the same, the SDRs must be identified by different extended parameters (extend_params). Or, KooGallery returns a verification failure message.

Response Message

The following table describes the response parameters.

Parameter

Mandatory

Type

Maximum Length

Description

error_code

Yes

String

6

Result code.

For details, see Result Codes.

error_msg

No

String

255

Result message.

data

No

AbnormalUsageDataInfo

   

Information about abnormal SDRs.
Table 2 AbnormalUsageDataInfo

Parameter

Mandatory

Type

Maximum Length

Description

abnormal_usage_data

Yes

List<AbnormalUsageData>

1,000

List of abnormal SDRs.
Table 3 AbnormalUsageData

Parameter

Mandatory

Type

Maximum Length

Description

metering_sn

Yes

String

64

Unique SDR ID.

error_code

Yes

String

16

SDR-level error code.

001: The instance does not exist.

002: Invalid time format.

003: Abnormal usage.

004: Missing SDR ID.

005: Duplicate SDR ID.

006: The product corresponding to the instance has been removed from the catalog.

007: The SDR has expired.

009: The instance does not match the seller.

010: Duplicate SDR.

011: Invalid SDR time range.

012: The instance is not a pay-per-use resource.

013: The instance resource status is abnormal.

014: The instance resource has been closed.

015: The SDR start time is earlier than the resource enabling time.

016: The instance is being enabled.

017: In the stop-before-excess scenario, relate_pkg_instance is empty.

018: In the stop-before-excess scenario, relate_pkg_instance is invalid or does not match instance_id.

error_msg

Yes

String

255

SDR error message.

Error codes

Table 4 AbnormalUsageData

HTTP Status Code

Error Code

Error Message

Description

200

MKT.0000

Success

Request successful.

500

94060001

System error!

Other internal errors.

401

94060002

Auth failed!

Input parameter verification failed.

Invalid value.

400

94060004

Param invalid

Invalid parameter.

The parameter is not defined by the API, there are more parameters than required, or a mandatory parameter is missing.

For example, a value is invalid or there is no instance ID.

400

94060005

Time format error

Incorrect time format.

400

94060006

TimeStamp invalid

Invalid timestamp.

401

94060007

Signature invalid

Signature verification fails.

400

94060008

Replay error

Request replay error.

500

94060009

Failed to report usage data

Report SDR failed.

401

94060010

isv status invalid

Invalid seller status.

200

94060999

Failed

SDR-level error information is returned. For details, see the example response.

If an error code starting with APIGW is returned after you call an API, rectify the fault by referring to the instructions provided in API Gateway Error Codes.

Example response:

  
{  
   "error_code":"MKT.0000",  
   "error_msg":"Success"  
} 
  
{ 
    "error_code": "94060999", 
    "error_msg": "Failed", 
    "data": { 
        "abnormal_usage_data": [ 
            { 
                "error_code": "005", 
                "error_msg": "METERING_SN_DUPLICATE", 
                "metering_sn": "6c75c177b5fe4b8cbb6fc2aa33facfcb" 
            } 
        ] 
    } 
}
Parent topic: APIs