Help Center/ KooGallery/ Access Guide/ SaaS Access Guide V1.0 (Existing Products)/ Interface Description/ Pay-per-Use Resource Usage Push/ Usage Push (Old)
Updated on 2024-05-09 GMT+08:00
View PDF
Share

Usage Push (Old)

Description

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

For details about how to obtain SDKs, see Calling APIs Through App Authentication.

You can obtain an AK/SK on the Access Keys page.

URI

POST https://mkt-intl.myhuaweicloud.com/rest/marketplace/v1/isv/usage-data (public network)

Request Message

The following table describes the request parameters.

Request method: POST

Parameter

Mandatory

Type

Maximum Length

Description

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.

product_id

Yes

String

64

ID of the product corresponding to the instance.

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.

relate_pkg_instance

No

String

64

Package instance ID. This parameter is required in SDRs of stop-before-excess packages.

Example request:

{ 
    "usage_records": [ 
        { 
            "instance_id": "7f141bf1-aec8-4859-8323-fb3a8ad50721", 
            "record_time": "20220809T091000Z", 
            "begin_time": "20220809T080000Z", 
            "end_time": "20220809T090000Z", 
            "usage_value": "99" 
        }, 
        { 
            "instance_id": "7f141bf1-aec8-4859-8323-fb3a8ad50721", 
            "record_time": "20220809T091000Z", 
            "begin_time": "20220809T080000Z", 
            "end_time": "20220809T090000Z", 
            "usage_value": "999" 
        } 
    ] 
}

1. During SDR upload, if SDR data is abnormal, no error is reported at the interface 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 one 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.

  • 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.

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 the following error codes.

error_msg

No

String

255

Result message.

The following table describes the error codes.

HTTP Status Code

Error Code

Error Message

Description

200

MKT.0000

Success.

Request successful.

500

MKT.0999

System internal error.

Other internal errors.

500

MKT.0100

Failure of input parameter

Input parameter verification failed.

Invalid value.

400

MKT.0101

Invalid parameter

Invalid parameter.

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

400

MKT.0102

Invalid body sign

Failed to verify the signature of the request body.

400

MKT.0199

Request parameter error

Incorrect request parameter.

401

MKT.0150

Illegal operation

You are trying to perform an unauthorized operation. For example, the product corresponding to instance_id is not released by the seller corresponding to the AK/SK.

401

MKT.0151

No authority

Insufficient permissions to access the API.

The token does not belong to a seller.

401

MKT.0154

Illegal token

Authentication failed.

Invalid token.

500

MKT.9001

Instance ID not found.

The instance ID does not exist. (This result code may be returned when the renewal, expiration, or resource release interface is called.)

500

MKT.9002

Invalid usage entities.

Invalid usage entities.

500

MKT.9003

Usage records extend size limit.

Too many records. Max. records: 1,000.

500

MKT.9004

Record beginTime extends Limit.

The start time exceeds the validity period (last 21 days).

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" 
}