TMF622 Product Ordering Management API

This training covers the TMF622 Product Ordering Management API, equipping developers and integrators to implement product order creation, tracking, and management using TM Forum standards.

A digital instructor presents all 14 pages. Hold “Ask” at any point and ask out loud — the answer comes from this course. No sign-up needed.

28 minFree to watchDownloads

What you’ll learn

01TMF622 Product Ordering Management API: Overview and Role in TM Forum Open APIsWelcome. This course covers TMF622, the Product Ordering Management API, and its role in the TM Forum Open API family. By the end, you will understand how it fits into your ordering architecture and where it touches your integration work. TMF622 standardizes how product orders are placed, tracked, and managed. Orders flow between a customer and a provider, or between partner providers. Each order is built from catalog offerings defined in TMF620, carrying pricing, options, and market details. The stable version is five point zero, released on the eighth of May, 2026, and it has moved to OpenAPI three point zero. Version five also introduced requestedInitialState, which gives you explicit control over order submission. The key dependencies are TMF620 for catalog, TMF637 for inventory, and TMF641 for service ordering. Typical adopters include communication service providers modernizing their OSS and BSS, order management vendors, and wholesale integration teams. So keep this framing: TMF622 captures commercial intent and hands it cleanly to fulfillment. Next, we will look at why standardized product ordering matters.tmforum.org tmforum.org tmforum.org+22 min
02Why Standardized Product Ordering MattersLet's talk about why standardized product ordering matters. If every partner and every channel needs a bespoke ordering interface, integration costs climb and onboarding slows to a crawl. And when order semantics drift from one channel to the next, the same request can behave differently depending on where it originated. The TM Forum Open API program addresses this with over one hundred REST based, event driven, and domain specific APIs, backed by shared guidelines, specifications, and conformance test kits for members. The business case is straightforward: faster time to market and easier multi partner orchestration. Adoption is already broad, with more than one million Open API downloads as of early twenty twenty five. The practical takeaway is one canonical product order model that normalizes every channel into a single order manager. Next, we will look at product, service, and resource ordering, and where TMF622 fits.tmforum.org tmforum.org tmforum.org+22 min
03Product, Service, and Resource Ordering: Where TMF622 FitsLet's look at where TMF622 sits in the ordering stack. Telco order management runs across three layers: COM for the commercial order, SOM for services, and ROM for resources. TMF622 handles the commercial product offering. TMF641 targets Customer-Facing Services. And TMF652 covers network resources. Orders decompose top-down, driven by catalog rules. Completion then rolls back up, layer by layer. There is no one-to-one mapping between layers. A single 200 Mbps broadband item may become three service order items and seven or more resource items. Each layer owns its own order API, its own catalog, and its own inventory. In a B2B2C chain, product orders move between providers, and each provider sees only its own commercial view. So keep the layering explicit in your design reviews and integration plans.tmforum.org tsm-docs.datalite.cloud bssoss-academy.dev+21 min
04Core Resources: ProductOrder, ProductOrderItem, and ReferencesLet's look at the core resources that carry every product order. At the top is ProductOrder. It holds the technical identifiers, id and href, plus externalId for your own reference, category for business segmentation, and priority, where zero is the highest urgency and four is the lowest. It also carries state and the related dates. Around that order sit the context references: billingAccount, relatedParty, channel, agreement, quote, note, and orderRelationship. Then comes ProductOrderItem. Each item is a line in the order. It requires an id, usually a sequence such as zero one, zero two, and an action: add, modify, delete, or noChange. Optional fields include quantity, state, productOffering, product, itemPrice, itemTerm, and appointment. Inside the product, productCharacteristic captures customer choices as name and value pairs, for example TEL underscore MSISDN or downloadSpeed. One last piece: CancelProductOrder has its own task states, acknowledged, inProgress, done, and terminatedWithErrors. Next, we move into the Product Order Lifecycle and State Model.tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com github.com datamodel.tmforum.org+22 min
05Product Order Lifecycle and State ModelLet's move on to the product order lifecycle and its state model. In TMF six twenty-two, an order moves through a defined set of states: acknowledged, rejected, pending, held, inProgress, completed, failed, and partial. Acknowledged means the order passed basic validation. InProgress means delivery has started. Now here is the key point. The order state is derived from item states. If every item completes, the order completes. If some items succeed and others fail, the order lands in partial. Pending means we are waiting on the requester. Held means a provider-side issue has paused us. Partial is terminal and real, so decide early on compensation, resubmission, or customer contact. Watch these pitfalls: improvised per-channel states, starting billing at capture instead of completion, and stale state while SOM or ROM work runs. Use milestones and jeopardy alerts to flag slippage or a point of no return. Next, we cover API operations: CRUD, query parameters, and cancellation.tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com github.com+21 min
06API Operations: CRUD, Query Parameters, and CancellationLet's move on to the API operations themselves. At the center is the product order resource. You create an order with a POST to productOrder. You retrieve a single order, or a filtered list, with GET. Partial changes go through PATCH on productOrder with the order identifier, while DELETE is reserved for administration only, not normal business flow. On listing calls, two query parameters do a lot of work. The fields parameter selects which attributes you get back, and offset plus limit paginate the results. Use them both. Now, when you create an order, you choose the starting point. Acknowledged means it is submitted for processing. Draft is held so the requester can keep editing before submission. You control this with requestedInitialState. Cancellation is separate. It is a task resource, and you request it with a POST to cancelProductOrder. That resource runs its own state machine, so do not assume it mirrors the order lifecycle. Finally, design your integration around the expected HTTP outcomes. Expect two hundred one Created on successful order creation, and two hundred two Accepted where processing continues asynchronously. Then handle the full four hundred and five hundred error set gracefully. The key design point is this. Keep synchronous validation responses distinct from asynchronous fulfillment progress. Validation tells you the request was understood. Fulfillment progress arrives later, through events. That leads us into our next topic. Events, Hub Registration, and Event-Driven Integration.tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com github.com datamodel.tmforum.org+22 min
07Events, Hub Registration, and Event-Driven IntegrationNow let's look at how event-driven integration works in this API. To receive notifications, a client registers a callback by posting to the hub endpoint. The callback URI is mandatory. The query filter is optional, and it lets you narrow which events you receive. To stop, send a delete to the hub endpoint with the subscription identifier. Do this whenever a listener is decommissioned. On the product order side, expect events for create, state change, attribute value change, delete, and information required. You will also see milestone, jeopardy alert, and error message events. Cancel product order events follow the same pattern. On your side, implement a post listener endpoint per event type, using the TMF event envelope. A few best practices. Keep listeners idempotent, keyed on the event identifier, because duplicates do happen. Return a quick two hundred response and process asynchronously. Use HTTPS. And always unsubscribe cleanly. Next, we move into payload modeling and validation rules.github.com tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com tmforum.org+22 min
08Payload Modeling and Validation RulesLet us move into payload modeling and validation rules. At minimum, a product order needs at least one product order item, and each item requires an id and an action, such as add, modify, or delete. Within that item, product offering references the commercial offer from your catalog, while product characteristic captures the actual configuration the customer wants. Those characteristics are typed. String, Number, and Object types are selected using the at type discriminator, so String Characteristic for text values, Number Characteristic for numeric ones. For change orders, you either pass the full item or use extensions to signal just the delta. Be aware that the conformance tool kit enforces mandatory fields only. Realistic deployments need optional fields populated for downstream systems to function. When validation fails, errors follow the TMF six thirty pattern, using code, reason, message, status, and reference error. Keep those fields consistent across your integration. Next, we will look at integration patterns, covering COM, decomposition, and inventory synchronization.tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com github.com+22 min
09Integration Patterns: COM, Decomposition, and Inventory SynchronizationLet's look at the integration patterns that make product ordering work in practice. First, Commercial Order Management, or COM, owns the product order end to end. It normalizes every channel, whether portal, retail, or partner API, into one canonical product order over TMF622. Second, product to CFS decomposition is catalog driven. It can live inside COM or in a separate decomposition engine. The choice depends on how complex your bundles and modify orders are. Third, treat TMF622 as a stable integration contract, not a workflow engine. Keep orchestration logic inside the owning domain. Now, synchronization. Keep order submission, qualification checks, and catalog queries synchronous. Push fulfillment, activation, and inventory updates to asynchronous events. This reduces coupling and lets fulfillment scale independently. Product Inventory, TMF637, triggers billing from completed instances, not from order capture. That prevents billing for services that were never delivered. Finally, avoid three anti-patterns. Do not create synchronous inventory dependencies during fulfillment. Do not embed qualification logic inside ordering flows. And do not model internal systems directly on TMF schemas. Next, let's walk through a concrete example in Scenario 1: B2C Digital-Channel Ordering.tmforum.org tmforum.org tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com+12 min
10Scenario 1: B2C Digital-Channel OrderingLet's walk through our first scenario: business-to-consumer ordering through a digital channel. The customer confirms a plan in the app, and the confirmed quote is submitted as a product order using POST on the product order resource. The order manager assigns an order ID and moves the order to acknowledged. Next comes validation. Address qualification, credit and fraud checks, and duplicate detection all run here. In practice, most order fallout happens at this stage, so treat validation as the critical control point. Once validation passes, the order moves to inProgress, and service orders are issued downstream. The channel renders progress by subscribing to state-change events, so the app stays current without polling. Order item details live in productCharacteristic. That is where you carry customer configuration like speed, SIM type, and installation preference. On the channel side, backend-for-frontend APIs serve both the app and the web from one TMF622 interface, so you keep a single order model. A good reference is Orange Poland's Flex, which uses TM Forum Open APIs for digital ordering. The takeaway: one order model, validation up front, and events for progress. Now let's move to scenario two: business-to-business and enterprise ordering.tmforum.org tmforum.org tmforum.org+22 min
11Scenario 2: B2B and Enterprise OrderingNow let's look at Scenario 2: Business to business and enterprise ordering. An enterprise order is rarely one product. A single order might bundle broadband, static IP addresses, router rental, and applications. Each order item carries its own action: add, modify, delete, or no change. The category field separates enterprise from residential, and that distinction drives routing, service level agreements, and priority. For modify orders, read the current instance from TMF637, product inventory, and send only the delta downstream. Unchanged items pass as no change, which gives downstream systems the full bundle context while keeping the actual work minimal. For example, if a customer upgrades broadband speed and adds a static IP, only those two items flow to service order management. Approvals and contract terms map to hold points, such as pending or held. And for B2B exposure, keep a stable, versioned contract with backward compatibility. Next, Scenario 3: Wholesale and Partner Ordering.tmforum.org tmforum.org2 min
12Scenario 3: Wholesale and Partner OrderingNow let's look at scenario three: wholesale and partner ordering. The core principle here is that partners should see your product offerings and commercial terms, not your internal service decomposition. Keep your service catalog and resource catalog behind the boundary. This way, you can change how you implement services on your network without forcing partners to re-integrate. The same TMF622 product order contract can serve both retail and wholesale flows. You simply expose different offerings and pricing for each segment. Product orders can also flow provider to provider. A common pattern is termination validation, where the originating provider sends a product order and the receiving provider validates agreement and quantity before confirming. Another practical point is that your submit endpoint may differ from your event-receiving endpoint. Plan for distributed event routing so notifications reach the correct partner system. Finally, give partners clear version management so they can integrate on their own release cycles. Track a few KPIs: partner onboarding time, API versus manual order volume, and partner-reported error rates. Next, we move into governance, conformance, and version management.tmforum.org tsm-docs.datalite.cloud bssoss-academy.dev+21 min
13Governance, Conformance, and Version ManagementLet's close the loop on governance, conformance, and version management. Open API conformance is self-applied and self-tested. You run the Conformance Test Kit, then submit those results for formal validation by a TM Forum subject matter expert. TMF622 has an active CTK, and version five point zero added out-of-the-box proxy settings for corporate environments, which removes a common setup headache. One caution: the CTK validates mandatory properties only. Optional fields still matter to real customers, so implement the full entity model. Versioning follows semantic versioning. A major change breaks compatibility. A minor version preserves it. Only the major version appears in the endpoint URL. As a consumer, tolerate new minor-version fields and unknown event types instead of failing. And remember, aligning TMF622 with TMF620, TMF637, and TMF641 is the real governance task. Next, let's move to Key Takeaways and Adoption Roadmap.tmforum.org tmforum.org tmforum.org+22 min
14Key Takeaways and Adoption RoadmapLet's bring everything together and close out this course. The core message is simple. TMF six twenty-two standardizes how we capture, track, and complete a product order, but it only delivers that value on top of a well-modeled catalog. Three factors drive success: catalog alignment, disciplined state governance, and event-driven integration. For your first steps, inventory your existing interfaces, run the Conformance Test Kit, and pilot one scenario end to end. Remember the ordering API is built around the product offering, so your catalog must be in place before ordering can flow cleanly. Next, decide what you will standardize and what you will extend. Extensions are fine, but they must not breach conformance. Start by watching the CTK's mandatory properties, then honor the full entity model in real deployments. Finally, build in resilience. Use idempotent listeners that tolerate duplicate events, carry correlation identifiers across systems, and manage versions cleanly with semantic versioning, keeping a major version in the endpoint. If an event arrives out of order, your listener should still handle it safely. Thank you for walking through this with me. You now have a practical roadmap, so take one scenario, validate it early, and keep your catalog and your API aligned as you grow.tmforum.org tmforum.org tmforum.org+12 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

PDF handoutEvery slide page, ready to print or share.15 pages · 3.4 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.15 pages · 17.7 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.15 pages · 3.3 MBDownload

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.