Integratec API Platform


The Integratec platform is modular and service-oriented, capable of distributing your workload across a flexible and highly scalable network of dedicated processing power.

The Integratec API enables you to connect to the platform, create service requests, and get the return from anywhere on the network. This interface gives you the tools necessary to create your own custom interface or automated process around the services we provide.


Features are broken into individual services, which expose functionality to you via requests made with the API. They generally consist of business logic, such as import or export, but in some cases can also be used to reconfigure the platform itself via the API.


Each unique component in the Integratec platform is referred to as a Module. Below is a list of modules, and the categories or type of module that they are:

  • Client API
  • Master
  • Workers
    • Essentials
    • Presort
    • Reporting
    • Data Marketing Services
    • Address Standardization
  • Control
    • Hub
    • Node


The following diagram illustrates the modules' relationship to one another:

Module Relationships

Client API

This module consists of our base library (cdecl calling convention), which exports the functions and callbacks necessary for using the Integratec platform. The functions themselves are covered in much greater detail in the Getting Started section of this guide.

For your convenience, this module also comes with wrappers written for additional languages, such as C# or Python.


This module is at the very center of the service-oriented side of the Integratec platform. The Client API and all Worker modules must connect, authenticate, and register with the Master in order to become active on the platform. Once active, requests generated by the API are passed through the Master to the waiting Workers able to process them.

The Master process also manages the persistent jobs database, and exposes a few services of its own that allow API consumers to reconfigure or get information from the Master while it is running.


These modules are responsible for doing the actual work for service requests generated by the Client API. They contain a configurable number of dedicated worker threads. Each thread can process only one request at a time, thus limiting the amount of concurrent work each worker module is capable of performing.

For example, you could have four worker threads in a single running worker module, or you could start a worker module four times, each containing a single worker thread. The latter is particularly useful if you intend to spread your workers across additional machines/hardware across a network.

Each worker thread type has a set limit of connections to your Master, a number that is determined by your licensing options.

  1. Essentials Module

    This module handles all the things that the other modules don't want to do themselves, such as: importing, exporting, modifying database records, etc.

  2. Presort Module

    This module is responsible for taking a list of addresses and presorting them to provide the best discount for shipping via the United States Postal Service.

  3. Reporting Module

    This module takes a presorted list and generates the USPS reports and other output files for shipping.

  4. Data Marketing Services Module

    This module provides access to BCC Software's Data Marketing Services, a suite of services to validate, enhance and update your address data.

  5. Address Standardization Module

    This module uses CASS and NCOALink certified software to update and standardize your address data by matching it against USPS data.

Control Services

These modules are services or background processes configured to manage the on/off state of distributed modules across a network.

  1. Hub Service

    This module receives start or stop commands from the Client API and forwards them to all Node services.

  2. Node Service

    This module receives start or stop commands from the Hub service and starts or stops a list of registered processes.


There are two versioning systems for the Integratec product: Release and Module.

For a detailed look at the changes in the Integratec API Platform from version to version, see the changelog page.

Release Version

The release version is tied to a dated release of a collection of modules, each with their own module version. The Integratec release version number format will be Year.Revision. For example, "16.3" is equivalent to the 3rd release of the year 2016.

Year: 2-digit year; increments by 1 with the date

Revision: 1-base value that increments with each release within the year

Module Version

The Integratec entities below each have separate version numbers but use a common version numbering system.

  • Client API
  • Master
  • Worker Modules
  • Control Services

The Integratec version number format is Product.Compatibility.Revision and applies to all Integratec entities. Note the Presort and Reporting libraries, which underpin their respective worker modules, continue to use their own version number systems (AA.BB.CC.DD) which is independent of Integratec.

Product: increments by 1 for significant changes

  • New product versions will most likely be backwards incompatible

Compatibility: increments by 1 for interface changes

  • Modules affected by an interface change are required to update to the same compatibility version
  • New compatibility versions will most likely be backwards incompatible

Revision: increments by 1 for any change, e.g., new feature, bug fix

  • New revisions may or may not be backwards compatible


The Integratec platform can be configured to utilize Curve25519 messaging encryption, made possible via the underlying ZeroMQ-based communications layer that Integratec uses.

Note: Integratec provides no encryption for "data at rest".

Pairs of public and private encryption key files are necessary for enabling the messaging encryption. A default installation comes with a key pair for use by Client APIs and the various workers, as well as a private key unique to the Master.

The Master installation includes a /credentials folder, where the public key files for any connecting Client APIs or Workers must be stored.

IMPORTANT: The responsibility for securing these keys, moving them across your network, etc. is yours alone.

The following example illustrates this for a distributed installation:

Distributed Install Key Setup

Alternatively, you could install the Client API, Workers, and Master all on one machine and still encrypt the local TCP traffic:

Single Machine Install Key Setup

Known Issues

Important: The computer may stop responding, with the only means of recovery being a hard reset. This is caused by a defect in the Windows Filtering Platform API which is documented in Microsoft KB article 2664888. Install the preventative hotfix if you know (or are unsure of) the Filtering Platform API is in use on your systems. The preventative hotfix is also available for download from Microsoft.