API Reference Table

Consolidated reference covering all key TMF Open APIs by domain — catalog, ordering, inventory, assurance, billing, and party management.

TM Forum Open API Reference

This table provides a consolidated reference for the key TM Forum Open APIs used across BSS/OSS domains. APIs are grouped by capability area: Catalog (design-time definitions), Ordering (runtime fulfilment), Inventory (runtime state), Assurance (fault and quality management), Billing & Revenue, and Party & Customer Management.

Design-Time vs Runtime

Catalog APIs (TMF620/633/634) define what CAN exist — they are design-time. Ordering APIs (TMF622/641/652) create instances — they are runtime. Inventory APIs (TMF637/638/639) track what DOES exist — they are runtime state. Understanding this distinction is fundamental to using the right API at the right point in the lifecycle.

Catalog Management APIs

Catalog APIs — Design-Time Definitions

API	Name	Domain	Purpose	Key Entities
TMF620	Product Catalog Management	BSS	Manages what a telco sells — product offerings with pricing, eligibility, and channel rules	ProductOffering, ProductSpecification, ProductOfferingPrice
TMF633	Service Catalog Management	OSS	Manages CFS and RFS specifications — the service decomposition blueprints that drive fulfilment	ServiceSpecification, ServiceCandidate
TMF634	Resource Catalog Management	OSS	Manages physical and logical resource type definitions used by ROM for activation	ResourceSpecification, ResourceCandidate

The three catalogs form a decomposition chain: ProductSpecification (TMF620) → CFS ServiceSpecification (TMF633) → RFS ServiceSpecification (TMF633) → ResourceSpecification (TMF634). This chain tells the fulfilment system how to break a commercial product into technical service and resource actions.

Order Management APIs

Order APIs — Runtime Fulfilment

API	Name	Domain	Purpose	Key Entities
TMF622	Product Ordering	BSS (COM)	Captures commercial product orders from channels — the entry point for all fulfilment	ProductOrder, ProductOrderItem
TMF641	Service Ordering	OSS (SOM)	Manages service-level orders created by COM decomposition — orchestrates CFS/RFS fulfilment	ServiceOrder, ServiceOrderItem
TMF652	Resource Ordering	OSS (ROM)	Manages resource-level orders — allocates and configures physical/logical resources	ResourceOrder, ResourceOrderItem
TMF640	Service Activation & Configuration	OSS	Activates and configures services on the network — the southbound execution API	Service, ServiceCharacteristic

The order chain mirrors the catalog chain: TMF622 (product order) → TMF641 (service order) → TMF652 (resource order) → TMF640 (activation). Each step decomposes commercial intent into increasingly technical instructions.

Inventory Management APIs

Inventory APIs — Runtime State

API	Name	Domain	Purpose	Key Entities
TMF637	Product Inventory Management	BSS	Tracks what each customer owns — the installed base of active product instances	Product (instance)
TMF638	Service Inventory Management	OSS	Tracks active CFS/RFS instances — the connective tissue between commercial and technical domains	Service (instance)
TMF639	Resource Inventory Management	OSS	Tracks physical and logical resource instances — ports, VLANs, IP addresses, devices	Resource (instance)
TMF685	Resource Pool Management	OSS	Manages pools of allocatable resources (IP address blocks, VLAN ranges, port pools)	ResourcePool, Reservation

Inventory APIs record the output of successful fulfilment. The specification/instance pattern links them to catalogs: ProductSpecification (TMF620) → Product instance (TMF637), ServiceSpecification (TMF633) → Service instance (TMF638), ResourceSpecification (TMF634) → Resource instance (TMF639).

Assurance APIs

Assurance APIs — Fault & Quality Management

API	Name	Domain	Purpose	Key Entities
TMF621	Trouble Ticket Management	BSS + OSS	Manages customer fault reports and internal trouble tickets with lifecycle tracking	TroubleTicket, TroubleTicketRelationship
TMF656	Service Problem Management	OSS	Tracks service-level problems correlated from network alarms and customer reports	ServiceProblem
TMF657	Service Quality Management	OSS	Monitors service quality KPIs against SLA thresholds — proactive degradation detection	ServiceLevelObjective, ServiceLevelSpecification

Billing, Revenue & Party APIs

Billing, Revenue & Party Management

API	Name	Domain	Purpose	Key Entities
TMF678	Customer Bill Management	BSS	Retrieves and manages customer bills and billing accounts	CustomerBill, BillingAccount
TMF676	Payment Management	BSS	Manages payments, refunds, and payment methods	Payment, PaymentMethod
TMF666	Account Management	BSS	Manages customer accounts, billing accounts, and financial accounts	BillingAccount, FinancialAccount
TMF632	Party Management	BSS	Manages individuals and organisations — the core identity entities	Individual, Organization
TMF669	Party Role Management	BSS	Manages the roles parties play (customer, supplier, partner) in different contexts	PartyRole, Customer
TMF645	Service Qualification	OSS	Pre-order check: can a specific service be delivered at a specific location?	ServiceQualification, ServiceQualificationItem

How the APIs Connect

End-to-End API Chain: Order to Activation

Browse Catalog

TMF620

Channel queries TMF620 for available product offerings.

Place Order

TMF622

Channel submits a product order via TMF622.

Service Order

TMF641

COM decomposes into service-level tasks via TMF641.

Resource Order

TMF652

SOM creates resource orders via TMF652.

Activate

TMF640

ROM activates via TMF640. Inventories (637/638/639) updated.

Section 7.2 Key Takeaways

Catalog APIs (620/633/634) are design-time; ordering APIs (622/641/652) are runtime; inventory APIs (637/638/639) track state
The decomposition chain Product → CFS → RFS → Resource runs through both catalog and ordering APIs
Inventory APIs record the output of fulfilment — they are the source of truth for what exists
Assurance APIs (621/656/657) depend on accurate inventory data to correlate faults to customers
Conformance guarantees structural compatibility but not semantic interoperability — integration still requires business rule alignment