The TMF Open API suite defines 26 standardised APIs covering the complete telecom BSS/OSS stack. Start here to understand how they fit together before diving into individual APIs or scenarios.
The provisioning spine — read this first
Every service delivery starts the same way:
Customer → Validate address → Qualify → Product order → Service order → Resource order + AAR → Activate → Inventory updated → Events fired
The right panel is your inspector — click any API chip, concept, or table cell throughout the app to see its payload and description. Use the learning mode bar above to switch between Beginner (8 APIs, happy path), Architect (all 26 APIs, branching), and Payload (full JSON inspector).
Customer → Validate address → Qualify → Product order → Service order → Resource order + AAR → Activate → Inventory updated → Events fired
The right panel is your inspector — click any API chip, concept, or table cell throughout the app to see its payload and description. Use the learning mode bar above to switch between Beginner (8 APIs, happy path), Architect (all 26 APIs, branching), and Payload (full JSON inspector).
ID traceability — the golden thread
Every entity in the TMF stack is linked by IDs that form a traceable chain from customer journey to network resource.
journeyId→
productOrderId→
serviceOrderId→
resourceOrderId→
serviceId (CFS)→
serviceId (RFS)→
resourceId ×5→
correlationId threads all events
🔀
Happy path swimlane
End-to-end animated flow
📊
Lifecycle states
All 8 entity state machines
📖
Glossary
All TMF terms defined
▶ Guided video tour — 42 steps · 10 chapters
Provisioning flow · Failure flows · All artifacts · TMF688 events
TMF622 vs TMF641 — the most common confusioncorrection
TMF622 — Product Order
POST /productOrder · @type: ProductOrderCommercial order placed by the customer.
References a product offering.
Created by BSS / order management.
Contains delivery address, appointment, billing account.
TMF641 — Service Order (SOLM)
POST /serviceOrder · @type: ServiceOrderTechnical fulfilment order raised by Orchestrator.
References CFS + RFS service specifications.
Contains decomposition items + serviceDirective.
Links back to TMF622 via
productOrderRef.
The confusion arose because older TMF documentation used the term "service order" loosely for both. In the current standard: TMF622 = what the customer ordered commercially, TMF641 = how the network fulfils it technically. They are always separate API calls.
Speed:
New provision — GPON FTTH
The happy path end-to-end, showing which system is responsible at each step. Click any step to inspect its payload in the inspector panel.
Reading the swimlane
• Each row is a system actor — the entity responsible for that step
• Each chip is an API call — click to inspect the payload
• The Orchestrator row is the hidden engine between BSS and network
• Arrows (→) show the sequence within each lane
Key insight: The Orchestrator is the critical hidden component — it sits between Channel/BSS and SILM/RILM but is not itself a TMF API. It reads decomposition rules from the Service Catalog and drives the entire order-to-activate flow.
Valid states and transitions for each core TMF entity. Click any state pill to see its meaning and what triggers the transition.
State legend
acknowledged / new
inProgress / processing
held / pending
active / completed
done / resolved
failed / cancelled
terminated / closed
reserved
| Entity (API) | Initial | In-flight | Blocked | Success | Failure | End of life | Notes |
|---|
Order states vs service states — the critical distinction: Order states (acknowledged → inProgress → completed) describe the work being done. Service states (inactive → active → terminated) describe the thing that exists. A service order can be completed while the service is still inactive if activation is asynchronous.
One customer request fans out into a chain of linked IDs. Click any node to see the entity payload and understand what system owns it.
ID chain — Jane Smith GPON FTTH provision
Ownership / system-of-record matrix
Who creates, updates, and is authoritative for each entity.
| Entity | Created by | Updated by | Authoritative source | Observed via |
|---|
A single
correlationId threads through every TMF688 event fired during a provisioning flow — from the shopping cart checkout all the way to the usage record. This is what enables end-to-end traceability across all 26 APIs.
correlationId:
so-2026-00789
22 events
20 architectural concepts that complete the TMF model beyond the 26 APIs.
Three CFS subtypes sit at the heart of the service model.
TMF688 is the nervous system. Every state change fires a typed event with a
correlationId.The causal chain: a command triggers a state change which fires an event which triggers a subscriber reaction. Understanding this chain is essential for debugging and building reactive OSS systems.
Real deployments diverge from the happy path. Click a card to inspect the divergence steps and which APIs are involved.
Four error-handling policies govern how the architecture responds to failures. Understanding which policy applies in which situation is critical for operations teams.
Policy decision matrix
| Failure scenario | Default policy | Rationale |
|---|
v style="font-size:12px;color:var(--tx2);margin-bottom:10px;line-height:1.7;">Three sequential gates must pass before a product order can be submitted. Each gate is progressively more expensive to run — fast checks first, deep network queries last.
Qualification rejection payloads — real failure codes
TMF645 unqualified response — OLT capacity exhausted
{\n "qualificationItemResult": "unqualified",\n "eligibilityUnavailabilityReason": [{\n "code": "TECH-001",\n "label": "OLT capacity exhausted",\n "technicalReason": "OLT-EAST-TOR-001 PON port 1/4/12 at 32/32 ONT capacity. No available ports on this splitter.",\n "suggestedAction": "Assign to adjacent OLT-EAST-TOR-002 or waitlist"\n }],\n "alternateServiceProposal": [{\n "serviceSpecification": {"name":"VDSL2 100Mbps Residential"},\n "alternateServiceProposalReason": "Next best available access technology at this address"\n }]\n}
TMF645 unqualified — optical budget exceeded
{\n "qualificationItemResult": "unqualified",\n "eligibilityUnavailabilityReason": [{\n "code": "TECH-002",\n "label": "Optical budget exceeded",\n "technicalReason": "Estimated path loss 31.2 dB exceeds maximum allowed 28.0 dB. Drop cable length 180m on G.652D fibre is beyond GPON budget.",\n "suggestedAction": "Install inline optical amplifier or re-route via closer splitter SPLIT-MAPLE-AVE-02"\n }]\n}
TMF679 ineligible — commercial rules
{\n "qualificationItemResult": "ineligible",\n "eligibilityUnavailabilityReason": [{\n "code": "COMM-003",\n "label": "Customer segment mismatch",\n "technicalReason": "Product po-gpon-ftth-business requires customerSegment=enterprise. Customer cust-56789 is segment=residential.",\n "suggestedAction": "Offer po-gpon-ftth-001 (residential) instead"\n }]\n}
A modify order triggers a diff engine that compares the current view (read from SILM) against the target view (declared in the order). Only changed fields generate resource order items.
Diff engine — GPON 1Gbps → XGS-PON 2Gbps upgrade
| Field | Current value | Target value | Change type | Resource Order Item raised? |
|---|
What gets patched vs recreated in RILM
Released (old resources freed)
res-inst-olt-port-04-12 (GPON 1/4/12) → usageState: idle
res-inst-ont-hwtc-a1b2 (EG8145V5) → usageState: idle
res-inst-ont-hwtc-a1b2 (EG8145V5) → usageState: idle
Created (new resources assigned)
res-inst-olt-xgspon-05-04 (XGS-PON 1/5/4) → usageState: inUse
res-inst-ont-hwtc-b9c8 (EG8247H5) → usageState: inUse
res-inst-ont-hwtc-b9c8 (EG8247H5) → usageState: inUse
VLAN pair (2042/100), fiber drop, BNG session — unchanged. No resource order items raised. No network churn.
Order state during held (field ONT swap required)
acknowledged→
inProgress→
held (field visit)→
inProgress→
completed
The order moves to held when a TMF724 appointment is required for the physical ONT swap. It returns to inProgress when the field technician confirms the swap via work order closure.
All 34 API payloads for the GPON FTTH fiber provisioning scenario. Click any row to inspect the full JSON in the right panel. All payloads use the same customer (Jane Smith, 42 Maple Ave, Toronto) and service instance for consistency.
Fiber scenario IDs:
Customer:
cust-56789 ·
ProductOrder: po-ord-2026-00789 ·
ServiceOrder: so-2026-00789 ·
ResourceOrder: ro-2026-00321 ·
CFS: svc-cfs-gpon-00456 ·
OLT port: 1/4/12 ·
ONT serial: HWTC-A1B2C3D4 ·
C-VLAN: 2042
30 TMF-specific terms with plain-language definitions. Filter by typing in the search box.