Introduction
API

SFTP
On this page

In order to test your integration, you’ll need:
How do I place a test order?
How do I perform the E2E testing?

Testing Integration#

Click below to jump to the topics:

In order to test your integration, you’ll need:#

  1. Have a test user

    You must share with your Account Manager an email address you have access to, but that does not already exist in PedidosYa. This email will be used to create a test user so you can view your test store from the PedidosYa mobile app.

  2. Have a test store

    Your Account Manager must provide you with the ID, name, and address of your test store.

  3. Have access to the test store in Partner Portal

    Your Account Manager must ensure that you have access to the test store in Partner Portal. In Partner Portal, you must configure the webhook and obtain the token.

  4. Validate your integration

    You can test the different functionalities you develop in your test store.

How do I place a test order?#

By logging into the PedidosYa mobile app with your test user, you must search for the test store at the address shared by your Account Manager. Once you find the store, you can place orders from the app as if you were a real user.

After placing the order in the app, you will receive it in the webhook you configured.

How do I perform the E2E testing?#

In order to ensure your integration is up and running, it’s important that you go through the end-to-end test cases.

  1. Place an order on the PedidosYa App in your test store with your test user and confirm on RECEIVED order status event triggered to your webhook

  2. Complete Order fulfilment for PedidosYa and Own Delivery flows (as it applies to your case)

    1. Complete Order fulfilment using the PUT endpoint & Platform Delivery flow

    2. Modified request body

      1. For Item level status: IN_CART

      2. Using PUT request share order fulfilment status READY_FOR_PICKUP

      3. You should receive response HTTP 200

      4. Your webhook should receive READY_FOR_PICKUP

      5. Your webhook should receive DISPACHED status as well, sent when the rider picks up the order from the vendor. You utilised reconciliation of orders, this order is an asynchronous status you can have upto 30 minutes delay

    3. Complete Order fulfilment using the PUT endpoint & Vendor Delivery flow

    4. Modified request body

      1. For Item level status: IN_CART

      2. Using PUT request share order fulfilment status DISPACHED

      3. You should receive response HTTP 200

      4. Your webhook should receive DISPACHED status

  3. Partially fulfil an order using the PUT endpoint, for both Delivery flows

    1. Modified request body

    2. Order status: READY_FOR_PICKUP or DISPACHED

    3. Item level status: IN_CART & NOT_FOUND`

    4. You should receive response HTTP 200

    5. Your webhook must receive READY_FOR_PICKUP, DISPACHED or both status

  4. Cancelling an order from Customer or Logistics or Vendor:

    1. Customer cancellation after order placement:

      1. Order is placed on Platform App

      2. Your webhook should receive the RECEIVED status

      3. Customer cancelled the order

      4. Your webhook should receive CANCELLED status

    2. Customer cancellation after order fulfilment:

      1. Order is placed on Platform App

      2. Your webhook should receive the event RECEIVED

      3. Picker received the order and fulfilled the order using PUT endpoint

      4. Your webhook should receive READY_FOR_PICKUP or DISPACHED or both depending on your delivery flow

      5. Customer cancelled the order

      6. Your webhook should receive the CANCELLED status

      7. In cancellation order payload you will receive an additional field post_pickup_flag: true which means cancellation happened after rider pickup. (check this FAQ)

    3. Vendor cancellation:

      1. Order is placed from Platform App

      2. Your webhook should receive status RECEIVED

      3. Cancel the order from your picking device using PUT & CANCELLED status

4. **Logistics cancellation(Platform delivery)**
1. Order is placed
2. Your webhook should receive `RECEIVED` status
3. You may then fulfil the order and receive `READY_FOR_PICKUP` status
4. When logistic cancels the order you receive `CANCELLED` status to your webhook
5. In cancellation order payload you will receive an additional field `post_pickup_flag: true` which means cancellation happened after rider pickup. (check this [FAQ](pos-pelican-picking-faq#how-can-i-tell-if-an-order-was-actually-picked-up-after-being-cancelled-i-need-to-know-whether-it-should-be-treated-as-a-final-sale))

You must test all scenarios in the UPDATE_CART:

  • Modify the quantity and price of a unit-based product

  • Modify the price of a weight-based product

  • Replace an item with another one (both weight-based and unit-based)

  • Mark an item as NOT_FOUND (both weight-based and unit-based)

  • Add an item (both weight-based and unit-based)

It's important that these tests include products with promotions.

  1. Modify item quantity or price for UNIT items using the PUT endpoint

    1. Modify the body of the item.pricing

    2. In pricing object quantity must be between max_quantity and min_quantity. Pricing is automatically adjusted

    3. If you want to adjust the price, use the unit\_price or total\_price, not both and not more than total_price or **unit\_price

  2. Modify item quantity for weighted (KG) items using the PUT endpoint

    1. Configuration is required in Catalog to set the item tag as sold_by_weight to enable weighted items.

    2. weight must be between max_quantity and min_quantity. Pricing is automatically adjusted

    3. Direct price adjustments on weighted items are not valid

  3. Replace an OOS item using PUT endpoint

    1. If item A is out-of-stock and you want to replace it with item B. Prepare the request body

    2. Set item status of item A as REPLACED and item B as IN_CART

    3. Include a new field replaced_id in item B, and use the value from id field from item A

    4. Fulfill the order using the READY_FOR_PICKUP or DISPACHED based on your delivery flow.

  4. Mark a product as NOT_FOUND

    1. Set the product status as NOT_FOUND

  5. Update Cart to validate changes on items

    1. Adjust the items status, or price or quantity

    2. Send PUT request with order status as UPDATE_CART

    3. Check for any feedback and rerun the request for success

    4. To complete the order send order fulfilment status with READY_FOR_PICKUP or DISPATCHED based on your delivery flow

  6. Add additional item to the order using PUT endpoint

    1. Prepare request body with following to add a new product

      1. sku: required for product hydration.

      2. pricing.quantity: required

      3. pricing.weight: required for weighted items

      4. pricing.unit_price: optional, Vendors can set a unit overriding the original price If not provided, the order will use the price from the item hydration

    2. Item status should be ADDITION

    3. Fulfill the order using the READY_FOR_PICKUP or DISPACHED based on your delivery flow.

  7. GET /vendor_id/orders

    1. Set the time frame and get the list of orders at the store level, they will have final statuses like CANCELLED or PICKED_UP

  8. GET /order_id

    1. Retrieves orders on the ID will have final statuses like CANCELLED or PICKED_UP

If all updates are correctly processed without errors, the integration is ready to go live. You can schedule a meeting here with our Integrations Support team to certify your integration.


APIUse Cases - Endpoints ExplainedAPITroubleshooting