Flow of Integration Testing

This article explains the procedure of testing the APIs before requesting for sign-off of integration

Written By Ops UrbanPiper (Collaborator)

Updated at July 30th, 2020

The POS partner is advised to self-validate the testing of the APIs consumed before requesting the integration team for the final demo. If any below-mentioned pointers are found to be not covered, the sign-off will not be given. Please ensure the pointers are self-validated before requesting for the sign-off.

Technical Considerations

  1. Make sure the menu architecture lies within the federated structure. In other words, the master menu is maintained for a brand and all the menu catalogue entries such as categories, items, option groups, options are maintained with the same menu code across all the locations.
  2. The retries(auto/manual) attempted for failed API responses are limiting to a maximum of 3 times.
  3. The request sent to API should always be in a bulk data payload. Individual data per API request is not entertained.
  4. The throttle limit defined for each API should be honored. Refer "Constraints and Expectations" section under each API in API documentation.
  5. The successive request should be sent to the UP system only after verifying the callback response. 

Excercise

  1. Set up a virtual brand in your staging environment for the testing.
  2. Make sure at least 4 outlets are configured for the same brand.
  3. Keep the menu for all the locations.
  4. Make sure the categories, items, Option Groups, Options, Taxes, Charges are configured with the right data just like how you set up for a real brand.
  5. Make sure you have configured all the webhook endpoints in the Quint Dashboard under Webhooks page.
  6. Make sure Gamma Dashboard Features are updated with status - "to-be-verified".

Adding/Updating Store

  1. Create 2 different stores with the below basic data in a single API request,
     - "name", "city", "ref_id", "address", "active": true, "ordering_enabled": true, "included_platforms", "timings".
  2. Make sure you pass the platform values under the "included_platforms" array.
  3. Check for a callback response for this API.

Store Actions API

  1. Make a request to disable the store using the platform value as - urbanpiper. (make sure you give other platforms values like zomato, swiggy, etc as a checkbox to select from because, during the demo, we will use "zomato" as the platform value for testing)
  2. Make another request to enable the store with the platform value as - urbanpiper.
  3. As you are passing the urbanpiper as the platform value, the webhook callback will not be triggered. So you need to simulate the callback response payload through postman. (During the demo, we will try to trigger the webhook callback from the UP system itself when platform used is "zomato")

    Note: In the live environment, you will be using the platform values as - zomato, swiggy, dunzo. Not urbanpiper.

Managing Catalogue API

  1. Sync the master menu of the brand by making a Master level request(-1). Pass all the catalogue details like Categories(sub-categories), Items, Option Groups, Options, Taxes, Charges in the request. This request will just create the data in the Quint Dashboard.
  2. Once the callback response is successfully verified for the Master level request, make a Location level request for both the stores you created. Pass the catalogue entries - categories, sub-categories, items, option groups, options. Such that the data gets associated to the right location. Check the callback response for the menu you synced
  3. Make sure you have used all the attributes in this API. No attribute should be missed.
  4. Make sure you have configured the webhook callback URL in Quint Dashboard choosing the event - Catalogue Publish through API.
  5. Make another request by updating the same menu.
  6. Check the callback response for the menu you synced again.
  7. The items combination should have - variants and add-ons as options.
    variants - minimum selectable should be 1 and max selectable should be 1
    add-on - min selectable should be 0 and max selectable should be -1.
  8. Make sure you implemented flush_categories: true,flush_items: true, flush_option_groups: true and flush_options: true, flush_charges: true, flush_taxes: true as per the API documentation.
  9. Please keep all the menu data for a particular location in one API request only. Don't keep a practice of sending the category in the request, items in another request, and so on.
  10. Make sure you read about the FAQs about the Managing Catalogue API thoroughly.

Items Actions API

  1. Disable a few sets of items and options in one request.
  2. Enable the same sets of items in another request. Check-in satellite, if it's reflecting under Inventory.
  3. During the demo, we will connect the test store to the zomato test environment to check the callback response.
  4. Make sure you have configured the webhook callback URL in Quint  Dashboard choosing the event - Items Stock In/Out

Order Relay Webhook

  1. Make sure you have configured the webhook endpoint for this event in Quint Dashboard under webhooks choosing the event - order placed.
  2. Place an order having the items with options combination from Satellite Tool. Make sure the taxes, charges are present for the items at the checkout page before placing the order. Apply the discount as well.
  3. Keep the channel as Zomato or Swiggy instead of Satellite.
  4. Check below pieces of information are showing in the POS screen -
    Order_id of aggregator, channel, delivery_type, payment type, instructions, delivery rider contact details, the current status of the order, current status of the delivery rider, Merchant Sponsored Discount.
  5. Merchant Sponsored Discount can be found by the formula = discount - total_external_discount
  6. Once the order is placed in your system, check if you have implemented a new order alert mechanism.
  7. Compare the data of items-options ordered, quantities, taxes, charges, subtotal, total, discount with the Satellite tool. Both systems should match the same data.

Order Status Update:

  1. Make sure you have configured the webhook endpoint for this event in Quint Dashboard under webhooks choosing the event - order status update
  2. Update the status of the order starting with Acknowledge, then Food Ready from your POS, and check if that status got updated in Satellite.
  3. Now, update the status of the order with Dispatched followed by Completed from Satellite, and check if the status got updated in your POS.
  4. Place one Zomato order and try to cancel the order from POS along with Cancellation reasons specified in the API doc and check if the status gets updated in the satellite along with the cancellation message.
  5. Place one more Zomato order and try to cancel the order from Satellite and check the status pushed to your POS.
  6. Place one Swiggy order and you try to cancel the order from POS. You will see the 400 HTTP cancellation error with - "message": "Cancellation of Swiggy orders is not allowed. Callback requested instead.". When you get this error, you have to mark the order as cancelled at your end. No further requests are made to the UP system for this order.
  7. Make sure you have simulated the orders payload shared in the Postman collections. That covers all the corner cases.

Rider Status Change

  1. Place one Zomato order and Acknowledge the order from your POS. Open Postman tool and place your rider status webhook URL in the URL section and now by copying the sample payload of rider status update from the API document, place it in the raw body. Now modify the payload data based on the order you have placed(take a reference of webhook payload).
  2. You need to show - Rider Phone, Name, current_status primarily on UI against the order.
  3. The complete details to modify the rider status update payload will be found in Order Relay payload, The modification involves - order.details.id of UrbanPiper, order.details.ext_platforms.id of Aggregator, order.details.channel, order.store.id for UP store id, order.store.merchant_ref_id for POS store id.
  4. Pass current_status as 'Assigned' in the first request and keep only 'assigned' array under status_updates[] and hit the request. Check your POS if it gets updated.
  5. Mark the order status as Food Ready from POS. Using Postman, make a request for current_status as 'At store' and keep the array of 'assigned', 'at-store' under status_updates[]
  6. Mark the order status as Dispatched from the satellite. Using Postman, make a request for current_status as 'Out for delivery' and keep the array of 'assigned', 'at-store', 'out-for-delivery' under status_updates[].
  7. Mark the order status as Completed from the satellite. Using Postman, make a  request for current_status as 'Delivered' and keep the array of 'assigned', 'at-store', 'out-for-delivery' and 'delivered' under status_updates[].

Once each and every pointer is validated, then please ask the Integration team to take the final demo.

Was this article helpful?