# Testing and Validation Now that you have completed implementing the touchpoints of the integration, you are advised to test and self-validate 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 provided. Please ensure the pointers are self-validated before requesting the sign-off. ### **Technical Considerations** 1. Make sure the menu architecture lies within the **federated** structure. This has been explained earlier in the [Architecture](/downstream/menu/architecture.md) of the menu. If this is not followed then we cannot proceed forward with the integration testing. 2. The retries(auto/manual) attempted for failed API responses you received are limited to a maximum of **3 times**. 3. The request sent to Add/Update Stores, Add/Update Menu and Menu Toggle APIs 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 honoured. Refer to the *Constraints & Expectations* section under each API in the API documentation for the details of the same. 5. The successive request should be sent to the UP system only after verifying the callback response. 6. The success and errors received in the webhook callbacks should be prompted on the POS UI for the end-users readability purposes. 7. Make sure to return the response for the webhooks that we trigger to your endpoints are within the timeout constraints of Connection Timout 3 seconds and Read Timeout 5 seconds. 8. Always keep UrbanPiper Order ID unique in your system. Due to any retry mechanism, you receive a duplicate order request, your system should ignore it from inserting the order again. 9. Make sure to read the article - [Webhook Circuit Breaker](/downstream/resources/webhook-circuit-breaker.md) ### **Exercise** 1. Set up a virtual brand menu in your staging environment for testing. 2. Make sure you have configured all the webhook endpoints in the Atlas Dashboard under Webhooks page. 3. Make sure at least 3 stores are configured for the same brand in Atlas dashboard. 4. Keep the different combination of menu available for all the 3 stores and sync it to Atlas dashboard. 5. Make sure the menu consists of categories, items, Option Groups, Options, Taxes, and Charges are configured with the right data just like how the brand has set up their menu in the aggregator's site. You can refer to your client's menu on any aggregators UI to get a better understanding. 6. Sync the menu to our staging environment and verify the menu populated in Atlas dashboard. 7. Enable the stores and disable the stores using Store Toggle API. Verify the results using Atlas dashboard. 8. Enable the items and options, disable them using Menu Toggle API. Verify the results using Atlas dashboard. 9. Place multiple test orders using the below combination using *Developer Tools*. * Order placed with different locations and different platforms. * Order without *Has an addon?* and *Has variants?* toggle enabled. * Order without *Has an addon?* and *Has variants?* toggle enabled but with *Item quantity* and *Line Item Count* greater than 1. * Order with *Has an addon?* toggle enabled. * Order with *Has an addon?* toggle enabled and *Addon count* field is filled with value greater than 1. Make sure you have more than one addon for an item configured already in Atlas dashboard to apply this condition. * Order with Has variants? toggle enabled. * Order with Has variants? and *Has an addon?* toggles enabled along with *Addon count* field value is greater than 1. * Order with *Has variants?* and *Has an addon?* toggles enabled along with *Addon count* and Item quantity field value is greater than 1. * Order with *Service Charges* value (for Talabat, Swiggy, Justeat) * Order with *Packaging Charges* value (for all platforms) * Order with *Delivery Charges* value (for all platforms) * Order with *Surcharge value* (for Deliveroo) * Order with *Driver Tip (for Ubereats)* * Order with *Fixed Discount Value (for Ubereats)* * Order with *Delivery Type* value - Partner * Order with *Delivery Type* value - Self (except Swiggy) * Order with *Fulfillment Type* value - Delivery * Order with *Fulfillment Type* value - Pickup * Order with *Is future order?* toggle enabled. * Order with *Payment Type* - Pre-paid * Order with *Payment Type* - Cash * Order with *Order Instructions* * Order with different combinations from the above scenarios. 10. Verify the orders placed in Atlas dashboard compared with your POS UI. 11. The key information such as - customer details (name, phone, address), Item details (item and option name, quantity, price, item instructions), order information (subtotal, total, taxes, charges, discount, order type - delivery/pickup, delivery type - self/partner/pickup, contact access code, External platform order ID, Channel name, instructions, delivery/pickup datetime), and Payment information are showing on the POS UI. 12. For some of the orders placed using the Developer Tools, update the order states in sequence - Acknowledged, Food Ready, Dispatched, Completed using Order Status Update API. 13. Similarly, for some orders update the order status - Cancelled along with the cancellation reasons. Make sure you allow the order cancellation request from the POS only for the orders that are not Acknowledged yet. 14. For some orders that are still in Placed status, try cancelling the orders from Atlas dashboard and check if you are getting the order status updates via webhook notification. 15. Simulate the Rider Status Change webhook payloads using Postman tool. Key information like - Rider Name, Rider Phone, and Rider Current Status should be shown in the POS UI. ### **Add/Update Store** 1. Make sure you have subscribed the webhook callback URL in Atlas Dashboard choosing the event - *Store Create/update.* 2. Create 3 different stores with the below basic data in a single API request,\ \- *"name"*, *"city", "ref\_id", "address", "active": true, "ordering\_enabled": true, "included\_platforms", "platform\_data", and "timings"*. 3. Make sure you pass the platform values under the *"included\_platforms"* array. 4. Check for a callback response for this API. ### **Store Toggle API** 1. Make sure you have subscribed the webhook callback URL in Atlas Dashboard choosing the event - *Store Status Change*. 2. Make a request to *"disable"* the store. Check if the changes are appearing in Atlas dashboard. 3. Make another request to *"enable"* the store. Check if the changes are appearing in Atlas dashboard. 4. Check for a callback response for this API. ### **Add/Update Menu API** 1. Make sure you have subscribed the webhook callback URL in Atlas Dashboard choosing the event - *Catalogue Publish through API*. 2. 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 Atlas Dashboard. 3. Once the callback response is successfully verified for the Master level request, make a Location level request for all the stores you created. Pass the catalogue entries - *categories*, *sub-categories*, *items*, *option groups*, *options.* Such that the data gets associated with the right location. Check the callback response for the menu you synced 4. Make sure you understand the importance of each attribute and have passed them in the API. No attributes should be hard-coded and everything should be dynamically fetched from your configuration. 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.\ \&#xNAN;*variants* - minimum selectable should be 1 and max selectable should be 1\ \&#xNAN;*add-on* - min selectable should be 0 and max selectable should be -1. 8. Make sure you implemented *flush\_categories,flush\_items*, *flush\_option\_groups* and *flush\_options* as per the API documentation*. Make sure to you read the article* [Flush Operations](/downstream/resources/flush-operations.md) 9. Make sure you implemented *clear\_items, clear\_option\_groups, clear\_opt\_grps, clear\_options,* and *clear\_nested\_opt\_grps* as per the API documentation. *Make sure to you read the article* [Flush Operations](/downstream/resources/flush-operations.md) 10. 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 one request, items in another request, and so on. ### **Items Actions API** 1. Make sure you have configured 2 webhook callback URLs in Atlas Dashboard choosing the events - *Items Stock In/Out and Option Sock In/Out.* 2. *"disable"* a few sets of items and options in one request. Verify the changes are reflecting in Atlas dashboard. 3. *"enable"* the same sets of items in another request. Verify the changes are reflecting in Atlas dashboard. 4. Check for a callback response for this API. ### **Order Relay Webhook** 1. Make sure you have configured the webhook endpoint for this event in Atlas Dashboard under webhooks choosing the event - *order placed*. 2. Place an order using Developer Tools with various combinations mentioned under Exercise. 3. 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. 4. Merchant Sponsored Discount can be found by the formula = *discount* - *total\_external\_discount* 5. Once the order is placed in your system, check if you have implemented a new order alert mechanism. 6. Compare the data of items-options ordered, quantities, taxes, charges, subtotal, total, discount with the Atlas dashboard. Both systems should match the same data. 7. Make sure to return your POS order ID in the response of Order Placed webhook under the attribute "order\_ref\_id" at the root level. ### **Order Status Update:** 1. Make sure you have configured the webhook endpoint for this event in Atlas 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 Atlas. 3. Now, update the status of the order with *Dispatched* followed by *Completed* from Atlas dashboard, and check if the status got updated in your POS.= via webhook. 4. Place one 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 Atlas along with the cancellation message and reason code. 5. Place one more order and try to cancel the order from Atlas 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. ### **Rider Status Change** 1. Place one Zomato order and *Acknowledge* the order from your POS. Open the 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, please fill the **Self-validation checklist** shared in the onboarding email and inform us over the email (`pos.support@urbanpiper.com`) to review and schedule the testing demo call . Once the demo is done, our integration team may ask you to address issues/shortcomings, if found, during the demo. You would need to implement the fixes and schedule another demo to showcase the fixes. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://api-docs.urbanpiper.com/downstream/integration-certification/testing-and-validation.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.