LockFlare Sonda — all 1,610 capabilities

HTTP / REST	GraphQL
GraphQL schema / introspection	gRPC
gRPC unary	gRPC server streaming
gRPC client streaming	gRPC bidirectional streaming
Interactive persistent gRPC streaming session	Keep gRPC stream open between messages
Send messages individually into an open gRPC stream	Receive gRPC messages individually as they arrive
Half-close client sending side	Continue receiving after client half-close
Explicit live-stream cancellation	Live sent / received gRPC event log
Expand individual live-stream messages	Live sent / received counters
gRPC response headers on live stream	gRPC trailers on live stream
Final gRPC status / code / message	Per-stream event sequence / history
Tree connection badge while gRPC stream is open	Close active gRPC stream from tree context menu
Batch execution remains available beside live streaming	Invalid outgoing message is rejected without closing stream
Open gRPC streams close on Workspace / account switch	gRPC reflection
.proto loading	WebSocket
Saved WebSocket messages	Native Socket.IO client
Socket.IO namespaces	Socket.IO auth payload
Socket.IO event ACKs	Socket.IO ACK round-trip timing
Socket.IO binary events	Socket.IO binary ACKs
SSE / Event Streams	SSE automatic reconnect
SSE Last-Event-ID	SSE retry semantics
MQTT	MQTT 3.1.1
MQTT 5	MQTT QoS 0 / 1 / 2
MQTT retained messages	MQTT wildcard subscriptions
MQTT 5 properties	MQTT response-topic handling
MQTT correlation data	MQTT client certificates over mqtts:// and wss://
STOMP over WebSocket	STOMP 1.2
STOMP 1.1 / 1.0 negotiation	STOMP CONNECT / CONNECTED
STOMP SUBSCRIBE / UNSUBSCRIBE	STOMP SEND / MESSAGE
STOMP ACK / NACK	STOMP auto / client / client-individual ack modes
STOMP RECEIPT handling	STOMP receipt round-trip timing
STOMP heartbeat negotiation	STOMP automatic heartbeat
Persistent STOMP subscriptions	Automatic STOMP resubscribe
STOMP ERROR frame interpretation	The transport chosen per gRPC call: native gRPC over HTTP/2, gRPC-Web or Connect
gRPC-Web through a gateway: unary and server-streaming calls, the status read from the trailer frame	The Connect protocol: unary and server-streaming calls, errors as JSON read into the answer
A pasted URL read as a gRPC target: the scheme says TLS, the path dropped	What came instead of gRPC said in words: a page, a 404, a server that speaks native only
MQTT reconnects on its own, its subscriptions made again	An MQTT unsubscribe the broker did not take is owed, and paid on the next connect

Kafka cluster connections from the bootstrap servers	Pure-Go Kafka client, no native libraries
TLS with your own certificate authorities	Self-signed lab clusters on request
Client certificates (mutual TLS) for every broker	SASL PLAIN
SASL SCRAM-SHA-256 and SCRAM-SHA-512	Topic list with partitions, leaders and in-sync replicas
Log start and end offsets per partition	Internal topics behind a toggle
Read a topic, one partition or every partition	Read from the end, the start, an offset or a point in time
Relative-time reads (for example, 15 minutes ago)	Reads join no consumer group and commit no offsets
Kept reads restart on every connect	Record stream with topic, partition, offset, key, value, headers and timestamp
JSON pretty-print and base64 for binary values	Produce records with a key, a value and headers
Produce by key or to a chosen partition	Every listener keeps its own watermark: history is never a trigger
A listener’s read grows with the topic: new partitions taken on

RabbitMQ brokers over AMQP 0-9-1	amqp:// and amqps:// with your own certificate authorities
Self-signed brokers on request	Client certificates (mutual TLS)
Connection named Sonda in the broker’s own UI	Consume with automatic acknowledgement
Acknowledge once the message is on screen	Hold mode: see messages without taking them
Prefetch limit per consume	Reject or dead-letter consumed messages
Get one message: peek and put back, or take	Publish to an exchange with a routing key
Every AMQP message property and custom headers	Publisher confirms on every publish
Mandatory publishing with the broker’s return reason	Stream tags: redelivered, returned, held, peeked, rejected, dead-lettered
Dead-letter reason and x-death count	Queues, exchanges and bindings listed with their counts
Queue inspection	Declare queues and exchanges
Bind and unbind queues	Purge a queue
Delete queues and exchanges	JSON pretty-print and base64 for binary bodies

NATS servers and clusters, one address or several	nats://, tls://, ws:// and wss://
TLS with your own certificate authorities	Client certificates (mutual TLS)
Self-signed servers on request	User and password, or a token
NKey seed or a .creds file	Connection name of your choice, Sonda by default
Custom inbox prefix for restricted accounts	JetStream domains for leaf nodes
Server name, version and cluster shown on connect	JetStream detected on connect, with the reason when it is missing
Automatic reconnect	Subscribe with * and > wildcards
Queue groups	Kept subscriptions and stream reads restart on every connect
Publish with headers and a reply subject	Request–reply: the first answer and how long it took
No responders reported when nobody listens	JetStream publish with the stream’s acknowledgement
Nats-Msg-Id for duplicate detection	Streams listed with what each one holds
Consumers listed with where each one is	Read a stream from new, all, the last, a sequence or a point in time
The last message of every subject	Relative-time reads (for example, 15 minutes ago)
Stream reads filtered by subject, wildcards allowed	Reads through ephemeral ordered consumers: no durable consumer moves
Get one stored message by sequence, or the last of a subject	Key/Value buckets listed
Keys listed, with * and > filters	A key’s value and its whole history
Put a value and see its revision	Delete a key with its history kept, or purge it
Watch a bucket or a key pattern live	JSON pretty-print and base64 for binary data

AMQP 1.0 brokers: Azure Service Bus and Event Hubs, ActiveMQ Artemis and Classic, Qpid, Solace, IBM MQ, RabbitMQ 4	amqp:// and amqps:// with your own certificate authorities
AMQP over WebSockets (wss://) for brokers behind a firewall	Azure Service Bus and Event Hubs connection strings
Client certificates (mutual TLS)	Self-signed brokers on request
SASL PLAIN, EXTERNAL and ANONYMOUS	Virtual host of your choice
Connection named Sonda in the broker’s own list, or a name of your choice	Idle timeout of your choice
Broker product and version shown on connect	The reason shown when the broker closes the connection
Hold mode: see messages without taking them	Accept, put back or dead-letter each held message
Held messages go back to the broker when a receive stops	Receive and accept
Browse: copies, the messages stay where they are	Receive and reject to the dead-letter queue
Link credit and a stop-after count per receive	JMS selector filters
Event Hubs partition start positions	Azure Service Bus sessions: one by its ID, or the next one free
Kept receives restart on every connect	Send with the broker’s outcome: accepted, rejected with its reason, released or modified
Request–reply on a temporary address, with how long it took	Body sent as bytes or as an AMQP string (JMS TextMessage)
Message ID, correlation ID, subject, reply-to and group ID	Durable, priority and time to live
Typed application properties and message annotations	Properties, application properties and annotations shown with their types
Data, value and sequence bodies read	JSON pretty-print and base64 for binary bodies

Redis streams and Pub/Sub, standalone or cluster	Clusters from several nodes or one configuration endpoint
rediss:// with your own certificate authorities	Client certificates (mutual TLS)
Self-signed servers on request	ACL users
Database selection	Client name of your choice in CLIENT LIST, Sonda by default
Server version and mode shown on connect	Stream keys found by pattern, on every master of a cluster
Each stream’s length, groups, first and last entries	Consumer groups with consumers, pending entries and lag
Pending entries with the consumer, idle time and delivery count	Read a stream live from new, the start, an ID or a point in time
Relative-time reads (for example, 15 minutes ago)	Read as one of a group’s consumers (XREADGROUP)
New entries for the group, or the consumer’s own pending	Acknowledge on read, or leave pending until Ack
First or last hundred entries (XRANGE, XREVRANGE)	Add entries (XADD) with field-value pairs
Entry IDs of your own, or made by Redis	Trim on add (MAXLEN ~)
Delete entries one by one	Create consumer groups from the end, the start or an ID
Create the stream with its first group	Remove consumer groups
Consumers Sonda made leave the group when the read ends, unless they hold entries	Pub/Sub: subscribe to channels and patterns
Publish and see how many subscribers got it	Kept reads and subscriptions restart on every connect
JSON pretty-print and base64 for binary values

FIX sessions, Sonda as the initiator	FIX 4.0 to 4.4
FIXT 1.1 for FIX 5.0, SP1 and SP2	TCP, or TLS with your own certificate authorities
Client certificates (mutual TLS)	Self-signed counterparties on request
SenderCompID, TargetCompID and the optional SubIDs	Username and password on the Logon
Extra Logon fields of your own	Heartbeat interval of your choice
Sequence numbers reset on every logon, or carried on	Next sequence numbers shown, and set by hand between sessions
Heartbeats sent when the session is quiet	A test request when the counterparty goes quiet
The counterparty’s test requests answered	Test request on demand, with how long the answer took
Resend requests answered: messages sent again as possible duplicates, with their original sending time	The session’s own messages skipped with a gap fill
Gaps in the counterparty’s numbers asked for again	The counterparty’s sequence resets followed
A sequence number lower than expected: logged out as FIX asks, with the reason	Logout said both ways
Body length and checksum checked on every message; a garbled one is reported and dropped	Messages written as tags and values, in their order
Tags by number or by name	Repeating groups as written
Fields as rows, or as text, one tag=value a line	Times, dates and fresh IDs filled in when sent
The session’s own fields written by Sonda	Values offered from each field’s own list, with their meanings
Templates: new order, cancel, replace, order status, market data, quote request, security list, mass status	Cancel, replace and status requests start from the last order sent
Paste a message (SOH, \| or ^A) into the composer	Wait for the answer, matched by a shared tag such as ClOrdID or MDReqID
Reject and BusinessMessageReject counted as the answer	Every field logged with its name and the meaning of its value
FIX 4.0 to 5.0 SP2 dictionary built in, nothing fetched	Possible duplicates marked in the log
Heartbeats and test requests behind a toggle	Filter the log, or by a message’s ClOrdID or symbol
Send a logged message again	Cancel a logged order, filled in from it
Copy a message, with or without SOH, or its fields as JSON

HL7 v2 over MLLP, both ways: send and listen	HL7 versions 2.1 to 2.8.2
Interface engines, EHRs and lab systems	TLS with your own certificate authorities
Client certificates (mutual TLS)	One connection, many messages
Empty MSH-7 and MSH-10 filled when sent: the time and a control ID	MSH-3 to MSH-6, MSH-11 and MSH-12 from the session
Now in any date or time field becomes the moment it is sent	Wait for the ACK that carries the message’s control ID (MSA-2)
AA, AE and AR read into words, with how long the ACK took	Enhanced mode: CA, CE and CR
Templates: admit, register, update patient, discharge, order, result, appointment, vaccination, document	Listen on a port, 2575 by default, this computer only or the network too
Answer each message: accept, error, reject or nothing	AE answers carry an ERR segment (2.5 and later)
Enhanced-mode acknowledgments as MSH-15 and MSH-16 ask	The ACK built from the message’s own MSH, reversed
One log for sending and listening	Each message by its type and meaning (ADT^A01 · Admit/visit notification)
A summary line: patient, MRN, visit, order, results with units and flags	Every segment, field, repetition, component and subcomponent named
Coded values read into their meaning (PID-8 F: Female)	OBX-5 read by the type OBX-2 names
HL7 escape sequences read	Names from the message’s own version (MSH-12)
HL7 syntax coloring in the composer	The composer checks as it is written: a missing or second MSH, an empty MSH-9, a segment the version does not have
Z segments accepted	UTF-8 or ISO-8859-1, as MSH-18 says
Bytes outside a frame dropped and reported	Copy a message, with CR, or its fields as JSON
Send a logged message again or on, with a fresh time and control ID	Filter the log by control ID or patient
HL7 steps in flows: the ACK’s code and fields as the output

STOMP brokers: ActiveMQ Classic and Artemis, RabbitMQ’s STOMP plugin, any STOMP 1.0 to 1.2 broker	STOMP over TCP: stomp://, tcp:// or host:port
STOMP over TLS: stomp+ssl://, stomps://, ssl:// or tls://	STOMP over WebSocket: ws:// and wss://, with the STOMP subprotocols offered
TLS with your own certificate authorities	Client certificates (mutual TLS)
Self-signed lab brokers on request	Virtual host, login and passcode, from variables and secret:// references too
Extra CONNECT headers, such as client-id for durable subscriptions	Heart-beats both ways at the slower rate, a quiet broker detected
ERROR frames read into words	Destinations: /queue/, /topic/, RabbitMQ’s /exchange/ and Artemis addresses
Ack modes: auto, client, and client one by one	Subscription headers: selectors, prefetch-count, durable names
Receipts waited for on SUBSCRIBE, so a refusal says itself	Kept subscriptions made on every connect
Held messages acknowledged or nacked from the log	ACK and NACK carry the 1.2, 1.1 and 1.0 headers, for every broker
Unsubscribe gives held messages back to the broker	Send JSON or text with its content type, JSON checked before it goes
A receipt on every send by default, with how long it took	Sonda’s own protocol headers protected from override
Disconnect with a receipt, held messages given back	Each message by destination and message-id, headers and a pretty body on click
Base64 for binary bodies	Copy a body or the headers as JSON, send a message again, filter by destination
STOMP steps in flows	CR LF frames read (STOMP 1.2)

MCP client	MCP STDIO
MCP Streamable HTTP	Legacy MCP HTTP/SSE compatibility
MCP Tools	MCP Resources
MCP Resource Templates	MCP Prompts
MCP generated forms from input schema	MCP completion suggestions
MCP progress notifications	MCP elicitation
MCP sampling	MCP server logs
MCP logging-level control	MCP OAuth discovery
MCP PKCE	MCP Dynamic Client Registration
MCP result treated as a normal API response	MCP result → Pretty / Raw
MCP result → Table	MCP result → XML / YAML
MCP result → generated types	MCP result history
MCP result diff	Themis can discover connected MCP servers
Themis can call MCP tools	Themis can read MCP resources
MCP sampling can use configured AI provider	MCP Roots client capability
Search tools / resources / prompts	Real-time MCP notifications
Explicit stateless / legacy protocol selection

SOAP 1.1	SOAP 1.2
SOAP envelope generation	SOAP Header authoring
SOAPAction handling	SOAP Fault interpretation
WSDL 1.1 import	WSDL → categorized Project
XSD-aware SOAP request skeleton generation	Nested complex-type skeleton generation
Repeated / optional XSD element hints	JSON-RPC 2.0
JSON-RPC positional params	JSON-RPC named params
JSON-RPC notifications	JSON-RPC auto request IDs
JSON-RPC fixed number / string IDs	JSON-RPC error interpretation
JSON-RPC batch response counting	XML-RPC
XML-RPC typed value serialization	XML-RPC array / struct values
XML-RPC dateTime / nil values	XML-RPC fault interpretation

Industrial devices as items of a project: Modbus, OPC UA, HART-IP, DDS	Tags: a name, a type, a scale and an offset, a unit
Every value with its quality: good, uncertain or bad	Every value with the time it was read
Watching: a value logged only when it changes	Deadbands: a number reported only once it moves past its deadband
A device gone quiet is asked less often until it answers	Writing off by default, switched on per device, asked first
Writing checked by the backend on the device as the project stores it	Every write on the activity log, with a trigger on it
A device’s tags as topics: watchers and flow triggers listen to them	Flows read tags and write them, with May send changes
Functions read tags with app.read and write them with app.publish	A log per device: reads, writes and changes
App runners reach only the devices their apps use	On watch: every read, or every change, sent to a request of the project
The read as one envelope, the same for every device: values, quality, units, what changed	A request with its own body takes the values by name: {{$watch.values.Level}}
The API down never stops the watch: failures counted on the tab, said in the device’s log	A slow API gets the latest read, never a queue

Modbus TCP	Modbus RTU over TCP, through a serial gateway
Read coils and discrete inputs	Read holding and input registers
Write a coil, a register, or several	Device identification
Exceptions in plain words	Types: bool, 16, 32 and 64-bit integers, float32, float64, string
Byte and word orders: ABCD, CDAB, BADC, DCBA	Scale and offset, read and written
Registers close to each other read in one request	Register map with live values
Addresses as manuals write them: 40001	Raw reads: unsigned, signed, hex and binary
A raw register made a tag in one click	Register map pasted from CSV, copied as CSV
Unit id, timeout and watch interval per device	A write in the tag’s own units: 21.5 °C, not register 215
A device that closes the connection is connected again, the request sent again

OPC UA over opc.tcp	Security policies: None, Basic256Sha256, Aes128-Sha256-RsaOaep, Aes256-Sha256-RsaPss
Signed, or signed and encrypted	Logon: anonymous, or a username and a password
Ask the server: its policies, modes and logons	The server’s certificate pinned: a first contact asks before connecting
A changed server certificate refused	This computer’s own application certificate, copied as PEM for the server’s administrator
Browse the address space from the Objects folder down	A variable’s data type and value shown while browsing
A node made a tag in one click	Every tag read in one request
Quality from the node’s status code	Time from the server’s source timestamp
A write in the node’s own data type	The server’s refusals in words
Sessions reconnect on their own

HART-IP over TCP, port 5094	An instrument, or a HART-IP gateway or multiplexer in front of it
HART 5, 6 and 7	Found at its polling address, then reached at its unique address
PV, SV, TV, QV and the loop current in one command	Percent of range
Device variables, each with its own status	Units from the device, as names: bar, °C, m³/h
Quality from the field device status	Tag, long tag, descriptor, message and date
Write the tag, descriptor and date	Write the long tag and the message
Write the damping	Write the range, in its own unit
Write protection said before anything is sent	The device’s refusals in its own words
Loop test: the current fixed at 4, 12, 20 mA or any value	The loop released when its time is up, on Release, and on disconnect
Configuration written only by a person, never by a flow	The session kept alive while open
A timed release that fails is tried again every few seconds, said on the activity

DDS in pure Go: RTPS, no C library	Discovery over multicast
Discovery by named peers, where multicast does not pass	The network interface chosen per domain
Participants, with their vendor and RTPS version	Every topic: its type, its writers, its readers
QoS per writer and reader: reliability, durability, history, partitions, representation	Why a reader and a writer do not match, in words
ROS 2 topics shown by their ROS names	A topic’s samples live, decoded
Types from IDL: modules, structs, enums, typedefs, sequences, arrays, @key	Types from ROS 2 .msg definitions
ROS 2’s common types known without a definition	XCDR1 and XCDR2: final, appendable and mutable types
A sample with no definition shown as its bytes and its text	Instances told apart by their key
Disposed and unregistered instances said	A topic’s field as a tag, for one instance or all
Publishing off by default, switched on per domain	Publish a sample written as JSON, encoded by its type
Reliable or best effort, volatile or transient local	Late joiners get the samples kept
A lost sample resent on the reader’s request	The representation the topic’s readers take, picked on its own
Publish to a topic nothing announces yet	A flow writing a tag publishes its instance with the field set
Readers matched by DDS’s own rules before the first sample goes	Every sample published on the activity log
History kept per instance on a keyed topic	Volatile readers get new samples only; transient-local ones get the history
History and resends of any size, split into datagrams	Ownership and partitions matched by DDS’s own rules

Workspaces	Multiple accounts / identities
Multiple workspaces per account	Environments
Parent / child environment inheritance	Variable precedence
Dynamic variables	Variable autocomplete
Unresolved-variable warnings	Auth inheritance
Folder / project inheritance	Pre-request scripts
Post-response scripts	JavaScript scripting
Go scripting	Python / Starlark scripting
A variable set to Ask: no value kept, a form at the send	Asked as text, number, yes / no, or a select with its choices
Asked every time, or once	Asked at every request that uses it, or only at the requests picked
Only the requests picked, or those and any other while it has no answer	A flow’s run asks too, in its inputs form
Route: a variable names the request that fills it, run first when it is empty	Ephemeral variables: never kept, cleared at a change of environment
A send reads the variables as their open tab has them, unsaved rows included	What a script sets holds for the session, written nowhere
Session values listed under each table, with Keep and Drop

A request becomes a form for a runner	Each field Hidden, Shown or Runner fills
Auth hidden from runners by default	Runner choices inherited from folder and project
Instructions for the runner shown above the form	Preview a request as a runner sees it
Scripts and checks still run on what a runner sends	Without a Runner view, runners send a scratch copy that is never saved
Runners can read and export the documentation

Collaborative Workspaces as a first-class team object	Workspace contains multiple Projects
People and roles assigned at Workspace level	New Projects inherit Workspace membership
Personal and Collaborative Workspaces coexist	Granted Collaborative Workspaces appear locally automatically
New team member lands in first shared Workspace automatically	Workspace membership materialized into Project grants
Workspace setup saves name, description and access atomically	Workspace people/role changes publish in one operation

Share a Workspace with another Division	Cross-Division access can be Read only
Cross-Division access can be Run (send, change nothing)	Cross-Division access can be Read and write
Workspace remains physically owned by its home Division	Foreign Division opens the authoritative source Workspace
No Project copy is created for cross-Division sharing	Project keys wrapped for authorized members of receiving Division
Cross-Division readers/writers added cryptographically	Revoking Division access removes wrapped keys and readers
Foreign Workspace visibly identifies its home Division

OAuth 1.0 (RFC 5849)	OAuth 1.0 HMAC-SHA1
OAuth 1.0 HMAC-SHA256	OAuth 1.0 PLAINTEXT
OAuth 1.0 RSA-SHA1	OAuth 1.0 Authorization-header signing
OAuth 1.0 query-parameter signing	OAuth 1.0 fresh nonce / timestamp per send
OAuth 1.0 callback / verifier fields	OAuth 1.0 temporary-credentials request support
Postman OAuth 1.0 import / export	Insomnia OAuth 1.0 import / export
Postman OAuth 2 / Digest / AWS SigV4 round-trip import-export

Cookie jar	Proxy settings
Client certificates (mutual TLS)

Code-free assertions / checks	Status assertions
Header assertions	Body / path assertions
JSON Schema assertions	Draft JSON Schema from response
Project → Folder → Request inherited checks	Project / collection runner
Choose requests for a run	Multiple iterations
CSV datasets	JSON datasets
Per-row variables	Delay between requests
Stop on failure	Programmatic next-request sequencing
HTML runner reports	JUnit reports
JSON runner reports

Built-in load testing	Concurrent virtual users
Ramp-up control	Think time
Duration-based load test	Request-count-based load test
Data-driven load testing	Live RPS
Sent / OK / Failed counters	Error rate
Min latency	Average latency
p50	p95
p99	Maximum latency
Apdex	Latency histogram
Status-code breakdown	Top errors
RPS timeline	Latency timeline
Per-request load breakdown	Configurable performance pass criteria
Saved load-test history	Compare two load-test runs
HTML load report	JSON load report
Load users distributed across network origins

Flows: a canvas of steps inside a project	Several flows per project
Call step: any request in the project	Call step: gRPC calls
Call step: MCP tools	Call step: Kafka records
Call step: RabbitMQ messages	Call step: MQTT messages
Cluster or broker connected before its first call	A request’s variables filled per step
A request’s body replaced per step	Flow step: another flow, with its inputs
Script step in JavaScript, await included	Set step for named values
Note step	If step: a yes and a no branch
For each: over a list, a number or words	For each: one at a time or N at once
For each: every result collected when done	Join: all, any one, or N of the wires arriving
Wait step	Wait until: a call repeated until a condition holds, or a timeout
Check step: assertions with pass and fail	End step: success or failure, with a message
Show step: a table drawn on the canvas as the flow runs	Several wires from one port run at the same time
Any field reaches an earlier step’s answer by name	Upstream outputs listed with their keys, click to copy
Flow inputs with a form to run from	Fail ports: a failure handled where it is wired
Live run on the canvas: status, words and milliseconds per step	Run history: each step’s outputs, the log, the values set
Runs kept per flow, how many is a setting	Runs stay on this computer, never published to the team
Credentials hidden in kept runs and exports	Calls in flight capped across branches and loops
Time limit for the whole run	Stop on error, or let the rest go on
Stop a running flow	Drag a request from the tree onto the canvas
Undo and redo	Copy, cut, paste and duplicate steps, between flows too
Fit the whole flow into view	Minimap
An Echo endpoint can run a flow: a local webhook	The flow answers the webhook with its own status, headers and body
Export a run as one HTML page	Runners run a flow from its inputs form, the canvas read-only
Themis lists and runs flows	Call step: NATS, AMQP 1.0, Redis, FIX, HL7 and STOMP messages
Trigger: a message on one of the project’s messengers starts the flow	Topic wildcards and a filter over the message
The message as the flow’s input, its fields filling the inputs	Runs at once set per trigger, in arrival order when one
Listening switched on per computer, never on every member’s at once	Changes from a message only with May send changes, asked first
A flow that would feed its own topic does not listen	Breaker: 30 runs in 10 seconds switches the trigger off, saying why
RabbitMQ, AMQP 1.0 and STOMP: acknowledged after the run, rejected or put back when it fails	HL7: the run answers with AA, AE or AR, and its words
RabbitMQ reply-to answered with the run’s reply and correlation id	Call step: Modbus, OPC UA, HART-IP and DDS: read tags, or write one
Trigger: a device’s tag changing past its deadband	If, Check, Wait until and filters read by Sonda, never run as code
Script step in Sonda’s own engine: the flow’s values, no network	Stopping a trigger ends the messenger’s hold, what waits goes back
A queue’s backlog runs the flow from its first message	A read whose scripts send requests counts as a change
A flow waits while its messenger is away, and takes its hold back when it is back	One connect per messenger at a time; a client reconnecting by itself is never replaced
A messenger’s pane asks before ending what a flow listens through	Two held flows on one queue share one consume; the last to leave ends it
A request a flow calls cannot be dropped into another project

Apps built inside a project, over its own requests	A screen designer: cards dragged and sized on a grid
A whole app built from the project’s spec in one step	Built apps: lists open their records, create goes to the new record, delete asks first
Themis builds and changes apps by asking	Fields, buttons and cards linked: a field feeds its button, a button fills its cards
The links drawn on the designer as a card is picked	Property grid with categories, in a panel that moves
Cards that load as the screen opens	A write never runs as a screen opens
Required fields checked before anything is sent	Field checks written as a function
Choice fields from a list, or filled from an API	Choice lists from the spec’s enums
Secret fields for passwords, PINs and API keys, typed hidden	File fields for binary and form-data uploads
Comma-separated fields for lists of values	Optional query parameters as optional fields
Nested body fields as plain fields: category.id becomes Category id	Table cards, their columns read from the answer
Badge columns in green, amber, red and blue	Copy a value with one click
Load more for paged APIs	Row buttons: a record opened in a popup or a screen
Row click opens another screen with the row’s values	Row click presses a button on the same screen: master and detail
Popups over a screen, closed with Esc	Screens hidden from the menu
Dashboards: number cards and charts	Charts grouped by a field that repeats in the data
Screens that refresh every few seconds	Confirm before a button sends changes
Buttons that open a URL with the screen’s values	After a create, straight to the new record
Dates shown as dates and amounts as money, read from the answer	Card heights: as drawn, growing with the rows, or down to the window’s bottom
App brand: color and logo	An app pinned to an environment
An app calls only its own project’s requests	Built from any OpenAPI spec, proven on the public Petstore

Functions kept with each app	JavaScript, Go and Python (Starlark)
A button that runs a function	A card filled by a function
An answer reshaped by a function before it shows	A field checked by a function
app.call: any request of the app’s project	app.publish: a message to any of the project’s messengers
The fields, the session, the row and the answer in hand	Say, notify, go to a screen, open a popup, keep a value
A function changes things only from a pressed button or an allowed watcher	Try it in the editor
Errors pointed at the function’s own line	Themis writes, changes and tries functions
app.read: a device’s tags, read now	app.publish to a device writes its tag

Watchers kept with each app	A check every few seconds
At set times, on chosen days	Listening on a messenger’s topic, each message checked
When it fails, when a value holds, when it changes, when something new arrives, or when a function says so	Fires as the condition starts to hold, not on every check
Desktop notifications	Then: a popup, a screen, a badge, a mark
Then: a request, a function, a message published	Changes only from a watcher allowed to send them
One clock for every open app, never overlapping	Backs off while the API fails
Watchers panel: the last word, pause, a log	Themis adds, changes and tries watchers
Listening on a device’s tags, each change checked	Paused from a messenger’s pane, until the app is opened again
Listens again on a new connection, from now on

App runner: a user type that runs apps and nothing else	Apps ticked per app runner, on the member sheet or the app’s Runners page
The app full screen: no sidebar, no tabs	An Applications dropdown to switch apps
Toolbar: licensed-to line, change password, log out	An app runner counts as a user
No role, no projects, no Discover, no Themis, no terminal	One type per person: no role or grant on top, from any door
Owner, administrators and members of several divisions are never app runners	Requests only from the apps it runs, enforced by the backend
Each request exactly as stored: method, host, path, parameters, headers, body fields, auth	Values checked under the app’s own environment
Only the places and variables the app fills may change	Brokers and devices only by exact reference from its apps
Scripts only of the requests its apps use	Tunnels only the ones its apps go through
The window holds its apps and what they use, nothing else	Project keys only for the projects its apps live in
Every other backend operation refused, kept closed by a test	Exports refused
App runs in the activity log, with a trigger on them	Its scripts run on what the backend holds: the app’s environment, the answer received
A request’s scripts run whole: in order, each once, in its language

Via: execute API requests from SSH server	Per-request Via selector
Folder Via inheritance	Project Via inheritance
Override inherited Via back to Local	Reach private API over SSH
Test IP-whitelisted API from remote server	Persistent SSH connection
No remote Sonda agent required	SSH direct-tcpip channels
TLS carried inside SSH	Preserve destination SNI
SSH known-host verification	First-contact fingerprint approval
Changed host-key rejection	SSH password auth
SSH key auth	SSH-agent auth
Remote reachability test

FHIR server discovery via CapabilityStatement	Import FHIR server from /metadata
CapabilityStatement → Project	FHIR resource folders generated automatically
FHIR Search interactions	FHIR search-parameter generation
FHIR Read	FHIR versioned read
FHIR Create	FHIR Update
FHIR Patch	FHIR Delete
FHIR resource history	FHIR server history
FHIR resource operations	FHIR transaction Bundle
FHIR batch Bundle	FHIR resource body skeleton generation
application/fhir+json handling	FHIR OperationOutcome interpretation
FHIR Bundle interpretation	FHIR resource identification
FHIR pagination via Bundle.link[relation=next]	One-click FHIR Next page
OData v4	OData CSDL / EDMX $metadata import
OData service → complete Project	OData EntitySet discovery
OData $filter	Property-aware OData $filter hints
OData $select	OData $expand
OData $orderby	OData $top
OData $skip	OData $count
OData $search	OData typed key URL generation
OData compound keys	OData typed Create skeleton
OData EDM primitive-type skeletons	OData complex-type skeletons
OData enum-value skeletons	OData collection-type skeletons
OData base-type property inheritance	OData PATCH generation
OData PUT generation	OData DELETE generation
OData navigation-property requests	OData singletons
OData function imports	OData action imports
OData service document	OData error interpretation
OData collection interpretation	OData entity interpretation
OData @odata.nextLink pagination	Relative OData next-link resolution
One-click OData Next page

Programmable Echo APIs	Static Echo responses
Request-aware Echo responses	Stateful Echo datasets
Mutable datasets across calls	Dataset reset to seed state
Automatic dataset CRUD	Echo script handler
Echo scripts in JavaScript	Echo scripts in Go
Echo scripts in Python / Starlark	Artificial response delay
Echo request / hit log	Internal echo:// protocol
In-process Echo call without TCP	Optional real network listener for the same Echo
AI-generated Echo API	Database-backed internal APIs
Internal sonda:// protocol	MongoDB endpoints
MongoDB find / findOne	MongoDB aggregate
MongoDB insert / update / delete	MySQL endpoints
MariaDB endpoints	PostgreSQL endpoints
SQL Server endpoints	Typed DB placeholders
Bound SQL parameters	Typed BSON / Mongo parameters
DB read-only mode	DB timeout / safety caps
DB endpoints callable from ordinary requests

Pretty response view	Raw response view
HTML response preview	Automatic JSON table view
Nested table exploration	Table filtering
Table sorting	Select visible columns
CSV export from response	XLSX export from response
JSON → XML view	XML → JSON view
JSON / XML → YAML view	Generate TypeScript interface from response
Generate Go struct from response	Generate Python dataclass from response
Generate C# classes from response	Merge array-object shapes for type inference
Nullable-field inference	Optional-field inference
Integer / float inference	Date / time inference
Keep every send	Per-send full response snapshots
Automatic last-known response	Last-known response survives app restart
Explicit stale/local-response indicator	Send to refresh stale response
Forget retained last response	Saved response examples
Side-by-side response diff	Inline response diff
JSON response diff	XML-conversion diff
YAML-conversion diff	TypeScript-contract diff
Go-struct diff	Python-dataclass diff
C#-class diff	Full response-only mode
Request/setup-only mode	Per-tab request / response workspace layout
Different tabs can independently stay response-only / split / request-only	JSONPath at cursor
Response bookmarks	Create variable directly from response value
Use response as body of new request	Default GET → PUT response workflow
Clone auth to response-derived request	Clone headers to response-derived request
Clone query / cookies to response-derived request	Code generation
cURL generation	Raw HTTP generation
JavaScript fetch generation	Go generation
Python generation	DNS timing
Connect timing	TLS timing
Send timing	Wait / TTFB
Download timing	Connection reuse
Remote address

Discover: use an app and Sonda builds the API behind it	Capture from a browser Sonda opens: Chrome, Edge or Brave
A fresh browser profile per capture, shredded when it ends	Read over the DevTools protocol: no extension, no certificate
Every request with its real kind: XHR, fetch, page, script	Bodies as the browser decoded them
WebSocket frames captured	Event-stream messages captured
Popups, frames and service workers captured	Capture proxy for phones, desktop apps and scripts
HTTPS read with a certificate authority made for the capture	Certificate authority key in memory only, or kept sealed on request
Certificate handed to the device at http://sonda.cert	Other devices ask first: Allow or Refuse
A refused device is cut off, open connections included	Allowed devices never reach this computer’s own services
Link-local addresses, cloud metadata included, refused for devices	The real site’s certificate always checked upstream
HAR import, read as a stream, files up to 1 GB	Capture through a tunnel
Nothing captured is written to disk	Live table: search, API calls, pages or everything, by status
Headers and bodies of any captured call on click	Trackers left out by a list you edit
Hosts outside the site flagged and left unticked	Preflights folded into their calls
Paths made templates only where a value is plainly an id	GraphQL split by operation, batches and persisted queries included
JSON-RPC split by method	Repeated calls folded, the richest sample kept
Requests named as a person would name them	Bearer token traced to the answer that handed it out
Login request gets the script that keeps the token	Basic, API key and cookie sessions detected
CSRF token carried from a cookie into its header	OAuth 2.0 sign-in offered as the project’s own auth
A folder per resource, and per host when there are several	Answers kept as examples, credentials hidden
Captured credentials as masked variables	A flow that replays the session, values passed on by name
An Echo that answers like the captured API did	Session cookies put in Sonda’s jar
Local only by default in a team’s Workspace	A shared project never carries the captured credentials
Up to 20,000 requests per capture	The organization’s rules: Wide open, a curated domain list, or open with DNS validation
The curated list: the browser opens on it, the proxy refuses the rest, a file’s other domains left out	The rules the owner’s, read when Discover opens and when a capture starts
A rule file gone from the store, or an older copy put back, refuses the capture

OpenAPI import	Swagger 2 import
Import OpenAPI from URL	Postman collection import
Insomnia import	HAR import
cURL import (paste a command)	Bruno .bru import
Bruno .bru export	Bruno scripting compatibility layer
OpenAPI-linked requests	Update Project from changed spec
Preserve user-owned edits on spec refresh	Preserve removed operations instead of silently deleting
Response status validation against spec	Response schema validation
Generate OpenAPI from Project	OpenAPI 3.1 generation
OpenAPI 3.0 generation	Swagger 2 generation
Self-contained HTML documentation	Documentation generated directly from Project
Folder-grouped navigation	Documentation code samples
Documentation from live session response	Keep response as documentation example
Interactive docs preview	API description → generated working Project
OpenAPI → generated Project	WSDL → generated Project
FHIR CapabilityStatement → generated Project	OData CSDL / EDMX → generated Project
gRPC reflection → callable API surface	MCP discovery → callable tool/resource surface

Git-readable Project format	Plain-text / YAML project representation
Standard .git repository	Git init
Git status	Commit
Diff	History / log
Branch create / switch	Fetch
Pull	Push
Clone	Merge / conflict workflow
Built-in desktop terminal	Local-first operation
No account required for core local use	Full desktop workflow without vendor cloud
Air-gapped-capable workflow	Password-encrypted entire workspace
Incognito / no-persist request	No history in incognito mode
No retained response in incognito mode	No retained cookies in incognito mode

Account chooser appears before any account-specific boot	No team-store pull before account selection
No Workspace load before account selection	No access-policy trigger before account selection
Pending publish queue cleared on account switch	Approval-flow cache isolated across accounts
Component-lock cache isolated across accounts	Merge state isolated across accounts
Queued action from previous account cannot execute under next identity	Display defaults do not silently mutate semantic Project state
Governed drafts use semantic comparison against store state	Sign-in with username and password; no account list shown
Password checked on every sign-in; switching account locks the account left	Revoked or changed credentials refused on the first screen
A wipe takes everything: every account, every team known, sessions and temporary copies	After a wipe, Sonda opens on the first page, as new
A team account opens again from the team’s store, no ticket needed	One username and password on several teams: the door asks which account
A password set, changed or removed reseals every file of the account, all or none	A stop in the middle of a reseal is finished or undone at the next start
The AI seat and the Git tokens are each account’s own	Unsaved tab changes kept across a restart, sealed with the account’s password
Close, lock or switch asks before going on without changes that could not be kept	Deleting a workspace offers its export first and is typed to confirm
Backups carry the tabs’ unsaved changes and the mail server

Collaboration through Git	Collaboration through S3-compatible storage
Cloudflare R2 team store	AWS S3 team store
Azure Blob team store	Google Cloud Storage team store
Backblaze B2 team store	SSH team store
WebDAV team store	Encrypted collaboration over customer-owned storage
LockFlare does not store Project contents	Per-Project encryption key
Project key wrapped separately per member	Reader removal rotates Project key
Project / folder / item sealed objects	Signed membership state
Signed role state	Signed project metadata
Refuse stale membership revision	Incremental object sync
Batched parallel store reads / writes	Packed encrypted snapshot for initial pull
Per-item encrypted revisions	Restore old item revision
Exclude specific folder from collaboration	Exclude specific item / request from collaboration
Project Collaboration Home / Setup / Approvals / History workspace	Team-store-native published Project history
Per-component published history	Open historical component without restoring
Restore and republish historical component	Configurable retained team-store versions
Pause editing for everyone on a shared Project	Project change freeze enforced by backend
Project freeze applies to administrator too	Share Project as transactional publish action
Shared repository revision shown explicitly	Delete shared Project from team store
Remote Project deletion moves local member copy to Trash	Semantic conflict detection ignores non-meaningful serialization differences
Resolved conflicts stay resolved across subsequent syncs	Collaboration tab on every folder and item
Pause editing on a single folder or item	A paused folder freezes everything under it, administrator included
Hide a folder or item from the team	Hidden items disappear from the tree, documentation, exports, search and Themis
Sonda Server team store: one server of your own holds the store	Every write compared against the version it was based on, at the store
Nothing written until Save: every item edited on its tab’s copy	Save writes this computer alone; Save & Publish sends that one thing
Publish now sends everything saved here: items, folders, deletes, moves	A pull keeps a delete or a move made here and not published
A teammate’s change pulled while a tab is open is kept when it is saved	The project’s own fields never written over a teammate’s newer ones
Shared environments: Save stays here, Save & Publish sends	An MCP server’s last arguments stay on this computer
A copy of a shared project is this computer’s own until shared

One program on a Linux or Windows server of your own	Builds for Linux amd64, Linux arm64 and Windows amd64
Holds the team store’s credentials: no member computer receives them	Keeps the team store in a folder of its own disk: no bucket needed
Or stands in front of S3, Azure, Google Cloud Storage, SSH, WebDAV or Git	A setup that asks, question by question, secrets typed unseen
The setup creates the organization, its first division and its administrator	One line carries the address, the token and the certificate’s fingerprint
That line pasted into Sonda fills all three	Installs itself as a service: systemd on Linux, the Windows service manager
TLS 1.3 only, on both ends	Its own certificate, pinned by fingerprint: the one certificate taken
Or the team’s own certificate, or a proxy of the team’s in front	A call without the token gets a bare not-found, nothing more
The token kept only as its SHA-256, said once, replaced in one command	Allowed networks: other addresses closed before the handshake
An address that keeps calling without the token is dropped for a while	Each person signs in to the server with a username and a password
The server checks the password itself and keeps it nowhere	The token alone reaches no file of the team’s
A paused or revoked account is refused at its next call	A password set again by an administrator ends that account’s sign-ins
Repeated failed sign-ins for one username are held for a while	The administrator’s password set again on the server, in one command
The provisioning bridge signs in with its own key	Two publishes in the same instant never both land
One server per store folder, held by the operating system’s lock	A write is whole or not there
Its private files are its account’s alone, on Linux and on Windows	On Windows, refuses to run a service from a folder others can change
Optional: small teams keep reaching their own store directly

Organization above multiple collaboration divisions / teams	Create multiple organizational divisions / teams
Independent membership per division / team	Independent roles per division / team
Independent Projects per division / team	Division / team administrator role
Organization owner role	Centralized or delegated organizational administration
Owner can enter and administer any division	Cryptographically scoped division-administrator delegation
Division-admin signature valid only inside its assigned division	Organization owner trusted across all divisions cryptographically
Revoke division administrator cryptographic authority	Revoked delegate signatures rejected on subsequent sync
Each division has a separate cryptographic roll / seal	Same customer-owned repository can host cryptographically isolated divisions
Division has independent roster / roles / projects / approvals / locks	Division has independent Mail and Themis configuration
Organization-wide Mail default inherited by divisions	Organization-wide Themis default inherited by divisions
Division can override inherited Mail configuration	Division can override inherited Themis configuration
Organization-defined role set inherited by a new division	Division can establish its own role set after inheritance
Division rows show member and Project counts	Directory source can target a specific division
Entra / Okta groups can provision into specific divisions	Leaver processing scoped to target division
Organization owner can orchestrate multi-division directory sync	Division administrator directory sync limited to own division
Same person can belong to multiple divisions / teams	One identity and key across every division a person belongs to
Organization Project stored once at organization root	Organization Project shared to selected divisions
Organization Project omitted from unselected divisions	Division receives organization Project as read-only content
Only the owner publishes organization Project	Organization Project key wrapped for active members of selected divisions
Organization Project key also wrapped for division admins	Organization Project paths remain rooted outside division stores
Removing a division from sharing removes member copies on next sync	Three ways to start: Standalone, Small teams and developers, Enterprise
Enterprise: the organization is made on Sonda Server, people only sign in

Administrator is selected from an existing person	Human identity is reused when elevated to Division Administrator
Division Administrator uses the member's existing key	Division Administrator authority remains cryptographically scoped
Removing administrator status returns the same identity to member	Several administrators per Division
Dedicated Division management dialog/control plane	Division setup, administrators, services, Workspaces and people in one place
Move an organization-root member into a Division	Member move preserves the same identity and key
Member receives owner-signed move instruction and follows it on sync	Naming an administrator can move a root member into the Division at the same time
Enterprise Setup → Discovery: the organization’s reverse-engineering rules

Organization-wide catalog of named Themis AI seats	Organization-wide catalog of named Secret managers
Organization-wide catalog of named Git accounts	Catalog never returns stored AI keys or Git tokens to the UI
Division selects one organization Themis seat	Division selects multiple organization Secret managers
Division selects multiple organization Git accounts	One save re-seals selected services to Division members/admins
Unlinking a service removes it from the Division	Division may inherit, override or disable organization service

All features available free up to 20 organization users	Free-user limit counted across the whole Organization
Division users count toward the same Organization limit	Signed per-team head counts used for Organization total
Paid license raises Organization-wide user capacity	Division Administrator enforces Organization capacity without holding license key
License can be cryptographically bound to Organization owner identity	License expiration falls back to free capacity without deleting existing users

Application RBAC	Per-Project access role
Administrator role	Editor role
Runner role	Viewer role
Custom roles	Granular request permissions
Granular script / check permissions	Central backend RBAC enforcement
Permissions enforced independently of UI state	Same permission policy applies to Themis actions
Same permission policy applies to keyboard shortcuts	Same permission policy applies to imports / paste
Same permission policy applies to drag / drop	Request-send permission separate from request-edit
Script-edit permission independent of request-edit	Check-edit permission independent of request-edit
Environment-edit permission independent of request-edit	Project-create permission enforced on imports / clones / demos
Cross-project move validates source and destination permissions	Load-test execution permission enforcement
Local non-shared objects exempt from collaboration policy	Semantic change detection avoids false RBAC refusals
Internal OAuth refresh is not mistaken for a manual auth edit	Derived path-variable updates are not mistaken for user edits
Permission refusals recorded in collaboration activity	Member pause / resume
Access expiration	Allowed working days
Allowed working hours	Timezone-aware schedule enforcement
Cross-midnight access windows	IP / CIDR access restrictions
Gate Workspace before content appears	Team-roster view permission independent of administrator access
Sealed member roster distributed to active members	Member-visible team role names
Member-visible project-scope information	Member can see workflow-approver status
Member Collaboration view limited to permitted pages	Hide Projects user cannot access
Show inaccessible Project name but keep contents sealed	Signed invitations
Self-service enrollment	Each user generates a personal keypair
SSO-verified enrollment	Admin approval of enrollment
OIDC SSO	SAML 2.0 SSO
IdP metadata import	SP metadata generation
Signed SAML AuthnRequests	SAML Response signature verification
SAML Assertion signature verification	Encrypted SAML assertions
SAML Single Logout	SP-initiated logout
IdP-initiated logout	SCIM 2.0
SCIM Users	SCIM Groups
SCIM group → role mapping	Customer-hosted SCIM bridge
SCIM without LockFlare control plane	Delegated provisioning key
Revoke provisioning key	Provisioned user enable / disable
Automatic enrollment matching SCIM identity	Multiple external identity directories
Microsoft Entra directory sync	Okta directory sync
Multiple directories simultaneously	Parallel directory sync
Union-of-directories membership	Per-directory default role
Automatic leaver deactivation	Fail-safe: no removals when a directory read fails
Scheduled directory reconciliation	Manual directory sync
Internal cryptographic roster available independently of Team-page visibility	Approval signature verification does not require Team roster UI permission
Roles set per folder or item; the nearest one wins	Send permission enforced on every live protocol
Try the company sign-in before it applies	An offline window holds when the identity provider does not answer
The SAML service provider’s private key sealed to every account, never in the clear

New member starts with no Project access by default	New member cannot create Projects until explicitly granted
New member cannot approve until explicitly granted	Disable member without destroying identity/key
Re-enable member using the same identity	Notification for sign-in attempt from disallowed network
Notification for sign-in attempt outside allowed days/hours	Denied sign-in notification includes computer and addresses
Denied sign-in notifications deduplicated per session	Invitations good for fourteen days, a new one retires the last
The newcomer’s key sealed under the newcomer’s own password, never held by the administrator	A request to join can be withdrawn
A declined request carries the reason

External secret-manager integrations	HashiCorp Vault
AWS Secrets Manager	Azure Key Vault
Google Secret Manager	1Password Connect
Doppler	Infisical
Generic HTTP secret provider	Uniform secret://provider/path#field syntax
Resolve secret only when executing request	External secret never written into Workspace
External secret never written into team store	Resolve multiple secret refs concurrently
RAM-only resolved-secret cache	Configurable secret cache TTL
Clear cached secrets manually	Automatically mask resolved secret values
Secret resolution for HTTP	Secret resolution for GraphQL
Secret resolution for gRPC	Secret resolution for WebSocket
Secret resolution for SSE	Secret resolution for MQTT
Secret resolution for Socket.IO	Secret resolution for MCP
OAuth fetch / refresh can resolve secret references	Native Sonda Secrets vault
Native local first-party secrets	Native team-shared encrypted secrets
Per-secret reader ACL	Fresh 256-bit key per Sonda Secret
Secret separately encrypted from Project data	Secret key wrapped separately for each reader
Signed secret files	Signed secret index
Secret stored encrypted in customer-owned repository	Repository access alone cannot decrypt secret
Secret plaintext never returned to frontend	secret://sonda/<name> execution-time reference
JSON subfield secret references

General AI assistant (Themis)	BYOK AI
Anthropic	OpenAI
xAI	Local / OpenAI-compatible AI endpoint
AI sees selected Workspace context	AI can explain responses
AI generates requests	AI generates scripts
AI generates checks / tests	AI writes documentation
AI creates Projects directly	AI creates folders directly
AI creates requests directly	AI sets variables through typed app tools
AI configures auth through typed app tools	AI creates checks through typed app tools
Documentation URL → full categorized API Project	AI discovers / imports OpenAPI rather than recreating it
AI-generated Echo API, from a description	AI can create Echo datasets
AI can create Echo endpoints	AI can start an Echo
AI web fetch limited to user-named hosts	AI tool results treated as untrusted data
AI output not executed directly as arbitrary code	Risky actions require explicit human confirmation
Per-Workspace Themis conversation	Themis conversation kept only in memory by Sonda
Administrator-managed shared team AI configuration	One shared AI provider / model configuration for authorized members
Dedicated RBAC permission to use team AI	Shared AI credentials sealed in customer-owned repository
AI credential wrapped only for members with AI permission	Member can use team AI without seeing API key
Shared AI credential kept only in member memory	Shared AI credential not persisted to member disk
Role changes automatically update team-AI access	Stop sharing centrally revokes team AI on next sync
No LockFlare AI credential relay required	Themis understands SOAP / WSDL workflows
Themis understands JSON-RPC / XML-RPC request modes	Themis understands STOMP request / connection workflow
Themis understands FHIR discovery / paging semantics	Themis understands OData metadata / query / paging semantics
AI import tool probes OpenAPI / WSDL / OData / FHIR descriptions	Themis respects collaboration holds rather than bypassing governance
Themis builds flows, watchers and functions over industrial devices

Temporary exclusive edit lock on a shared component	Named lock owner
Configurable lock duration (1–168 hours)	Lock reason / note
Lock takes effect immediately	Lock owner retains edit rights
Everyone else becomes read-only	Administrator is also blocked from editing locked component
Administrator can forcibly lift another member's lock	Lock owner can release early
Lock expires automatically	Folder lock applies to descendants
Locked component cannot be deleted by another member	Lock cannot overlap an approval-frozen item
Backend-enforced component lock	Lock visible in Project tree and editor
Workspace-wide Locks view	Lock records signed by the lock owner
Lock records sealed to the team	Administrator notified when a lock is taken
Configurable lock notification audience	Lock audience notified when lock is released or lifted

Three-way merge using a common base revision	Automatic clean merge before declaring a conflict
Field-level structured object merge	Query parameters merged by key
Headers merged by key	Path variables merged by key
Checks merged by stable ID	Examples merged by stable ID
Saved protocol messages merged by stable ID	One-sided field change automatically wins
Same change from both sides auto-resolves	Only mutually changed fields become conflicts
Non-conflicting edits from both users are preserved	Automatic merge attempted during publish
Automatic merge attempted during pull	Per-field conflict resolution UI
Conflict view shows both values and remote author	Every conflicting field requires explicit resolution
Apply merged result and publish	Whole-item keep-local fallback
Whole-item take-remote fallback	Previous publisher notified when revision is merged / replaced
Merged or replaced revision remains restorable in History	Semantic conflict detection ignores serialization-only differences
Resolved semantic conflicts stay resolved across later syncs

Visual approval workflow builder	Executable approval workflow runtime
Project-scoped approval flow	Folder-scoped approval flow
Request-scoped approval flow	Nearest-scope approval policy wins
Single-approver step	Multi-approver step
All-approvers rule	Any-one approver rule
N-of-M approval quorum	Sequential approval stages
Parallel approval branches	Fan-in waits for all reached predecessors
Conditional branch on change type	Conditional branch on scripts / auth touched
Conditional branch on submitting member	Notification node inside approval graph
Approved / Rejected terminal outcomes	Custom instructions / notification templates
Approval reminder interval	Changes held from team publication until approved
Submitted item frozen for everyone during approval	Originator also blocked while approval is pending
Backend-enforced approval lock	Approval lock visible in Project tree / editor
Exact proposed content attached to submission	Field-level proposed-change diff for approver
Submission records base repository revision	Governed local draft is not treated as a sync conflict
Remote store changes do not overwrite governed draft	Manual save cannot bypass approval
Manual publish cannot bypass approval	Conflict resolution cannot bypass approval
Approved change publishes through privileged approval path	Allow changes returns editing to originator only
Resubmission restarts full review	Multi-round approval on one submission
Originator can cancel approval	Cancellation releases item locks
Required approvers automatically notified	Originator notified of allow-changes / reject / approve
Append-only approval event history	Approval event signed by its author
Approval entries sealed to team members	Deterministic approval state rebuilt from event chain
Built-in approval configuration diagnostics	Deletes, moves and new folders under a flow go up only through their submission
A request under a flow cannot be dragged out of that flow’s reach

Built-in SMTP notification engine	SMTP TLS
SMTP STARTTLS	SMTP AUTH PLAIN
SMTP AUTH LOGIN	Microsoft 365-compatible SMTP path
Team-shared sealed SMTP configuration	SMTP password never displayed to members
Revoked member loses access to shared mail config	Invitation email
Join-request email	Approval / decline email
Directory-sync result email	Per-member notification rules
Notify selected team members	Notify administrator shortcut
Login activity notification	Request-create notification
Request-update notification	Request-delete notification
Request-send notification	Folder-create / delete notification
Project-create / delete notification	Project-publish notification
Project-publish activity trigger covers burst publishes	Project / Bruno / backup export activity trigger
Activity tracking covers WebSocket / gRPC / MQTT / SSE / Load Test / MCP items	Secret-use notification
Echo-start notification	Load-test notification
Export notification	Activity event batching / digesting
Duplicate-event counting	High-signal events sent immediately
Notification mail sent from member's own Sonda	No LockFlare notification relay required
Notification rule persistence	Administrator notification recipient fallback
Notification delivery / failure activity logging	Per-session sign-in notification state resets on account switch
Unmanaged-directory status persists across sessions

Each person’s activity: sign-ins, sends, request changes, publishes, team-secret use, exports, mock APIs started, load tests, people added or revoked	Written to the person’s own month in the team store
Signed by the person alone: nobody else writes there	Sealed to the person, the owner and the division’s administrators
Kept sealed on the computer until the write lands	Activity page by month, person and kind
Members see their own activity	The same action within ten minutes is one line, counted
Personal workspaces stay off the activity log

Named reusable repository definitions	Repository connection test
Repository browser	Backup complete team store
Backup contains sealed / signed store files	Backup remains unreadable without team keys
Restore backup into current store	Restore backup into another supported backend
Restore only replaces matching files	Refuse another team's backup by identity
Explicit override for cross-team restore	Move entire live team to another storage provider
Git → S3 / R2 migration	S3 / R2 → Git migration
S3 ↔ GCS / Azure migration	SSH / WebDAV / Sonda Server migration
Copy destination completely before redirecting clients	Signed / encrypted relocation record in old store
Relocation target wrapped separately for members	Members automatically follow team move on next sync
No manual client reconfiguration after store move	Repository provider can change without rebuilding Projects
Storage backend is not permanent team identity	No vendor-storage lock-in: projects stay on your side

1,610 capabilities. Each one checked against the code that ships.

Every area, with its count.

Protocols · 74

Kafka · 21

RabbitMQ · 24

NATS · 36

AMQP 1.0 · 32

Redis · 31

FIX · 43

HL7 v2 / MLLP · 35

STOMP brokers · 28

MCP · 33

SOAP & RPC · 24

Industrial: the shared core · 20

Modbus · 19

OPC UA · 17

HART-IP · 21

DDS · 32

Workspace & scripting · 27

Runner view · 9

Collaborative workspaces · 10

Cross-division workspace sharing · 11

Authentication · 13

Network · 3

Checks & runner · 19

Load testing · 29

Flows · 73

Orchestration: apps over your APIs · 40

Functions · 16

Watchers · 17

App runners · 23

Via / remote execution · 19

FHIR & OData · 59

Echo & databases · 33

Response engineering · 65

Discover · 49

Specs, imports & docs · 34

Git & local-first · 24

Account isolation & correctness · 25

Collaboration & repositories · 57

Sonda Server · 31

Organizations & divisions · 43

Organization administration · 13

Organization service catalog · 10

Organization licensing · 8

RBAC & enterprise identity · 87

Member lifecycle & access · 13

Secrets · 41

Themis AI · 49

Component locking · 22

Structured merge & conflicts · 25

Change governance & approvals · 49

Notifications & activity · 41

Activity log · 9

Repository portability · 24

Free forever, up to 20 seats. Every line above included.