Integration concepts

A manufacturing ERP is never alone: orders arrive from an online store or a customer’s EDI, and accounting lives in another tool. Every re-entry between these systems is time lost and a source of discrepancies. Integrations exist so data is entered only once. This documentation covers several families of tools: e-commerce, ERP, accounting, EDI, e-invoicing and no-code tools. Four principles are common to all of them, whatever the tool plugged in.

​

1. Every piece of data keeps its origin

For each synced record, Bonx retains which integration it came from and under which reference it is known there. That link is kept separately, so the same record can be known to several tools under a different reference in each. This is what makes syncs idempotent: replaying an import does not create a duplicate, it finds and updates the existing record. It is also what lets you tell, from a Bonx record, where it came from.

​

2. Who owns the data

This is the trickiest part of any integration, and the one that does the most damage when left implicit: if two systems can edit the same article, which one wins? Bonx settles it with an explicit setting, per integration and per entity type. For each pair, you designate the owner: Because the setting is per entity type rather than global, you can leave the ERP in charge of articles while staying in charge of orders and invoices. That is what makes the hard case workable, an article master shared across several systems, without two tools fighting over the same record. Two practical consequences:

• Nothing syncs by default. A freshly created integration touches no data until an administrator has designated an owner, entity type by entity type.
• A manual push overrides it. Pushing a record by hand works even on a type the connected tool owns, to unblock a specific case. It is the only exception to the rule, and it is logged.

​

3. Security and secrets

Bonx connects with the most secure method the target tool offers: OAuth where it exists, otherwise an API key, dedicated credentials or a file drop. The detail is on the authentication methods page. Tokens, keys and credentials are encrypted at rest with an encryption key dedicated to your instance, managed by a key management service and rotated periodically. They are never readable back once saved, including through the API: they can be replaced, not consulted.

​

4. When a sync runs

Depending on what the connected tool allows:

• Periodically. This is the baseline mode. The most recent connectors let you set the interval per integration, from a few minutes to once a day; the others run once a day.
• On demand, by triggering a sync from Bonx.
• At a process step, when a document reaches a step that must be pushed to the tool, for example a validated invoice. This is how a single record is synced without waiting for the next cycle.

Every run is logged: what was processed, what was rejected and why. A rejected record is kept with its reason, to be fixed and replayed rather than lost in silence.