View Categories

Import Usage by API

Table of Contents

Last verified with: 10.8.6.0

Overview #

LogiSense Billing supports importing usage through API as an alternative to sending a usage feed file.

This is valuable for businesses that want a more direct system-to-system integration model for usage delivery. Instead of generating a file, placing it in a monitored location, and waiting for file-based pickup, a source system can submit usage directly to the platform by API.

The most important thing to understand is that API import is not a separate usage model. It uses the same UDR Feed and Data Profile structure that file-based import uses. That means businesses can change the delivery mechanism without rebuilding how usage is mapped, normalized, mediated, and rated.

What API Usage Import Is #

API usage import is a way to send usage records directly into the LogiSense Billing import and mediation flow.

From a business perspective, this means:

  • the source system pushes usage instead of delivering a file,
  • the platform still applies the configured feed and profile logic,
  • and the imported usage continues through the same downstream mediation and rating process as file-delivered usage.

This is one of the key strengths of the capability. Businesses can adopt a more modern integration pattern while keeping the same pricing and mediation design they already use.

Why Use API Import Instead Of A Feed File #

API import is useful when a business wants tighter integration or more immediate delivery of usage into the billing platform.

Common reasons include:

  • reducing dependence on file creation and file-transfer processes,
  • supporting near-real-time or more frequent usage submission,
  • simplifying direct integration from an application or service platform,
  • and keeping the billing pipeline aligned with API-first architecture standards.

This can be especially useful when the source application already produces usage in memory or through services and does not naturally operate as a file-based system.

The Core Business Model #

At a business level, API import works like this:

  1. A UDR Feed is configured in LogiSense Billing.
  2. That feed references the Data Profile that defines how incoming usage should be interpreted.
  3. The source system sends usage to the API for that feed.
  4. The platform ingests the usage and processes it through the configured mediation path.
  5. The mediated usage continues into rating, bucketing, taxation, and billing according to the configured pricing model.

This is important because the API does not replace mediation design. It replaces the transport mechanism.

That means businesses still get all the value of reusable feed configuration, mapping, normalization, and pricing logic without requiring file delivery as the ingestion method.

Prerequisite: Configure The UDR Feed First #

Before usage can be imported by API, the corresponding UDR Feed and its Data Profile need to be configured.

That is a critical concept for customers to understand. The API import route does not define how the records should be interpreted on its own. It sends usage into a configured feed context.

This gives the business two major benefits:

  • consistent treatment of usage regardless of how it was delivered,
  • and reuse of existing mediation design rather than duplicating import logic for API traffic.

The Main API Submission Patterns #

The platform supports more than one API-based usage submission pattern.

Direct Raw Usage Submission #

The most direct pattern is to send usage to a specific UDR Feed by API.

In this model, the calling system submits a list of raw usage records tied to a configured feed. This works well when the business wants the API to behave like a file alternative, where each submitted record is effectively treated like a feed row delivered directly instead of through a file.

This pattern is available by:

  • UDR Feed ID,
  • or, in newer API versions, by API Feed Name.

Business value:

  • lets the source system address the intended feed directly,
  • supports cleaner integration when a stable API-facing feed name is preferred,
  • and preserves the existing feed configuration model.

Example request body for the raw file-style pattern:

{
  "data": [
    "2022-05-01T01:01:00.01,Unknown,4038675309,4038675345,648-688-4180,94,False,False,data_class,Data_1,2022-05-01T01:01:00.01"
  ]
}

In this pattern, each item in the data array is effectively one feed row submitted as a string. This is the closest API equivalent to sending a usage feed file row-by-row instead of as a file.

JSON Record Submission #

For JSON-based usage feeds, the platform also supports sending JSON usage records directly.

This is useful when the source system naturally emits structured JSON events rather than flat-file style records.

Business value:

  • aligns well with modern event-producing applications,
  • reduces transformation effort before submission,
  • and allows businesses to keep JSON-native usage delivery while still using the configured feed and profile logic.

Example request body for the JSON-record pattern:

{
  "Date": "2026-04-16T14:32:00Z",
  "UdrIdentifierTypeName": "Unknown",
  "OriginatingIdentifier": "acct-100045",
  "TerminatingIdentifier": "svc-api-gateway",
  "UdrUsageIdentifier": "evt-20260416-00012345",
  "Value": 1250,
  "UsageClassName": "API Requests",
  "UsageClassTypeName": "Requests",
  "Inbound": false,
  "PrimaryDataRow": 1,
  "Extensions": {
    "region": "us-east-1",
    "plan": "growth",
    "operation": "generateReport"
  }
}

The exact JSON structure depends on the configured UDR Feed and Data Profile, but a representative usage record can look like this.

This example shows the general idea:

  • Date identifies when the usage occurred,
  • OriginatingIdentifier and TerminatingIdentifier help identify what generated the usage and where it applies,
  • UdrUsageIdentifier provides a unique usage-event reference,
  • Value carries the measured amount,
  • UsageClassName and UsageClassTypeName help classify the usage for pricing,
  • and Extensions can carry additional values that a configured mediation design may use.

In practice, customers should treat this as an illustrative example rather than a universal schema. The valid fields and how they are interpreted are determined by the feed and profile configuration that the API import is targeting.

What Gets Submitted #

The exact content of the submitted usage depends on the configured UDR Feed and Data Profile.

That means the business does not design the import format only at the API route level. The expected record shape is still governed by the feed and profile configuration.

This is one of the most important reasons API import is operationally powerful. The ingestion channel can change, but the business logic for interpreting the usage does not have to.

Record Limits And Submission Size #

For direct API submission, the platform enforces practical request-size limits.

The current API import process supports up to 1,000 records in a single direct API request.

This matters for customers because it creates a natural operating model:

  • use API import for direct and frequent submission,
  • chunk large imports into manageable request sizes,
  • and avoid treating a single API call as an unlimited bulk-load container.

That pattern tends to be a better operational fit for scalable integrations anyway, especially when usage is being sent continuously or in frequent batches.

API Import Is Asynchronous #

Another important concept is that usage import by API is an asynchronous process.

The API call submits usage into the import pipeline and returns tracking information. The platform then continues processing the submitted usage through the import and mediation flow.

This is valuable because it decouples the source application from the full downstream billing workload. The calling system does not need to wait for mediation and rating to complete in the same request-response cycle.

That makes the integration more resilient and better suited to production-scale usage delivery.

Tracking And Auditability #

API usage import is not a black box.

The platform records request tracking and usage import history so the business can trace what was submitted and how the import performed.

This includes the ability to monitor usage import history with information such as:

  • the associated UDR Feed,
  • the related Data Profile,
  • the import start and end times,
  • imported record counts,
  • exception counts,
  • skipped-record counts,
  • duplicate counts,
  • and overall record totals.

This is important because operational confidence matters just as much as ingestion itself. Businesses need to know not only that usage was sent, but also what happened after submission.

Exception Visibility #

When usage import issues occur, the platform provides visibility into import exceptions tied to the usage import history.

That gives operations teams a way to investigate records that did not process cleanly instead of treating API submission as an all-or-nothing outcome.

This is especially useful for high-volume environments where some records may need review or reprocessing, but the entire integration should not be considered failed just because a subset of records requires attention.

Reprocessing Support #

The platform also supports reprocessing for usage import history.

From a business perspective, this matters because usage operations are not always perfect on the first pass. If an import has completed or failed and needs to be run again, the platform provides a reprocessing path rather than forcing the business to rebuild everything manually from scratch.

That gives operations teams a cleaner recovery model and improves trust in the import process as a production integration pattern.

How API Import Compares To File Import #

The best way to think about API import is:

  • file import is file-based transport into the mediation model,
  • API import is API-based transport into the same mediation model.

That distinction is important.

Businesses do not have to choose between:

  • rich mediation design,
  • and modern API integration.

They can have both.

This means a company can continue using:

  • feed-based mapping,
  • normalization rules,
  • mediation customizations,
  • identifier resolution,
  • and rating logic,

while simply changing how the usage arrives.

When API Import Is A Strong Fit #

API usage import is often a strong fit when:

  • the source system already exposes usage through services or events,
  • usage needs to be sent more frequently than file exchange makes practical,
  • a business wants to reduce operational reliance on file-transfer infrastructure,
  • or an API-first integration model is preferred by the customer or implementation team.

It is especially attractive when the organization wants the control and reuse of feed-based mediation without the overhead of file handling.

When File Import May Still Be The Better Fit #

File import can still be the right choice in some environments.

For example, file-based delivery may still be preferable when:

  • the upstream source naturally produces flat files,
  • very large bulk export cycles are already operationally established,
  • or the surrounding organization is optimized around scheduled file exchange processes.

This is not a question of one model being universally better. It is about choosing the transport model that best fits the upstream operating environment while preserving the downstream billing design.

Business Benefits Of API Usage Import #

The business value of API usage import includes:

  • more direct integration between source systems and billing,
  • less dependency on file-transfer operations,
  • faster or more frequent usage delivery,
  • reuse of existing UDR Feed and Data Profile configuration,
  • continued mediation and pricing flexibility,
  • operational tracking and exception visibility,
  • and a cleaner fit for API-first architecture strategies.

That combination is powerful because it modernizes the ingestion path without forcing a redesign of the pricing and mediation framework.

Practical Positioning #

For most customers, the clearest way to position API usage import is:

“Use API import when you want to deliver usage directly from an application or integration layer, but still want LogiSense Billing to interpret and rate that usage through your configured feed and mediation model.”

That is the real strength of the feature. It gives businesses an API-native transport option while preserving all of the downstream billing flexibility they already rely on.

Summary #

Importing usage by API in LogiSense Billing is a modern alternative to data feed file delivery.

It allows usage to be sent directly into a configured UDR Feed, continues through the same mediation and rating model used by file import, and gives businesses strong operational visibility through request tracking, import history, exception handling, and reprocessing support.

For customers that want a more direct system-to-system integration model without giving up mediation reuse and pricing flexibility, API usage import is a strong option.