API Reference
Products
Developers
API Reference
Contact Us

Usage Record Resource

Access Super SIM usage data

Super SIM's Usage Records API is currently in Public Beta . Some features are not yet implemented and others may be changed before the product is declared as Generally Available. Beta products are not covered by a KORE SLA . Learn more about beta product support.

To avoid ambiguity throughout this page, Sim (initial cap) refers to the Sim API resource. SIM (all caps) refers to the physical Subscriber Identity Module (that is, a SIM card) associated with a Sim resource.

A UsageRecord represents aggregated usage information over a specified period. Usage data can be filtered to show usage for a specific resource (e.g., Sims or Network) or grouped around a type of resource (e.g., Sims or Networks) where one record will be returned for each resource of that type for which usage occurred during the requested period. If you want to slice up your results by UTC day or UTC hour, you can control the granularity of the results.

All dates and times are presented in UTC .

Data Usage Processing

Usage events containing how much data your SIMs used are simultaneously handed off to the aggregation engine that powers the UsageRecords API and KORE's billing system. As a result, for each event handled, the usage in bytes will be reflected in the results from the UsageRecords API before the amount charged will be. Once the usage event has been processed by our billing system and the output billing event is received by the aggregation engine, it too will be reflected in the results via the data_total_billed property. All data billing events should be received and reflected in your results within 24 hours from when the usage occurred.

When generating critical spending reports, such as those you may need for monthly reporting for your business' operations, using this API, we recommend you wait at least 24 hours after the reported period ends to generate the report to allow usage events to be processed, charged, and reflected in your results.

API Authorization

Before you can make requests to this resource, you must have a valid bearer token. Review our API authorization guide to learn how to generate a token. Here's a curl example on how to define your access token in a header:

curl -X GET \
-H "Authorization: Bearer <YOUR_ACCESS_TOKEN>" \
'https://supersim.api.korewireless.com/v1/Sims'

The examples below do not show the required Authorization header due to a bug. We're working on fixing that. In the meantime, be sure to include that in all of your requests.

Read UsageRecord resources

Retrieve a list of UsageRecords over a specified period aggregated according to the specified granularity.

Usage information will be retained for 18 months , after which it will be deleted. Requests querying usage records older than 18 months will return an exception.

Which resources' usage data you receive will depend on the Account SID you provide to authorize your API access. If you authorize a request using a parent Account's credentials, the call will return only usage for resources belonging to that parent Account. SIMs belonging to the parent's child accounts, if it has any, will not be included. To request usage information for a given child account, authorize the request with that child account's credentials. Only that child account resources' data will be returned.

List UsageRecords

GEThttps://supersim.api.korewireless.com/v1/UsageRecords
Authorization
Query parameters
Response

OK

Headers
Body
usage_recordsarray of supersim.v1.usage_record (object)
metaobject
Request
const response = await fetch('https://supersim.api.korewireless.com/v1/UsageRecords', {
    method: 'GET',
    headers: {},
});
const data = await response.json();
Response
{
  "usage_records": [
    {
      "account_sid": "text",
      "sim_sid": "text",
      "network_sid": "text",
      "fleet_sid": "text",
      "iso_country": "text",
      "data_total_billed": 0,
      "billed_unit": "text"
    }
  ],
  "meta": {
    "first_page_url": "https://example.com",
    "key": "text",
    "next_page_url": "https://example.com",
    "previous_page_url": "https://example.com",
    "url": "https://example.com"
  }
}

Exclusive End Time

The end_time query parameter is exclusive. Usage that occurred before the end_time will be returned. For example to request all of the usage that occurred on February 20, 2022, you should use the following start_time and end_time request parameters in UTC format:

  • start_time: 2022-02-20T00:00:00Z

  • end_time: 2022-02-21T00:00:00Z

Single SIM Usage Requests Versus Account Usage Requests

Queries that are made for a single SIM by passing in a value for the Sim parameter require less computational work to aggregate the results than do requests which encompass all SIMs on your Account. Therefore queries for a single SIM may support longer ranges between the StartTime and EndTime parameters or may support queries made for any valid UTC timestamp as opposed to requiring the timestamps fall on a UTC hour or day boundary. Consequently, the sections below may be read in two ways, each depending on whether the request you are making is a Single SIM Usage Request or an Account Usage Request:

  • Single SIM Usage Requests — These are requests made with the Sim parameter set. They return UsageRecords representing usage only incurred by that Super SIM.

  • Account Usage Requests — These are requests made without any Sim parameter set. They return UsageRecords representing usage incurred by all Super SIMs in your Account.

Read filtered UsageRecords

You can filter UsageRecords to show usage for a specific resource such as a single SIM or Network.

The following query parameters will give you filtered UsageRecords:

  • Sim— Only show usage for the requested Sim resource. Can be passed in as either the Sim resource's Sid or UniqueName.

  • Fleet — Only show usage for Super SIMs that were assigned to this Fleet resource when the usage occurred. Can be passed in as either the Fleet resource's Sid or UniqueName.

  • Network — Only show usage on this cellular network. Only accepts the Network resource's Sid as FriendlyNames are subject to change.

  • IsoCountry — Only show usage incurred on cellular networks in this country. IsoCountry will be determined based on the IsoCountry of the Network resource on which the usage occurred.

When a filter is applied, the corresponding parameter on each UsageRecord will be populated with this value. For example, if you filter by a Sim resource, each UsageRecord returned will have the Sim resource's Sid in the SimSid property.

Multiple filters can be applied at once. For example, you can provide values for both Sim and Network to see the usage that a single Super SIM incurred on the requested cellular network.

Read UsageRecords over time

Each UsageRecord will represent the usage incurred over a period of time. The unit of time that each record represents depends on the Granularity query parameter. You can set the Granularity to either all, day, or hour. The default value is all.

The maximum allowed range between the StartTime and EndTime will vary depending on the Granularity you select and whether or not you are making a Single SIM Usage Request or an Account Usage Request. Further limitations on the allowed range may be imposed if you group your UsageRecords by a resource type as documented in the Group UsageRecords by resource type section below.

Read UsageRecords over time for a single SIM

Requests for the usage incurred by a single SIM must be made using the following rules for each Granularity:

  • all — One record will be returned representing the usage for the entire period queried after the StartTime and EndTime are transformed, if necessary, based on the logic below. Your StartTime and EndTime request parameters can be any valid UTC timestamp. The maximum allowed query period is 18 months .

    • If the period between your StartTime and EndTime is 24 hours or less, usage between the StartTime and EndTime (exclusive) you provided is returned.

    • For periods over 24 hours, usage for the entirety of the first and last hour is also included in the results. The StartTime is rounded down to the start of the UTC hour. The EndTime is rounded up to the next UTC hour.

  • day — One record will be returned for each UTC day between the StartTime and EndTime (exclusive). Your StartTime and EndTime request parameters must fall on midnight UTC (e.g., 2021-08-19T00:00:00Z) when Granularity=day or they will be rejected. The maximum allowed query period is 3 months .

  • hour — One record will be returned for each UTC hour between the StartTime and EndTime (exclusive). Your StartTime and EndTime request parameters must fall on a UTC hour (e.g., 2021-08-19T03:00:00Z) when Granularity=hour or they will be rejected. The maximum allowed query period is 31 days .

Read UsageRecords over time for an account

Requests for the usage incurred by all the Super SIMs in your Account must be made using the following rules for each Granularity:

  • all — One record will be returned representing the usage for the entire period between the StartTime and EndTime. Your StartTime and EndTime request parameters must fall on a UTC hour (e.g., 2021-08-19T03:00:00Z) when Granularity=all or they will be rejected. The maximum allowed query period is 18 months .

  • day — One record will be returned for each UTC day between the StartTime and EndTime (exclusive). Your StartTime and EndTime request parameters must fall on midnight UTC (e.g., 2021-08-19T00:00:00Z) when Granularity=day or they will be rejected. The maximum allowed query period is 3 months .

  • hour — One record will be returned for each UTC hour between the StartTime and EndTime (exclusive). Your StartTime and EndTime request parameters must fall on a UTC hour (e.g., 2021-08-19T03:00:00Z) when Granularity=hour or they will be rejected. The maximum allowed query period is 31 days .

If you were a early adopter of Super SIM (<Mid 2021) and integrated with this API you may be able to make API requests on non-UTC hour or day boundaries despite the above documentation saying that you should not be allowed to. If you observe that, it is likely that your account has non-standard permissions that were enabled to ensure your applications were not disrupted when that requirement was introduced. See Legacy Functionality below for more details.

Group UsageRecords by resource type

You can group UsageRecords around a type of resource (e.g., Sims or Networks). Each UsageRecord represents the aggregated usage incurred by an instance of the resource (e.g. a Sim or a Network) over a period of time.

Grouping your UsageRecords by SIM or by Fleet is currently in Private Beta . To request access to this functionality, contact your KORE Account Executive. Don't have one yet? Talk to a KORE sales specialist.

You can group your UsageRecords by the following resource types:

  • sim — Group usage by Super SIM. Each UsageRecord represents the usage incurred by a Sim resource over the UsageRecord's period. When grouping usage by Super SIM, the maximum allowed query period between the StartTime and EndTime is 31 days for all Granularity values. This functionality is in Private Beta and you may need it unlocked on your KORE Account.

  • fleet — Group usage by Fleet. Each UsageRecord represents the usage incurred by all the Super SIMs assigned to a Fleet resource when the usage occurred over the UsageRecord's period. This functionality is in Private Beta and you may need it unlocked on your KORE Account.

  • network — Group usage by Network. Each UsageRecord represents the usage incurred on a Network resource over the UsageRecord's period.

  • isoCountry — Group usage by country. Each UsageRecord represents the usage incurred on all of the Network resources in a country over the UsageRecord's period.

When a grouping is applied, the corresponding resource type's parameter on each UsageRecord will be populated with its identifier. For example, if you group by sim, each UsageRecord returned will have the Sim resource's Sid in the SimSid property.

You can filter grouped UsageRecords.

Read Grouped SIM UsageRecords

curl -X GET "https://supersim.api.korewireless.com/v1/UsageRecords?Group=sim&PageSize=20" -H "Authorization: Bearer <YOUR_AUTH_TOKEN>"

Read Grouped Fleet UsageRecords

curl -X GET "https://supersim.api.korewireless.com/v1/UsageRecords?Group=fleet&PageSize=20" -H "Authorization: Bearer <YOUR_AUTH_TOKEN>"

Read Grouped Network UsageRecords

curl -X GET "https://supersim.api.korewireless.com/v1/UsageRecords?Group=network&PageSize=20" -H "Authorization: Bearer <YOUR_AUTH_TOKEN>"

Read Grouped Country UsageRecords

curl -X GET "https://supersim.api.korewireless.com/v1/UsageRecords?Group=isoCountry&PageSize=20" -H "Authorization: Bearer <YOUR_AUTH_TOKEN>"

Legacy Functionality

If you were an early user of this API (<Mid 2021) and integrated into your application before it was publicly released, you may experience some slightly different behavior explained below due to having flags added to your account to ensure that your application was not disrupted by changing the expected response from the API when it was released.

Querying Account Usage With Non-UTC Hour or UTC Day Boundaries

If your account was identified as using this API before we implemented requirements that the StartTime and EndTime request parameters must fall on UTC day or hour boundaries depending on whether you were making a Single SIM Usage Request or an Account Usage Request and what Granularity was used, a flag was added to your account to continue to returning with a 200 response instead of throwing an exception to avoid disrupting your application. While we accepted your request, the timestamps used to request data from our systems was transformed as described below. In the future you may be contacted by our team asking you to adjust your application to ensure that data returned matches your request parameters and these unique account permissions can be removed.

Granularity hour and day

Your StartTime and EndTime values will be effectively rounded up to the next UTC hour or UTC day if the values provided do not fall on a UTC hour or UTC day boundary, respectively. For example, a request made with Granularity=day with StartTime=2021-07-01T00:30:00Z (July 1, 2021 12:30am UTC) and EndTime=2021-07-15T14:00:00Z (July 15, 2021 2:00pm UTC) will return results from the start of July 2nd through the end of July 15th . Similarly, a request made with Granularity=hour with StartTime=2021-07-01T00:30:00Z (12:30am UTC) and EndTime=2021-07-01T10:30:00Z (10:30am UTC) will return results for 1:00am UTC to 11:00am UTC .

To ensure that you receive the expected results, it is recommended that you make all requests with Granularity=hour with StartTime and EndTime values that fall on a UTC hour boundary (e.g., StartTime=2021-07-01T00:00:00Z) and all requests with Granularity=day with StartTime and EndTime values that fall on midnight UTC (e.g., EndTime=2021-07-16T00:00:00Z).

Granularity all

For Account Usage requests made with Granularity=all, if your StartTime and EndTime parameters are less than one hour apart, the results of all raw usage records where the measured period started between the StartTime and the EndTime will be aggregated. If your StartTime and EndTime parameters are more than one hour apart, then both the StartTime and EndTime parameters will be rounded up to the nearest UTC hour as described in the section above for Granularity=hour.

To ensure that you receive expected results, you should make all Account Usage requests with StartTime and EndTime values that fall on a UTC hour boundary.

Single SIM Usage Requests made with Granularity=all will correctly return the usage that occurred between any StartTime and EndTime up to the allowed range. This is a result of how these requests are processed — see Single SIM Usage Requests versus Account Usage Requests for details.

PreviousSettingsUpdates ResourceNextSMSCommand Resource

Last updated