Configuration
Authentication
Before performing any logical unit of work, an authentication token must be acquired and subsequently will be used by all other Web API methods in order to access and performed any operations in the system. All API requests must be made using a valid authentication token, otherwise such requests will fail
Acquiring an authentication token can be accomplished by using one of the following methods
- Web API Key
- Username & Password
Recommended Authentication Method
The recommended method of authentication is using Web API Keys of a "System Key" classification. Web API Keys are assigned to specific users in order to access a specific organization and can be used to authenticate users through Web API, resulting to an authentication token that can subsequently be used by other Web API calls, without any data restrictions
The authentication Web API call that should be performed is POST authentication/web_api_key/token (based on HTTP Basic Auth)
Web API Key Method Example
Using Fields Set
CRM.COM Web APIs offer the ability to select the fields that will be retrieved from each API method by specifying the "fields_set" input parameter
Using this parameter developers have the ability to filter the response object and retrieve only the fields that will be used for the desired implementation. If "fields_set" is not specified, then all fields of the response will be retrieved
The "fields_set" attribute is used for each call throughout the entire integration guide
Using Pagination
There are some API methods that retrieve a large number of entities, such as list API methods. Some of these CRM.COM API methods provide the option to apply pagination on the results retrieved
In such cases the API call should be constructed using the following input parameters
- number_of_results: The number of results that can be retrieved through each call. The maximum number of results can be 50, and objects are returned in chronological order (oldest requests are retrieved fist)
- offset: Defines the number of entities that should be skipped from the results. During the first call it should be set to 0 and then it should be increased based on the number of results that were retrieved
Integration Scenarios
Purchase and Spend Award Flow
The flow described below is an example of a POS integration with CRM.COM Rewards, including both purchase and spend transactions
Step 1 - Customer Identification | |||
No | Description | Web API Example | POS Conceptual Examples |
---|---|---|---|
1 | The customer is identified on the POS system by providing an identification mean. Such identification can be an email address, a phone number, a card number, etc
Identifying a customer in CRM.COM (also referred as rewards participant) should be performed using the POST rewards_participants/show method The following identification means can be used to identify a customer in CRM.COM
| POST Request https://hostname/crmapi/rest/v2/rewards_participants/show | Prior Customer Identification |
2 | Once a customer is identified in CRM.COM, then the full information of the customer is returned
The following information can be displayed on the POS screen
| After Customer Identification | |
Step 2 - Preview Award and Spend Information (Optional) | |||
No | Description | Web API Example | POS Conceptual Examples |
1 | Prior completing the sales transaction on POS, customer may request to know their available balance and the amount that are eligible to spend on the related transaction. In addition, the preview method will determine whether the purchase customer event that will be submitted can be redeemed by the Front-End System (i.e. POS) or by a Back-End System
Previewing such information should be performed using the POST customer_events/purchases/preview method, and the following information should be passed to CRM.COM
| POST Request https://hostname/crmapi/rest/v2/customer_events/purchases/preview | Not Applicable |
2 | Once a customer is identified in CRM.COM, then the full information of the customer is returned
The following information can be displayed on the POS screen
| After Preview
| |
Step 3 - Submitting Sales Transaction for Awarding Customer | |||
No | Description | Web API Example | POS Conceptual Example |
1 | Once all products are registered in the POS, the sales transaction should be submitted in CRM.COM in the form of a purchase customer event. Creating such customer event, CRM.COM will validate whether the purchased items are eligible to be awarded by a reward offer and credit the customer's wallet balance
Submitting a purchase event in CRM.COM should be performed using the POST customer_events/purchases/create method, and capture the following information
Products should already exist in CRM.COM in order for the POS to make transactions for them. In the event that a POS integration requires to perform transactions for such items, CRM.COM provides the ability to allow such transaction submission using a default product (everything is handled by CRM.COM without additional changes from the POS system) | POST Request https://hostname/crmapi/rest/v2/customer_events/purchases/create | Not Applicable |
2 | Once the sales transaction submission is performed (purchase customer event creation), the POS system can proceed to the redemption step
The following information can be displayed on the POS screen
| After Customer is Awarded | |
Step 4 - Redeeming Awarded Amount | |||
No | Description | Web API Example | POS Conceptual Example |
1 | Customer may want to spend some of the available wallet amount on the previously created transaction, submitting a spend customer event in CRM.COM
The following information can be displayed on the POS spend request form
Submitting a spend request in CRM.COM should be performed using the POST customer_events/spend_requests/create method, and capture the following information
| POST Request https://hostname/crmapi/rest/v2/customer_events/spend_requests/create | Spend Request Form |
2 | Once the spend request is performed, it will return back the actual amount that was spent, which might be different than the amount that was requested to be spend
The following information will be used in the next step of reducing and closing the sales transactions
| After Spend Request | |
Step 5 - Closing the sales transaction | |||
No | Description | Web API Example | POS Conceptual Example |
1 | Once the sales transaction (purchase customer event) and spend transaction (spend request customer event) are submitted successfully , then the POS system can calculate the redemption amount, reduce it from the total amount of the sales transactions, and close the sales transaction with the customer's payment
The redemption amount is calculated as the sum of the following attributes
The total_spend_amount is also the sum of total_instant_spend_amount, total_additional_spend_amount and total_automatic_spend_amount as retrieved by the "purchases/create" (all these three values are retrieved from the same method as well)
The calculated redemption amount is deducted from the POS sales transaction by applying a discount on the sales transaction
Upon completion, the following information is displayed and printed on the customer's receipt
| Not Applicable | Receipt |
Product Synchronization Flow
The flow described below is an example of synchronizing products from a POS system into CRM.COM
Product Synchronization can be achieved using existing CRM.COM Web API methods, where product information (as described previously) can be passed through a product parameter set
The maximum number of products that can be synchronized per call is 1,000
Step 1 - Synchronize Products | |||
No | Description | Web API Example | POS Conceptual Examples |
---|---|---|---|
1 | Product synchronization on a POS system can implemented as a batch process that is performed on a repeated basis (i.e. every day at 2 am), where product information is sent to CRM.COM
Submitting a product synchronization request in CRM.COM should be performed using the POST products/synchronise method, and capture the following information
The maximum number of products that can be synchronized per call is 1,000
| POST Request https://hostname/crmapi/rest/v2/products/synchronise | Not Applicable |
2 | Once the product synchronization request is submitted and upon completion processing from the CRM.COM, the following information is returned (and handled accordingly by the POS system)
| Not Applicable |