Integrating R-COM Gateway with External Services

R-COM Gateway can exchange data with external systems through REST APIs and MQTT messaging. These integration options allow external applications, IoT devices, RFID readers, barcode scanners, ERP systems, WMS platforms, and cloud services to send data into the gateway or receive data from the gateway.

This article gives a high-level overview of how data can move into and out of R-COM Gateway. It does not replace the dedicated configuration guides for REST API endpoints, MQTT clients, authentication, MQTTPublisher, MQTTChallengeResponse, or SetHttpResponse. Instead, it connects those features into one practical integration model.

Integration Overview

External system integration usually falls into two categories:

Direction	Meaning	Common Methods
Data into R-COM Gateway	External systems, devices, or services send data to the gateway for processing	REST POST/GET, MQTT topic subscription
Data out of R-COM Gateway	External systems request or receive data from the gateway	REST GET with SetHttpResponse, MQTT publish actions, WebRequest action.

R-COM Gateway supports both push-based and pull-based patterns. The correct approach depends on the external system, the required response behavior, and whether communication should be real-time, event-driven, or request-based.

Getting Data into R-COM Gateway

External systems can send data into R-COM Gateway using REST API endpoints or MQTT topics.

Option 1: Push Data Using REST API POST/GET Endpoints

A REST POST/GET endpoint is the most direct way for an external system to send data into R-COM Gateway.

In this model, R-COM Gateway exposes a dedicated HTTP endpoint. The external system sends a request body, usually in JSON format, to that endpoint. The gateway then processes the payload based on the configured route, event type, and workflow logic.

Typical use cases include:

• Barcode scan ingestion
• RFID tag read ingestion
• Inventory updates
• Device telemetry
• Sensor events
• ERP or WMS event notifications

Example:

POST https://rcom-gateway.example.com/RCOMENDPOINTAPI/inventory/productScanPost
Content-Type: application/json
Authorization: Bearer <token>

Example payload:

{
  "deviceId": "scanner-001",
  "barcode": "1234567890",
  "timestamp": "2026-06-22T10:15:00Z"
}

When the endpoint receives the request, R-COM Gateway maps it to the configured event type and forwards it into the relevant processing flow.

Use REST POST when the external system can actively send data to R-COM Gateway and expects a standard HTTP response such as 200 OK or 202 Accepted.

For setup details, refer to the dedicated REST API Endpoint Configuration article.

Option 2: Push Data Using MQTT Topics

MQTT is useful when devices or services publish frequent event messages to a broker. R-COM Gateway can connect to the broker as an MQTT client and subscribe to selected topics.

In this model, the external device or system publishes messages to an MQTT topic. R-COM Gateway listens to that topic and processes each message as an internal event.

Example topic:

factory/readers/line-1/tag-events

Example message:

{
  "readerId": "reader-001",
  "epc": "300833B2DDD9014000000001",
  "antenna": 1,
  "timestamp": "2026-06-22T10:15:00Z"
}

Typical use cases include:

• RFID reader events
• Barcode scanner events
• IoT sensor telemetry
• Machine status updates
• Real-time shop-floor events

MQTT is especially useful for high-frequency, event-driven communication where external devices already publish messages to a broker.

R-COM Gateway MQTT configurations define:

• Broker connection details
• Client ID
• Authentication credentials
• TLS settings
• Subscribed topics
• QoS level
• Event type mapping
• Payload type

Use MQTT ingestion when devices or services publish event streams and R-COM Gateway needs to process them in real time.

For setup details, refer to the dedicated MQTT Client Configuration article.

Getting Data out of R-COM Gateway

R-COM Gateway can send data to external systems or return data when external systems request it.

There are three common models:

• R-COM Gateway actively sends MQTT messages out.
• R-COM Gateway actively calls external HTTP/HTTPS services.
• External systems request data from R-COM Gateway.

Option 1: Push Data Out Using MQTT Publish Actions

R-COM Gateway workflows can publish messages to MQTT topics using the MQTTPublisher action.

In this model, a workflow runs inside R-COM Gateway and sends a message to a configured MQTT broker topic. External systems, devices, or services that subscribe to that topic can consume the data.

Example topic:

factory/gateway/inventory-updates

Example payload:

{
  "productId": "123456",
  "status": "available",
  "quantity": 42,
  "updatedAt": "2026-06-22T10:20:00Z"
}

Typical use cases include:

• Sending processed scan results to another system
• Publishing inventory updates
• Sending device commands
• Notifying downstream services
• Triggering automation in an external platform

The MQTTPublisher action allows you to define:

• MQTT client configuration
• Target topic
• QoS level
• Payload
• Optional response wait behavior
• Timeout value

Use MQTT publishing when R-COM Gateway needs to actively send messages to external MQTT consumers.

For setup details, refer to the dedicated MQTTPublisher action documentation.

Option 2: Use MQTT Challenge-Response for Request/Reply Flows

For workflows that require a response from another MQTT-based system, R-COM Gateway can use the MQTTChallengeResponse action.

This action publishes a request message to one topic and waits for a response on another topic.

Example flow:

R-COM Gateway publishes request:

factory/device/request

External system responds:

factory/device/response

Typical use cases include:

• Device handshakes
• Synchronous validation
• External confirmation before continuing a workflow
• Requesting status from an MQTT-connected system

Use this model when R-COM Gateway must send a request and wait for a reply before the workflow continues.

For setup details, refer to the dedicated MQTTChallengeResponse action documentation.

Option 3: Push Data Out Using the WebRequest Action

R-COM Gateway workflows can also send data directly to external HTTP or HTTPS services using the WebRequest action.

In this model, R-COM Gateway acts as the HTTP client. A workflow prepares the required data and sends it to an external API endpoint using a configured HTTP method such as POST, PUT, GET, or DELETE.

This is useful when the external system exposes a REST API and expects R-COM Gateway to call it directly.

Example:

POST https://external-system.example.com/api/inventory/update
Content-Type: application/json
Authorization: Bearer <external-system-token>

Example payload:

{
  "productId": "123456",
  "status": "available",
  "quantity": 42,
  "source": "Gateway"
}

Typical use cases include:

• Sending processed workflow results to an ERP, WMS, MES, or cloud platform
• Posting scan results to an external API
• Updating inventory or object status in another system
• Calling webhook URLs
• Triggering external automation services
• Sending alerts, confirmations, or event notifications over HTTP

The WebRequest action allows you to define:

• Request URL
• HTTP method
• Request headers
• Cookies
• Request content type
• Payload data
• SSL bypass behavior
• Response wait behavior
• Timeout value
• Success response code ranges
• Retry count and retry delay
• Variables for storing response body and response headers

If AWAIT_RESPONSE is enabled, the workflow waits until the external service responds or the configured timeout is reached. If READ_RESPONSE_MESSAGE is enabled, the response body can be stored in a workflow variable for later use.

Use the WebRequest action when R-COM Gateway needs to actively call an external REST API or webhook.

For setup details, refer to the dedicated WebRequest action documentation.

Option 4: Expose Data Using REST GET Endpoints

External systems can request data from R-COM Gateway using REST GET endpoints.

In this model, the external system calls a configured HTTP GET route. A workflow processes the request, retrieves or prepares the required data, and returns the response using the SetHttpResponse action.

Example request:

GET https://rcom-gateway.example.com/RCOMENDPOINTAPI/inventory/status?productId=123456
Authorization: Bearer <token>

Example response:

{
  "productId": "123456",
  "status": "available",
  "quantity": 42
}

The SetHttpResponse action defines what the external client receives, including:

• HTTP status code
• Response headers
• Content type
• Response body

Typical use cases include:

• Returning inventory status
• Validating a barcode or RFID tag
• Returning object details
• Providing workflow result data
• Exposing processed gateway data to another application

Use REST GET with SetHttpResponse when an external system needs to request data from R-COM Gateway on demand.

For setup details, refer to the dedicated REST API Endpoint Configuration and SetHttpResponse documentation.

Authentication for REST Integrations

REST endpoints can be protected using authentication.

R-COM Gateway supports different authentication options depending on the endpoint configuration, including:

• No authentication, mainly for testing
• Basic authentication with mapped external users
• Access Tokens authentication for protected access

For production integrations, protected endpoints should use Access Tokens or Basic authentication. External applications can authenticate through

• External User for Basic Auth
• Configured Access Token-based authentication
• External Login API and then include the returned token in subsequent requests.

Example with external login:

Authorization: Bearer <Token>

The general authentication flow is:

1. External application sends credentials to the external login endpoint.
2. R-COM Gateway returns an access token and a refresh token.
3. The external application includes the token in protected API requests.
4. When the token expires, the external application uses the refresh token flow to obtain a new token.

tip

For setup details:

• External Users In R-COM Gateway
• Bearer/Access Token Enabled Endpoints in R-COM Gateway
• External Login via API

Choosing the Right Integration Method

The best integration method depends on how the external system communicates and what kind of data exchange is required.

Requirement	Recommended Method
External system sends occasional structured data	REST POST endpoint
Devices publish frequent real-time messages	MQTT topic subscription
R-COM Gateway sends event data to MQTT consumers	MQTTPublisher action
R-COM Gateway sends a request and waits for an MQTT response	MQTTChallengeResponse action
R-COM Gateway actively calls an external HTTP/HTTPS API	WebRequest action
External system requests data from R-COM Gateway	REST GET endpoint with SetHttpResponse
External system needs secured API access	External Login API with bearer token

Common Integration Patterns

Pattern 1: Device-to-Gateway Event Ingestion

A device publishes scan or sensor data to an MQTT broker. R-COM Gateway subscribes to the topic, receives the event, and starts a workflow.

Device → MQTT Broker → Gateway → Workflow

Use this for RFID readers, barcode scanners, BLE sensors, and industrial devices.

Pattern 2: External System-to-Gateway API Ingestion

An ERP, WMS, or custom application sends data to a REST POST endpoint. R-COM Gateway receives the payload and processes it.

External System → REST POST → Gateway → Workflow

Use this for inventory updates, master data synchronization, status changes, or event notifications.

Pattern 3: Gateway-to-External MQTT Publishing

A workflow processes data and publishes the result to an MQTT topic. External systems subscribe to the topic and consume the message.

Workflow → MQTTPublisher → MQTT Broker → External Subscriber

Use this for event notifications, processed scan results, or device commands.

Pattern 4: Gateway-to-External HTTP API Call

A workflow processes data and sends it to an external REST API using the WebRequest action.

Workflow → WebRequest → External HTTP/HTTPS API

Use this when R-COM Gateway needs to push data to an ERP, WMS, MES, webhook, cloud service, or custom external application over HTTP.

Pattern 5: External System Requests Data from Gateway

An external application calls a REST GET endpoint. R-COM Gateway processes the request and returns a structured response using SetHttpResponse.

External System → REST GET → Gateway Workflow → SetHttpResponse → External System

Use this for status queries, object lookups, validation checks, and on-demand data retrieval.

Best Practices

• Use REST POST for structured request-based ingestion and MQTT for real-time event streams.
• Use secure authentication for production REST endpoints. Avoid unauthenticated endpoints except during testing.
• Use TLS for MQTT broker connections when sending sensitive or production data.
• Use WebRequest when the gateway must actively call an external HTTP/HTTPS API.
• Use retries and timeout values carefully in WebRequest actions to avoid long workflow delays.
• Avoid bypassing SSL verification in production unless there is a controlled and documented reason.
• Keep route names and topic names clear, consistent, and purpose-specific.
• Use asynchronous REST processing for high-volume ingestion where the caller does not need to wait for full processing.
• Use synchronous REST processing when the caller requires an immediate validation result or response body.
• Use SetHttpResponse whenever a REST GET endpoint or web-triggered workflow needs to return structured data to the caller.
• Use suitable MQTT QoS levels. Higher QoS improves delivery guarantees but adds more overhead.
• Validate payload formats before going live. Event type and payload type must match the expected gateway processing logic.