NCR Counterpoint Connections and Settings

The NCR Counterpoint integration connects an on-premises NCR Counterpoint installation to iPaaS.com, allowing customers, products, inventory, categories, locations, shipping and payment methods, gift cards, and transactions to move between Counterpoint and the other systems in a subscriber's integration.

Counterpoint runs on the subscriber's own server rather than in the cloud, so connecting it to iPaaS.com involves two locally installed components: the CPHive web service, which iPaaS.com calls to read and write Counterpoint data, and the CPWebhooks service, which watches the Counterpoint database and notifies iPaaS.com when records change. Both must be installed and reachable before the settings on this page will validate. See the NCR Counterpoint Installation Instructions for how to install them.

Before configuring the subscription in iPaaS.com, subscribers or their MiSP need the following in place:

Both installation steps are covered in the NCR Counterpoint Installation Instructions.

The connection is made up of three settings. All three must be filled in before the subscription will save, though only the first two affect whether it can transfer:

The integration identifies itself to the CPHive web service with the CP Api Username saved on the subscription, and holds a token that CPHive issues in return. There is no interactive sign-in step and no consent screen: the value is entered once on the subscription and used for every subsequent transfer.

The protection around CPHive is where it is published, not this exchange. CPHive runs on the subscriber's own server and reads and writes the Counterpoint database directly, so the controls that matter are the certificate on its address and the restriction of inbound traffic to the sources that need to reach it. Subscribers or their MiSP should confirm both are in place before go-live — see the NCR Counterpoint Installation Instructions.

When the connection is tested, the integration reads the company record from Counterpoint and returns the company name it found. A successful test confirms two things at once — that the CPHive service is reachable at CP Api Url, and that CPHive can read the Counterpoint database it is pointed at.

If the test fails, it is usually one of the following:

Connection and transfer errors surface at Dashboard / Integration Monitoring / Error Logs.

Navigate to the NCR Counterpoint subscription settings in iPaaS.com and provide the following. Name and Versions are standard subscription fields; the remainder are specific to this integration.

Inventory Qty Method determines how the integration calculates the available quantity it reports for a product. It offers three values and is pre-populated with A single location:

Inventory Qty Method must not be left empty. Clearing it causes the quantity calculation to fail with an error rather than falling back to a default.

Inventory Location is required whenever A single location or All locations in a location group is selected, because both read it to decide which location or group to report from. If either is selected and Inventory Location is empty, the quantity calculation fails with an error naming the setting. All locations does not use it.

Inventory Qty Method and Inventory Location are read wherever a mapping uses the quantity-from- settings formula, and they change the quantity that mapping reports. They are the only two settings the integration itself acts on.

The remaining optional settings — First Order Date, Store, Drawer, Station, User, Template Customer, Default Customer, Next Customer, Tracking #s in CP, Qty Stock Threshold and Item Description From — behave differently, and it is worth understanding why before relying on them.

At the time this documentation was written, these settings are not read by the integration on their own. Saving a value in Store, for example, does not by itself cause that store id to appear on transactions. The mapping collections that ship with this integration supply values such as the store, station and drawer as fixed values on the mapping itself, not from these settings.

What these settings do provide is a place to hold an installation-specific value that a subscriber's own Dynamic Formulas can then read, using the Setting function. This makes them useful as a single point of configuration: a value is entered once on the subscription and referenced from any mapping that needs it, instead of being repeated across mappings. For how to reference a setting from a formula, see the Setting function in Functions.

Subscribers who expect one of these settings to take effect without a corresponding mapping change should validate the behavior in a staging environment first.

Some entities in this integration offer an initialization option, which is intended to load every existing record of that type from Counterpoint in bulk rather than transferring them one at a time. The option is presented for the following:

Initialization is supported for each of these, and loads that entity's existing Counterpoint records into iPaaS.com in one operation. It is the intended way to populate reference data when a subscription is first set up, rather than transferring those records one at a time.

Initialization is not offered for products, customers, inventory or transactions. Those are brought in through their own collections — using Manual Sync, which is available on every mapping collection, for a first load. Once the corresponding trigger events are enabled, subsequent changes transfer automatically.

NCR Counterpoint does not impose its own API rate limits — CPHive runs on the subscriber's own server, so the practical limit is the capacity of that server and its database rather than a published quota. At the time this documentation was written, this integration does not expose throttle settings on the subscription. For the throttling and concurrency options available at subscription level, see Subscription Configuration – Edit.

The absence of a rate limit is not the same as unlimited capacity. Because Counterpoint is a live retail system, large transfers compete with point-of-sale activity on the same database. Subscribers or their MiSP should schedule large or historical data loads outside trading hours, and avoid running several intensive jobs at the same time. For guidance on large transfers, see Best Practices for Syncing Large Data Sets in iPaaS.com.