Protocol

The Reverse Connections protocol defines the recommended sequence of operations that a daemon should follow when communicating with the Talk2sync platform.

This approach is designed for integrations where the external system is located behind a firewall, or where exposing a public integration layer is not desirable. The daemon can run on a server that has Internet access while continuing to communicate with the ERP, legacy database, or other internal application.

How the Protocol Works

The reverse connection workflow is based on a continuous daemon loop. The daemon periodically checks Talk2sync to determine whether the platform is requesting data from the external system or whether there are updates that need to be stored in the external system.

The overall process consists of four main stages:

  1. Check whether Talk2sync is fetching changes.
  2. Push products and orders when requested.
  3. Check whether Talk2sync is pulling changes.
  4. Pull products and orders and store them in the external system.

After processing the current synchronization activity, the daemon enters a sleep period before checking the Talk2sync platform again.

Protocol Operations

The protocol is divided into separate flows for products and orders.

Product Upload

The product upload flow is used when Talk2sync requests product information from the external system.

The daemon:

  1. Determines the timestamp from which products should be considered.
  2. Queries the external system for products.
  3. Transforms the products into the Talk2sync format.
  4. Sends products to Talk2sync in pages.
  5. Determines whether additional products remain.
  6. Finalizes the product push when all products have been processed.

See Product Upload for the complete flow.

Order Upload

The order upload flow follows the same general pattern as product upload, but operates on orders.

The daemon:

  1. Determines the timestamp from which orders should be considered.
  2. Queries the external system for orders.
  3. Transforms the orders into the Talk2sync format.
  4. Sends orders to Talk2sync in pages.
  5. Determines whether additional orders remain.
  6. Finalizes the order push when all orders have been processed.

See Order Upload for the complete flow.

Product Download

The product download flow is used when Talk2sync has products that must be inserted or updated in the external system.

The daemon:

  1. Checks whether products are available.
  2. Retrieves the next product.
  3. Transforms and stores the product in the external system.
  4. Reports whether the storage operation succeeded or failed.
  5. Waits until Talk2sync is ready for the next transaction.
  6. Continues until there are no more products to process.

See Product Download for the complete flow.

Order Download

The order download flow follows the same model as product download, but operates on orders.

The daemon:

  1. Checks whether orders are available.
  2. Retrieves the next order.
  3. Transforms and stores the order in the external system.
  4. Reports whether the storage operation succeeded or failed.
  5. Waits until Talk2sync is ready for the next transaction.
  6. Continues until there are no more orders to process.
  7. Finalizes the pull transaction.

See Order Download for the complete flow.

The complete reverse connection process can be represented as the following loop:

The daemon should continuously execute this loop. Each operation is responsible for completing its corresponding transaction before the daemon proceeds to the next stage.

Transaction Order

The order of operations is important because the reverse connection protocol uses Talk2sync connection states to coordinate the synchronization process.

A typical cycle follows this sequence:

Check fetch status
    ↓
Push products, if requested
    ↓
Push orders, if requested
    ↓
Check pull status
    ↓
Pull products, if requested
    ↓
Pull orders, if requested
    ↓
Sleep
    ↓
Check fetch status again

The individual operations are documented in the following sections:

Implementation Considerations

The reverse connection protocol is particularly useful when the external system cannot or should not expose a public HTTP interface. Instead, the daemon initiates communication with Talk2sync and performs the required synchronization operations.

The implementation should preserve the transaction order defined by the protocol and wait for the appropriate Talk2sync state before continuing to the next operation.

Next Steps

Start with the Protocol Overview to review the complete synchronization loop.

Then review the specific flows:

Last Updated: