Solace API and SDKs: Choosing a Messaging API by Language and Use

The Solace API family is a set of native messaging libraries, one or more per language, that connect applications to the Solace Event Broker over SMF, Solace’s own protocol. Solace documents APIs for C, .NET, Go, Java (the Java API, JCSMP and Java RTO), Jakarta Messaging and JMS, JavaScript, Node.js, Python and iOS (Solace Messaging APIs). They expose the broker’s full feature set, which open protocols such as MQTT and AMQP do not, at the price of tying the code to Solace. Spring, Quarkus and management APIs sit around them.

This page lists every API with its language and use case, explains how to choose, and covers the traps. It belongs under Solace protocols and APIs in the Solace cluster. The rename from PubSub+ in May 2025 renamed the APIs too (“Solace PubSub+ Messaging API for…” became “Solace Messaging API for…”), but many package names still say pubsubplus.

Every Solace API, by language and use case

API	Language	Solace’s description, in short	Typical use case
C API (CCSMP)	C, C++	Highest throughput, lowest latency, lowest CPU	Trading-style latency, embedded services, wrappers
.NET API	C# and .NET	Object-oriented managed wrapper over the C API	Windows services, .NET MES and line-side apps
JCSMP	Java	Classic object-oriented Java API, high throughput, low latency	Existing Java estates and most published samples
Java API	Java	High throughput using modern Java features and programming models	New Java services
Java RTO	Java	Low-latency JNI wrapper over the C API	Latency-critical Java where JNI is acceptable
JMS / Jakarta Messaging	Java	Standard JMS 1.1 functionality in javax and jakarta namespaces	Application servers, migrations from other JMS brokers
JavaScript API	JavaScript	Web and mobile web, SMF over WebSocket	Browser dashboards, operator screens
Node.js API	JavaScript	Server-side, event-based programming (npm solclientjs)	Node back ends, integration scripts
Python API	Python	Cloud and enterprise server applications (PyPI solace-pubsubplus)	Data engineering, analytics, AI services
Go API	Go	Cloud and enterprise server applications	Cloud-native services, tooling
iOS API	Objective-C, Swift	Native wrapper of the C API with iOS lifecycle integration	Native iPhone and iPad apps

Sources: Solace Messaging APIs; package versions as of 9 October 2026: Python solace-pubsubplus 1.11.0 on PyPI, Node.js solclientjs 10.18.3 on npm.

Feature coverage is broad but not identical. Partitioned queues, for example, are supported across JCSMP, JMS, C, Python, Go, .NET, JavaScript, REST, MQTT 5 and AMQP (Solace Community). Solace publishes a feature support matrix per API; check it for the specific features your design depends on.

Frameworks, tools and management APIs

Frameworks. Spring users get Spring Boot starters and the Spring Cloud Stream binder for Solace in the solace-spring-cloud project, so a Spring service can bind to Solace with configuration rather than API calls. A Quarkus extension covers Quarkus, and a MuleSoft connector covers Anypoint. For schemas, Solace’s Schema Registry ships Avro and JSON serialisers, with the Java SERDES released alongside the 10.28.0 Java APIs in August 2025 and a .NET JSON Schema SERDES in July 2026.

Management. SEMP, the Solace Element Management Protocol, is the REST management API (versions 1 and 2) behind the web UI, the CLI and the Terraform provider. The 2026 solace-broker-mcp server exposes 47 SEMP-based tools to AI assistants: 29 read-only and 18 write tools that are off by default.

Developer tools. SdkPerf for load testing, the Try-Me CLI and VS Code extension, Codelabs and getting-started code for every API in SolaceSamples.

The settings that matter more than the API

Choosing the library is the easy part. Three decisions inside the code decide whether a plant can trust it.

Direct or guaranteed delivery. Every Solace API can publish Direct messages, which are fast and at-most-once, or guaranteed messages, which the broker stores and the consumer acknowledges. A live dashboard can live with Direct. A quality hold, a batch record or an order to the ERP cannot. Decide per topic and write the decision down; the guaranteed messaging page explains the mechanics.

When to acknowledge. Acknowledge after the work is done and committed, not when the message arrives. An application that acknowledges first and then crashes has lost the message, and the broker cannot know.

Tracing. The broker generates OpenTelemetry spans natively on receive, enqueue, send, acknowledge and delete, and Solace publishes an OpenTelemetry Collector receiver to forward them to tools such as Jaeger, Datadog or Dynatrace (Solace distributed tracing). Instrumenting the client side as well means a delayed message can be followed from the line gateway to the consuming application, which shortens the “is it the network, the broker or the app?” argument during an incident.

How to choose a Solace API

A procedure that holds up in a design review:

1. Decide portability. Devices, packaged products and anything that may move to another broker should use an open protocol. See Solace MQTT and JMS, AMQP and REST.
2. Let the runtime choose. The team’s language and framework usually settle the rest.
3. In Java, choose deliberately. Spring teams should use the binder; application servers need JMS or Jakarta; greenfield code should start on the Java API unless a library or sample it depends on only exists for JCSMP.
4. Check the feature matrix for the features the design depends on, such as partitioned queues, replay or transactions.
5. Standardise wrappers. Write one thin internal library per language for connection settings, reconnect behaviour and logging, so twenty teams do not invent twenty variants.

An illustrative case. A plant’s line-side quality application is written in C#, the analytics team works in Python, and the operator dashboard runs in a browser. The C# application uses the .NET API with guaranteed messaging, the data scientists use the Python API to subscribe to site1/*/*/quality/>, and the dashboard uses the JavaScript API over secure WebSocket with direct messaging. Three APIs, one topic tree, and no translation code. Where those applications meet plant historians and SCADA, our plant data overview covers the other half of the picture.

Where it gets hard

• Reconnect and retry settings. Defaults differ by API. Set them explicitly and test a broker failover, or a client may give up after a few attempts.
• Acknowledgement mistakes. Acknowledging before processing loses messages; never acknowledging fills the queue. Both are common in first projects.
• Version drift. With eleven APIs and frequent releases, teams end up on many versions. Track them, and align with the broker’s long-term release.
• Package names. Search for pubsubplus as well as solace when auditing dependencies; the rename did not reach every package.
• Lock-in by convenience. Every Solace-specific feature used is a reason it will be harder to move. That can be the right trade; make it on purpose.

Related: the sibling Kafka integration page, the messaging model the APIs expose, and the Solace hub.