Reference · built on requestConnectorStreams, queues & webhooks

NATS

Messages on NATS subjects and JetStream streams, with Key Value and Object store reads, through NATS client protocols.

Request accessPricing ↗

About

NATS is a messaging system maintained by Synadia. Core NATS delivers a message to every subscriber of a subject that is connected at the moment of publish, at most once, with no broker queue and no acknowledgment. Subjects are dot-delimited, and subscriptions match with the * and > wildcards. Queue groups hand each message to exactly one member. Request-reply rides on _INBOX subjects with a no-responders signal. JetStream adds server-side stores: a stream bound to subjects with a Limits, Interest, or WorkQueue retention policy, and consumers that track how far a client has read and redeliver a message that is not acknowledged in time.

Through Fibric, an operator reads from a durable JetStream consumer or a core subscription and proposes a publish or a request for your approval.

This is a reference listing. It documents what Fibric would read from NATS and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Messages on the subjects you name, subscribed with * for one token and > for the tail of a subject
  • Messages held in a JetStream stream, pulled by a durable consumer in batches with fetch or as a flow with consume
  • Stream configuration: subjects, retention policy, File or Memory storage, replica count, and the message, byte, age, and size limits
  • Consumer position within a stream, and the count of messages delivered but not yet acknowledged, capped by MaxAckPending
  • Entries in a JetStream Key Value store, which has built-in replication and durability
  • Objects in a JetStream Object store, stored as chunks with per-object metadata
  • Replies to a request, or the no-responders signal when nothing is listening

Proposed actions

  • Target capability: propose publishing a message to a subject, with a Nats-Msg-Id header so a stream turns away a duplicate for two minutes
  • Target capability: propose sending a request on a subject and recording the reply or the timeout
  • Target capability: propose putting a value under a key in a Key Value store

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Watch device heartbeats for silence

    Sensors publish to subjects such as site.room.sensor. The operator subscribes with a > wildcard, tracks the last message per subject, and reports the sensors that go quiet.

    With Sensor Health

  • Drain a work queue without losing a job

    A WorkQueue stream holds jobs from a line system. A durable consumer pulls in batches and acknowledges each after the operator records it. Unacknowledged jobs come back.

    With Integration Health, Data Freshness

  • Ask a service for state on demand

    The operator proposes a request on a subject and waits for the reply. A no-responders signal tells it the service is down before a person is paged.

    With Vendor Outage

Requirements

  • A reachable nats-server, or cluster, on its client listener
  • A user entry with publish and subscribe permissions on the subjects the connector uses. A fresh user can reach every subject until rules are set
  • JetStream enabled, with a stream bound to the subjects you want kept, for any read that must survive a disconnect
  • A durable consumer name reserved for this connector, so its position persists between runs
Authentication
A per-user credential on the nats-server: username and password, an NKey whose private seed signs a server nonce, a TLS client certificate mapped to a user, or a decentralized JWT under an account; a shared token is also accepted but cannot be per-user.

Limits

  • Core NATS is at-most-once. A message reaches only the subscribers connected when it is published
  • JetStream is at-least-once. A message not acknowledged in time is redelivered, so the operator must tolerate a repeat
  • Only one stream can keep a given subject, and Memory storage is lost when the server restarts
  • A stream's default is Replicas 1, on one server. Durability across a server loss needs 3 or 5 replicas

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request NATS ↗

Questions and answers

What is the delivery guarantee?
Core NATS is at-most-once: fire-and-forget publish with no storage. JetStream is at-least-once: the server stores messages in a stream and a consumer redelivers a message that is not acknowledged in time. A Nats-Msg-Id header makes a stream turn away a duplicate for two minutes.
How do wildcards work in a subscription?
Subjects are dot-delimited tokens. The * wildcard matches one token, so orders.*.created matches orders.eu.created. The > wildcard matches one or more trailing tokens, so orders.> matches everything under orders.
Which credentials can the connector present?
Username and password, an NKey (the server holds the public key and the client signs a nonce), a TLS certificate mapped to a user, a JWT under an account, or a shared token. Permissions then limit which subjects the user may publish to and subscribe from.
Ask about NATS

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with NATS through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy