Live sandbox · free · no signup

Mock Telco API & TM Forum Open API Sandbox Build and test BSS/OSS integrations against TMF-compliant product catalog, quoting, ordering, inventory, billing and payment endpoints — without an operator environment.

A free, hosted mock telecom API for developers, system integrators and solution architects. Every endpoint speaks canonical TM Forum Open API, mirrors your request payloads, calculates real quote and order totals, and routes payment outcomes from the card details you send. Point your client at it and start integrating today.

Why use a mock telco API?

Telecom integration work has a chicken-and-egg problem: the BSS environment you need to develop against is usually the last thing to become available, and when it does arrive it is shared, rate-limited and full of data you are not allowed to touch. A telecom API sandbox removes that dependency. You get stable, realistic, TMF-shaped responses on day one, so front-office portals, partner integrations, CPQ flows and billing reconciliation can all be built and tested in parallel with the real platform.

This sandbox is built for the cases that usually block a team:

• Contract-first development — code against TMF620, TMF622 and TMF648 before any operator API exists.
• Error-path coverage — reproduce a 504 timeout or a 402 decline on demand instead of waiting for one in the wild.
• Payment integration — exercise approvals, declines, 3-D Secure challenges and fraud holds with deterministic test cards.
• Demos and training — show a full catalog-to-fulfilment journey without exposing a production system.
• CI pipelines — assert on response contracts in automated tests with no fixtures to maintain.

Supported TM Forum Open APIs

Every resource follows the canonical TMF model — @type discriminators, href self-links, relatedParty[], Money and TimePeriod structures — so clients written against a real operator's TMF gateway work here unchanged.

Get a token

Three demo clients ship with the sandbox: developer, demo and admin. No registration.

curl -X POST https://telco-mock-api.pages.dev/auth/token \
  -H 'Content-Type: application/json' \
  -d '{"clientId":"developer","clientSecret":"dev-sandbox-2026"}'

Call your first endpoint

curl -H "Authorization: Bearer $TOKEN" \
  https://telco-mock-api.pages.dev/tmf-api/productCatalogManagement/v4/productOffering

Real CPQ pricing, not canned JSON

Submit product offerings and quantities to the quote calculator and get a fully-priced TMF648 Quote back. Unit prices are resolved from the live catalogue, per-line discounts apply, and a 20% VAT is split across recurring and one-time subtotals. The order flow adds a 10% special communication tax on mobile lines, itemised separately. The arithmetic is deterministic — identical requests produce identical totals.

curl -X POST https://telco-mock-api.pages.dev/tmf-api/quoteManagement/v4/quote/calculate \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "customerId": "cust-1001",
    "currency": "TRY",
    "quoteItem": [
      { "productOfferingId": "offer-infinity-fiber", "quantity": 1 },
      { "productOfferingId": "offer-pro-mobile", "quantity": 2, "discountPercentage": 10 }
    ]
  }'

Payment test cards

The payment decision engine reads the card number, CVV and amount, then returns an approval, a decline with an ISO reason code, a 3-D Secure challenge or a fraud hold. First match wins. Raw card numbers are never echoed back — only the masked form and the last four digits.

Simulate failures with one header

Send X-Mock-Scenario on any request to force an error path without touching your client code. Every response body follows the TMF630 common error structure, so your error handling is exercised exactly as it would be against a real gateway.

curl -H "Authorization: Bearer $TOKEN" \
  -H "X-Mock-Scenario: timeout" \
  https://telco-mock-api.pages.dev/tmf-api/productCatalogManagement/v4/catalog

Frequently asked questions

What is a mock telco API?

A mock telco API is a stand-in server that speaks the same contracts as a real telecom BSS — product catalog, quoting, ordering, billing and payments — without any of the backing systems. You point your integration at it during development so you can build and test against realistic responses long before a real operator environment is available to you.

Which TM Forum Open APIs does this sandbox implement?

Thirteen specifications: TMF620 Product Catalog, TMF622 Product Ordering, TMF629 Customer Management, TMF637 Product Inventory, TMF640 Service Inventory, TMF648 Quote Management, TMF651 Agreement Management, TMF666 Billing Account, TMF676 Payment and Payment Method, and TMF678 Customer Bill — plus a reference-data surface and an engine-administration API. Errors follow the TMF630 common error structure.

Is it free, and do I need an account?

It is free and there is no signup. Three demo clients ship with the sandbox; call POST /auth/token with clientId 'developer' and clientSecret 'dev-sandbox-2026' to get a JWT that unlocks every endpoint for an hour.

Do the responses actually change based on my request?

Yes. This is not a static JSON file server. Request fields are mirrored into responses, quote and order totals are genuinely calculated from the catalogue price list with discounts and tax applied, and payment outcomes are routed by a decision engine reading the card number, CVV and amount. Two identical requests give identical totals; different requests give different answers.

How do I test error handling and failure paths?

Send the X-Mock-Scenario header on any request. Eleven values are accepted — not-found, validation-error, unauthorized, forbidden, conflict, payment-declined, insufficient-funds, timeout, server-error and service-unavailable — each returning the mapped HTTP status with a TMF630-shaped error body. Your client code does not change; only the header does.

Which test cards trigger declines and 3-D Secure?

A card ending in 0002 declines for insufficient funds, 0069 declines as an invalid card, and 0036 triggers a 3-D Secure challenge. A CVV of 000 fails CVV verification, any BIN starting with 9 returns a general decline, amounts above 10,000 are held for fraud review and amounts above 50,000 exceed the card limit. Anything else is approved.

Can I use it for load testing or in CI?

It is fine for functional and contract testing in CI pipelines. A fair-use policy of 100 requests per minute per client keeps the shared instance responsive, so it is not suited to load testing. For that, clone the repository and run your own instance — it deploys to Cloudflare Pages in a single command, or run it locally with npm run dev.

Is any of the data real?

None of it. There are no corporate identifiers, no real customer records, no PSP-specific fields and no operator-specific characteristic codes. Demo customers are obviously synthetic and demo email addresses use the reserved .invalid TLD. Card numbers are never persisted, and only the masked form and last four digits are ever returned.

Hit a bug? Something not behaving?

If an endpoint returns something unexpected, a response does not match the TMF spec, or you would like a scenario or field added — get in touch. Reports are welcome and usually get a quick turnaround.

• The request you sent (method, path, body) and the response you got back
• The X-Request-Id response header — it correlates the call
• Any X-Mock-Scenario header you were using

✉ merrt.topal@gmail.com