TM Forum integration sandbox

Mock the telecom action.
Keep delivery moving.

A focused mock service for CRM teams integrating against TM Forum actions. Shape requests, reproduce scenarios, and validate behavior before upstream systems are ready.

Database-configured Contract-shaped PostgreSQL-backed
Live example
POST /mock/billing/tmf666/createBillingAccount
{
  "name": "ACME billing",
  "accountType": "Consumer"
}
201 Created
{
  "id": "billing-account-42",
  "state": "Active",
  "confirmation": { ... }
}
Response generated in-process24 ms
8configured systems
33active mock rules
100safe items per response
0arbitrary code paths
Why TMF Mock

Built for the integration gap.

When CRM work is ready before billing, inventory, or orchestration environments are stable, TMF Mock keeps the contract testable. Every response is driven by a reviewable database formula—not application code hidden behind a bespoke stub.

01

Mirror the contract

Match real methods and TMF-style paths, then copy meaningful request data into the response.

02

Control the scenario

Generate IDs, MSISDNs, headers, statuses, repeated items, and deliberate latency from configuration.

03

Stay inspectable

List active rule metadata at runtime and keep the source of every behavior in version control.

Configured now

Systems on the wire

The homepage reads the same PostgreSQL records as the dispatcher, so the catalogue stays aligned with what the service can actually return.

Route catalogue

Small surface. Clear behavior.

View machine-readable rules ↗
MethodPrimary routeSystemStatus
POST /billingAccount billing 201
POST /product billing 201
GET /product/:productId billing 200
PATCH /product/:productId billing 200
POST /productOrder billing 201
GET /resource msisdn-repository 200
POST /reservation msisdn-repository 201
PATCH /reservation/:reservationId msisdn-repository 200
GET /tmf622/productOrder order-management 200
POST /productOrder order-management 201
GET /tmf622/productOrder/:id order-management 200
PATCH /tmf622/productOrder/:id order-management 200
DELETE /tmf622/productOrder/:id order-management 204
GET /tmf622/cancelProductOrder order-management 200
POST /tmf622/cancelProductOrder order-management 201
GET /tmf622/cancelProductOrder/:id order-management 200
POST /tmf622/hub order-management 201
DELETE /tmf622/hub/:id order-management 204
POST /serviceOrder service-order 201
GET /serviceOrder/:serviceOrderId service-order 200
POST /cancelServiceOrder service-order 201
POST /service charging 201
POST /checkProductStock stock-management 201
GET /checkProductStock/:checkProductStockId stock-management 200
POST /reserveProductStock stock-management 201
GET /reserveProductStock/:reserveProductStockId stock-management 200
POST /adjustProductStock stock-management 201
POST /shippingOrder shipping 201
GET /shippingOrder/:shippingOrderId shipping 200
PATCH /shippingOrder/:shippingOrderId shipping 200
POST /trackings shipment-tracking 201
GET /trackings shipment-tracking 200
GET /trackings/:trackingId shipment-tracking 200
Three ways in

Use the routing style that fits the environment.

Production-like subdomains, explicit local paths, and a request header all resolve to the same ordered rule engine.

  1. 01
    System subdomainhttps://billing.tmfmock.com/tmf666/createBillingAccount
  2. 02
    Local fallback path/mock/billing/tmf666/...
  3. 03
    Explicit request headerX-TMF-System: billing

Ready when the real system isn’t.

Point your CRM flow at a predictable contract.

Inspect the rules ↗