Connects to your ERP, DMS and CRM

Explained

Why integration decides whether a channel program works

A loyalty or incentive program is only as good as the data it runs on. Schemes need purchase data to calculate earnings. Claims are easier to verify when they can be matched to orders. Payouts need verified identities and bank details. If each of these lives in a different system with no connection, teams fill the gaps with spreadsheets and manual uploads, and errors creep in.

IMAST 360 approaches this in two layers. Inside the platform, the products share data natively: Distribution+ purchase data flows into LoyaltyBoard for scheme calculation, Sales Track field reps enrol and support partners, and LoyaltyBoard points redeem through Reward Max. There is no middleware to build between IMAST products.

Outside the platform, IMAST connects to the systems you already run. Pre-built connectors cover SAP, Salesforce, Tally, Shopify, Zoho, Paytm, Razorpay and more, and a documented REST API handles anything else. Most integrations go live within the first week.

Inside IMAST 360

Native connections between products

No middleware between IMAST products.

Outside IMAST 360

Connect the systems you already use

Pre-built connectors plus APIs for everything else.

Best practice

Planning an integration that lasts

Start with the decisions the data has to support. If schemes are calculated on secondary sales, the order data has to arrive daily, not monthly. If claims are matched to invoices, both sides need the same identifiers for partners and products.

Agree on a system of record for each type of data — partners, products, orders, payouts — so there is one source of truth and no conflicting copies. Test with real records before go-live, and plan who owns the integration once it is running.

Where an IMAST product can do the job natively, prefer it to a custom connector. Native connections between Distribution+, Sales Track, LoyaltyBoard and Reward Max need no separate maintenance.

• Map which records move, how often, and in which direction
• Use the same partner and product IDs across systems
• Test with real data before go-live
• Name an owner for each integration

Data ownership

Which system should own which data?

Most integration problems come from two systems both believing they own the same record. Before connecting anything, agree on a single source of truth for each type of data — for example, your ERP owns product and price masters, Distribution+ owns secondary orders and stock, and LoyaltyBoard owns points and redemptions.

Once ownership is clear, data flows one way for each record type, and the receiving system treats it as read-only. That avoids duplicate partners, mismatched prices and points calculated on the wrong numbers.

Keep a short integration log: which systems connect, what moves, how often and who to call when something breaks. It costs little to maintain and saves days when a team member changes or a new system is added.

• One owner per record type
• Data flows one way for each record
• Receiving systems treat it as read-only
• Keep a simple integration log