In this month’s Product focus blog Product Manager Tom Kindl outlines a new feature licence available on Openmind Network’s Traffic Control platform.
The current situation
Configuration on a messaging core never sits still. New ESMEs are onboarded, operator routes change, business rules get tightened after a fraud event. None of those changes takes effect until it reaches the cluster configuration (CCONF) on Traffic Control 6000, Openmind’s messaging platform. For most customers, that means an external system such as a provisioning platform, an OSS/BSS workflow or a home-grown script pushing changes into CCONF through the SOAP API.
SOAP has done that job reliably for years. But it carries costs that are easy to overlook until you’re paying them at scale. Every call carries a full XML envelope. Changing a single attribute means sending, parsing and validating the entire object. Each integration needs a developer who knows the schema and the toolchain to work with it, and that knowledge is getting harder to find. And at throughput, the XML parsing load shows up as CPU you’d rather spend on message handling. For TC6000 customers, who need fast, flexible, automation of their messaging provisioning data, CCONF REST API offers an atomic, fast solution.
For operators consolidating onto OpenCore, or smaller operators trying to run a lean, automated core, that overhead is the difference between provisioning that keeps up with the business and provisioning that becomes a ticket queue.
What we built
The CCONF REST API is a REST/JSON interface to the TC6000 Cluster Configuration server. It sits alongside the existing Web UI, command-line/native API and SOAP API as a fourth way in, and it is built for automation from external applications.
Three things define it:
Partial operations. You can read or update a single field, a single row in a list, or a group of attributes, without touching the rest of the object. A PATCH sends only what changed. This is the core difference from SOAP, and it is where most of the performance gain comes from.
An OpenAPI specification. The API ships with an OpenAPI/Swagger definition, so client code can be generated in whatever language your integration team uses rather than hand-written against documentation.
The same security model. Authentication is JWT bearer token over HTTPS. Role-based access control is identical to the GUI and SOAP API, and configuration changes flow through the same audit trail (channel 2/15), SIEM CDRs and validators. Nothing about the security posture of the cluster changes because a new interface exists.
The API shares its HTTP setup with the GUI and SOAP, so there is no separate service to deploy or expose.
How it works
This section is for engineers and integrators. If that’s not you, skip to “What it means for you”.
Every configuration object in CCONF is addressed by a leafId (the object type, e.g. moebius_crb_operators) and an itemName (the specific instance, e.g. op_1003). The full path model looks like this:
/api/item/{leafId} list items in a leaf
/api/item/{leafId}/{itemName} one item
/api/item/{leafId}/{itemName}/{fieldName} one field or attribute group
/api/item/{leafId}/{itemName}/{listName}/{rowId} one row in a list attribute
Standard verbs apply: GET to read, POST to create, PUT to replace, DELETE to remove, and PATCH to partially update at item or list-row level.
A typical session starts with authentication:
POST /api/auth/login
{ “username”: “omn_admin”, “password”: “secure_password” }
200 OK
{ “token”: “eyJhbGciOi…”, “tokenType”: “Bearer” }
Reading a single attribute returns just that attribute:
GET /api/item/moebius_crb_operators/op_1003/common.desc
{ “fields”: [ { “name”: “common.desc”, “label”: “Description”, “value”: “desc 1” } ] }
And updating two fields on an operator, without sending the rest of the object:
PATCH /api/item/moebius_crb_operators/op_1003
{
“fields”: [
{ “name”: “common.desc”, “value”: “desc 4” },
{ “name”: “op_gw_rx.prof_fallback”, “value”: “true” }
]
}
204 No Content
The same pattern extends to list rows. PATCH /api/item/moebius_crb_operators/op_1003/op_gw_rx.gw_routes/0 updates the first gateway route on that operator and nothing else.
Benchmarks
We ran the REST and SOAP interfaces side by side on a TC6000 cluster with identical hardware allocation. Operator configuration workload, 10 TPS steady state unless stated.
| Metric | SOAP API | REST API |
| Peak throughput (uncapped) | 9 TPS | 172 TPS |
| Average latency | 325 ms | 12 ms |
| CPU utilisation | 100% | 5% |
| JVM young GC events | 23 | 1 |
The throughput difference is roughly 20x on operator configuration and 15x on ESME provisioning (~152 TPS vs ~10 TPS). Single-attribute reads, which under SOAP require parsing the full object, dropped from 179.5 ms to 10.2 ms. Sequential Store → Get → Store workflows completed 3.4x faster for ESME entities and 2.0x faster for operator entities.
The CPU and garbage-collection numbers are the ones operations teams should note. SOAP’s XML parsing allocates and discards heavy parser objects on every call, which at load shows up as GC thrashing. REST holds a flat, predictable memory profile.
What it means for you
The CCONF REST API applies to any TC6000 cluster deployment. It is delivered under a feature licence, available on demand, and enabled through the standard rolling upgrade procedure. There is no downtime and no migration: SOAP stays fully in operation, so existing integrations keep working and can be moved to REST on your own schedule.
In practice this means:
- Provisioning integrations that are faster to build, because code can be generated from the OpenAPI spec rather than written by hand.
- Configuration changes that take effect in milliseconds rather than hundreds of milliseconds, which matters when a business rule needs to change in response to a live fraud pattern.
- A lower compute footprint for config-heavy workloads, which on a consolidated or cloud-deployed core translates directly into hardware and power cost.
To enable it, contact your account manager or sales@openmindnetworks.com.
What’s next
A machine-readable, OpenAPI-defined interface is the prerequisite for AI-driven operations. Model Context Protocol (MCP) integrations consume OpenAPI schemas directly as tools, which means an AI agent can read and change cluster configuration the same way a provisioning system does. The REST API is the foundation we are building that on.
