How the inbound matching process works
How the Inbound Matching process works
The inbound matching API takes an inbound message and attempts to match it to an existing record inside BodyShop Booster, usually via the customer cellphone number. If we are able to do that, we will store the value for id sent inside the repair object of the message combined with the API key (API code) used to send that message.
API codes are used when creating an API key inside the Booster admin to allow multiple keys to update the same record. See Guide to Creating an API key as a BodyShop Booster Customer
Future messages with the same API key / code and value for id will update the same record, unless that causes a conflict with another existing record.
If we are not able to match the message content to an existing repair record, we will either create a new record (for example if the customer’s phone number is previously unknown), create a ‘Decision Needed’ item for the repairer to resolve manually, or if we can identify the customer, but not the specific repair, we put a message in a ‘General Messages' section for the CRM user to view and resolve. Note that this only needs to be done the first time we receive the payload - once we have stored the external GUID against the specific repair record we always route future updates on the same external GUID to the same place without needing manual intervention.
BodyShop Booster does not have different types of record at different 'stages' like assignment, estimate, repair etc - there is a single Repair Record throughout the process.
That means your guid / the value you send for id should be consistent throughout the entire lifecycle.
This flow diagram shows how the full inbound matching process works. It is not necessary to understand this to implement the API - simply send the data and we’ll make sure it gets routed correctly on our end! It is included here for reference only.