What TMF Open API means for a billing platform

What the TM Forum Open APIs are

TM Forum is the industry association most telecom operators and BSS/OSS vendors belong to. Its Open API program publishes a catalogue of REST interface specifications, each numbered TMFxxx, describing how systems such as CRM, product catalogue, ordering, inventory and billing should talk to each other. Each specification ships with an OpenAPI (Swagger) definition, a Postman collection, a user guide and a conformance test kit (CTK), and the API definitions are published under Apache 2.0 unless stated otherwise.

The point is interchangeability. If a CRM calls GET /customerBill the same way against any vendor's billing engine, swapping the billing engine stops being a multi-year integration project. The same idea underpins TM Forum's Open Digital Architecture (ODA), which packages software into standard components that expose and consume these APIs.

TMF Open API billing: the APIs that matter

No single TMF API is "the billing API". Billing sits in the middle of the order-to-cash flow, so a billing platform ends up exposing or consuming several. These are the ones that come up in nearly every billing integration:

Two supporting pieces are worth knowing by name. TMF630 is the REST design guideline the other APIs follow (filtering, pagination, field selection, error format), and TMF688 covers event management: the publish/subscribe notifications that tell a CRM "a bill was created" without polling.

Versions: v4 vs v5

Most billing-relevant APIs have two versions in active use. Version 4, published around 2020–2021, is still widely deployed. TMF678, TMF666 and TMF629 all reached v5.0.0 in September 2023, and TM Forum published an updated TMF678 v5.0 release in May 2026. The v5 models are more consistent across APIs, but v4 and v5 payloads are not identical, so "we support TMF678" without a version number is only half an answer.

Usage changed the most. In January 2026 TM Forum uplifted the v4 Usage Management API to TMF635 Product Usage Management v5, renamed the /usage endpoint to /productUsage, and published the stable v5 release in March 2026. Older v4 integrations still use the previous name and endpoint.

Specifications, conformance test kits (CTKs) and sample code are also updated on their own schedules, so check the TM Forum directory page for the exact release a vendor tested against. If your CRM or partner portal already speaks v4, a v5-only billing system means an adapter in between, and the reverse is also true.

What a TMF678 call looks like

Here is the kind of request a CRM or self-care portal sends to show a customer their latest bills. It uses the standard TMF678 v5 resource; the values are illustrative.

GET /tmf-api/customerBillManagement/v5/customerBill?billingAccount.id=BA-10234&limit=3

[
  {
    "id": "CB-88412",
    "billNo": "INV-2026-11-0412",
    "billDate": "2026-11-01T00:00:00Z",
    "paymentDueDate": "2026-11-15T00:00:00Z",
    "state": "sent",
    "amountDue": { "unit": "ZAR", "value": 499.00 },
    "remainingAmount": { "unit": "ZAR", "value": 499.00 },
    "billingAccount": { "id": "BA-10234", "@referredType": "BillingAccount" },
    "@type": "CustomerBill"
  }
]

The CRM never needs to know how the bill was rated or which billing engine produced it. Usage moves the other way: mediation or a partner platform posts records to TMF635's /productUsage resource (v5), billing rates them, and the charges appear on the bill as appliedCustomerBillingRate items that the CRM can fetch through TMF678.

What "TMF compliant" can mean

The phrase covers a wide range. Roughly, vendors sit at one of four levels:

• Inspired by. The vendor's own API borrows TMF resource names but not the schemas. Good for marketing, little integration value.
• Mapped, with an adapter. The platform's API covers the same business entities, and a thin gateway presents them in TMF shape. Often the pragmatic route, but new fields and edge cases are mapped twice.
• Native. The platform's own API is the TMF API, and its screens and workflows use it internally.
• Certified. The implementation has passed TM Forum's conformance assessment, using the CTKs plus TM Forum's review.

Certification is voluntary, but it is common among larger BSS vendors; TM Forum lists every awarded certification in its Open API conformance directory. A certificate covers only the specific API and version tested, not the whole product, so check the directory entry rather than the badge.

When TMF APIs matter, and when they don't

Where they pay off

• Multi-vendor stacks. If CRM, ordering and billing come from different suppliers, a shared contract cuts integration work for each pair of systems.
• Replacing a legacy billing system. When surrounding systems already call TMF APIs, you can swap the billing engine underneath with less rework. This is common when moving off Oracle BRM.
• Partner and wholesale channels. MVNOs, resellers and enterprise customers increasingly expect standard bill and usage interfaces rather than bespoke file feeds.
• Procurement. Larger operators often list specific TMF APIs as mandatory in tenders.

Where they matter less

• Simple stacks. A single-product ISP or SaaS business with one CRM and one payment gateway may get more from a well-documented native API than from full TMF coverage.
• Billing logic. TMF APIs define the interface, not the rating. Two TMF678-certified systems can still prorate, discount and tax very differently.
• Batch flows. Bulk CDR files, nightly bill runs and ledger exports often still run on files or queues, even in TMF-oriented stacks.

Questions to ask a billing vendor

When a proposal says "TM Forum Open API compliant", these questions get you to the real answer quickly:

• Which APIs, exactly? Ask for the list by TMF number. TMF678 alone is not a billing integration.
• Which version of each? v4, v5, or both?
• Native, adapter or certified? If it's an adapter, who maintains it, and is it in the licence or support fee?
• Which resources and operations? For TMF678, is it read-only, or does it support on-demand bill creation and bill cycles too?
• Events? Does the platform publish notifications (bill created, payment received, balance low), or will you be polling?
• Extensions? How are your custom fields carried? TMF uses @type polymorphic extensions; check the vendor follows that rather than inventing its own.
• Evidence? A certification report, CTK results, or at least a Postman collection you can run against a trial instance.

How OpenBRM handles TMF Open APIs

We'll be direct about where OpenBRM sits on the scale above: it is mapped, not certified. OpenBRM bills both prepaid and postpaid customers. Its SOAP API exposes customers, products, invoices, payments, billing runs and mediation, and lets you read orders and subscriptions; a REST API handles customer records and product categories. Those APIs are organised around the same business entities as the TM Forum Open APIs, so an adapter layer can present them in TMF shape to an ODA-style stack while the billing core stays unchanged.

Because OpenBRM is open source billing software, you can do what proprietary vendors rarely allow before purchase: download it, call the SOAP API against your own CRM, and read the code behind them. The full list is on the integrations and APIs page. If your stack needs TMF-shaped endpoints, our implementation services team can scope the adapter against the exact APIs and versions your systems expect.

If you need certified TM Forum conformance out of the box, that is a reason to look at a certified commercial platform instead. Our Oracle BRM alternatives guide covers the options.

TMF Open API and billing: common questions

Sources

• TM Forum: Open API table
• TM Forum: TMF678 Customer Bill Management API v5.0.0
• TM Forum: Conformance certification process
• TM Forum: TMF678 Customer Bill Management API (current release)
• TM Forum: TMF635 Product Usage Management API v5.0
• TM Forum: TMF666 Account Management API v5.0.0
• TM Forum: Open API conformance certification directory
• TM Forum: ODA Component Conformance Certification