REST-Side Configuration (Enterprise)

The REST-side handles multiple remote modems and is responsible for:

• Polling the satellite provider API (e.g., Inmarsat IoT Nano, Viasat).
• Forwarding payloads into the MAPS namespace.
• Optionally running in bridge mode for raw byte[] forwarding.

Example Configuration

This example is used when receiving data from a remote MAPS server and remote anonymous clients

    - name: "inmarsat IoT interface"
      auth: anon
      protocol: satellite
      url: satellite://inmarsat:0/


      # Rest Server Config
      baseUrl: "http://localhost:8085/iotMessaging/v1"
      mailboxId: "mailbox-001"
      mailboxPassword: "mailbox-secret"

      remoteAuthConfig:
        username: "ogws client id"
        password: "ogws client secret"
        
      # Timeouts
      incomingMessagePollInterval: 10
      outgoingMessagePollInterval: 30
      httpRequestTimeoutSec: 30

      # Maps message package config
      bridgeMode: false  # if true Maps will NOT parse the icoming data
      sharedSecret: "This is a shared secret to use"
      maxInflightEventsPerDevice: 2

      # Namespace mapping
      outboundNamespaceRoot: "/inmarsat/{deviceId}"
      outboundBroadcast: "/inmarsat/broadcast"
      namespaceRoot: "/{mailboxId}/{deviceId}/{sin}"
      inboundNamespaceRoot: "/incoming/{deviceId}/{sin}/{min}"

This example is used when receiving data remote anonymous clients

- name: "Inmarsat pub/sub interface"
  protocol: satellite
  auth: anon
  url: satellite://inmarsat:0/
  httpRequestTimeoutSec: 30
  incomingMessagePollInterval: 15
  outgoingMessagePollInterval: 60
  maxInflightEventsPerDevice: 2
  outboundNamespaceRoot: "/inmarsat/{deviceId}"
  outboundBroadcast: "/inmarsat/broadcast"
  inboundNamespaceRoot: "/incoming/{deviceId}/{sin}/{min}"
  baseUrl: "http://localhost:8085/v1"
  remoteAuthConfig:
    username: "demo-user"
    password: "demo-password"

  mailboxId: "mailbox-001"
  mailboxPassword: "mailbox-secret"
  namespaceRoot: "/{mailboxId}/{deviceId}/{sin}"
  bridgeMode: true

---

Key Configuration Parameters

Key Fields

Field	Description
bridgeMode	If true, MAPS does not parse/transform events. Payload is sent as opaque byte[] and published as-is. Default: false.
namespaceRoot	Where inbound events are published. {mailboxId} and {deviceId} are automatically substituted and {sin} is extracted from the incoming message. This is only used when in bridgeMode and no topic names are supplied from the remote end
inboundNamespaceRoot	Namespace root for common message responses to be published to
outboundNamespaceRoot	Topic root for uplink events per-device.
outboundBroadcast	Topic for broadcast uplinks.
baseUrl	REST API base URL of the satellite provider.
incomingMessagePollInterval	Poll frequency (sec) for incoming mailbox messages. Min: 10.
outgoingMessagePollInterval	Flush frequency (sec) for uplink messages. Min: 15.
sharedSecret	Optional shared key for lightweight auth.
maxInflightEventsPerDevice	Limit for queued events per device before backpressure.
httpRequestTimeoutSec	HTTP request timeout (sec).
mailboxId / mailboxPassword	Provider mailbox credentials.
remoteAuthConfig	Credentials for the REST API (if required).

---

Token Substitution

MAPS automatically replaces tokens in namespace paths:

• {mailboxId} → resolved from config.
• {deviceId} → resolved from inbound/outbound message metadata.
• {sin} → The SIN supplied with the message
• {min} → The MIN supplied with the message

Example:

namespaceRoot: "/inbound/{mailboxId}/{deviceId}/{sin}"

If mailboxId = "mailbox-001" and deviceId = "device-abc", events publish under:
/inbound/mailbox-001/device-abc/…

If a {sin} is provided the server will replace the string with the messaging SIN number, useful if different SINs represent different event types

---

---

Defaults and Enforced Minimums

• incomingMessagePollInterval — must be ≥10s (defaults to 15).
• outgoingMessagePollInterval — must be ≥15s (defaults to 60).
• deviceInfoUpdateMinutes — must be ≥10 (defaults to 15).

---

Typical Use Case

REST-side integration is best for:

• Large-scale fleet management (hundreds → thousands of devices).
• Enterprise data aggregation without requiring GNSS/visibility.
• Bridging Inmarsat/Orbcomm REST APIs into MQTT / AMQP / NATS / REST within MAPS.

---

Polling Interval Timeline