confirm_order

Finalize an Instamart order that's awaiting payment (PENDING_PAYMENT). Called after payment settles. Idempotent; the agent normally never calls it directly.

Finalize an Instamart order that's awaiting payment (PENDING_PAYMENT). Transitions the order to PLACED on successful payment, or finalizes it to failed state otherwise. Idempotent and safe to retry.

See confirm_order in actionComing soon

Example

const result = await client.callTool({
  name: "confirm_order",
  arguments: {
    orderId: "241234567890",
    paasId: "PAAS_TXN_12345",
  },
});

Parameters

Parameter	Type	Required	Description
`orderId`	`string`	yes	Order ID returned by `checkout`.
`paasId`	`string`	yes	Payment transaction ID returned by `checkout`. This is the canonical payment-transaction reference for Instamart.

Session credentials (user identity, access token) are supplied automatically by the authenticated MCP session - you do not pass them in the tool call. See Authenticate.

Response

All Swiggy MCP tools return:

{
  "success": true,
  "data": { /* tool-specific payload */ },
  "message": "optional human-readable message"
}

On failure:

{
  "success": false,
  "error": { "message": "description of what went wrong" }
}

See Error codes for the full catalogue.

Details

Field	Value
Name	`confirm_order`
MCP Server	Instamart
Endpoint	`POST mcp.swiggy.com/im`
Stage	Payment
Behaviour	mutating

Agent guidance

How Swiggy agents and orchestration logic use this tool. Surface these expectations in your prompts or tool-selection policies.

In normal UPI flows, you (the agent) never call this directly — confirmation is handled automatically when payment settles. Only call it manually if payment was confirmed but order confirmation did not complete.

WHEN TO CALL:

✅ Payment is confirmed (PAID) but the order is still in PENDING_PAYMENT — call once to finalize.
⏱️ At your polling cap with payment still PENDING — call once to finalize (never loop).
❌ DO NOT call on FAILED — instead call get_payment_options to retry payment.
❌ DO NOT call on REFUND-INITIATED — inform the user a refund is on its way; do not retry.

Idempotent: safe to retry on transient failure.

Next in this journey →

Continue with track_order to follow delivery.