Openclaw Rappi

assisted rappi ordering through a local HTTP service. use this when the user asks to order food, groceries, pharmacy, convenience items, lunch, snacks, household basics, or anything "por Rappi". the skill structures the request, creates a cart draft in visible Chrome, summarizes cart/checkout, prepares review handoff, sends a native approval button when available, and submits the final purchase only after exact explicit approval in the current chat.

intent

use this skill to help users place Rappi orders (food, groceries, pharmacy, convenience, household items) by building a cart draft through the local openclaw-rappi service, summarizing items/price/address/delivery estimate, and submitting only after the user gives exact written approval. the skill enforces a hard safety boundary: no final purchase without explicit per-order approval in the current conversation. use this when a user says "order me lunch", "buy groceries on Rappi", "get pharmacy items", or any variant of requesting delivery/commerce through Rappi.

inputs

local service endpoint:

• OPENCLAW_RAPPI_SERVICE_URL (env var, default: http://127.0.0.1:4777)
• service must be running and healthy before cart creation; health check via GET /health

chrome/browser automation:

• Chrome browser with remote debugging enabled on port 9222 (macOS: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222)
• dedicated Chrome profile logged into https://www.rappi.com.co/ with saved address/payment (optional but recommended)
• if unavailable, bootstrap from GitHub at https://github.com/zarruk/openclaw-rappi.git into $HOME/.openclaw/tools/openclaw-rappi and start service locally

user input / context:

• order category: restaurant, grocery, pharmacy, convenience, or unknown
• item names, quantities, and notes
• budget constraints (if any)
• dietary preferences, preferred store/location, address hint, substitution policy
• delivery address (may be pre-filled in Rappi profile or require explicit input)
• payment method (may be pre-selected or require choice)
• handoff target: cart (user reviews before checkout) or checkout (user reviews at checkout screen)

chat channel context (Telegram-specific):

• chat ID for button-based approval requests
• support for native button callbacks vs. plain text approval phrases

procedure

1. health check

   • call GET /health against the service endpoint
   • if unavailable, run bootstrap script (see setup check in decision points)
   • re-check GET /health after bootstrap; if still down, report exact stderr and stop

2. parse user request into structured order

   • extract category (restaurant, grocery, pharmacy, convenience, or unknown)
   • extract items: name, quantity, notes (e.g. "2x burger, light onions")
   • extract preferences: budgetMax, dietary restrictions, preferred store, address hint, substitution policy (allowSubstitutions: true/false)
   • determine handoff target: if user says "dejar listo para pagar", "llevar hasta checkout", "hasta el final", or similar, set handoffTarget: "checkout"; otherwise handoffTarget: "cart"
   • always set safety flags: { "requireHumanFinalCheckout": true, "restrictedItemsAllowed": false }
   • if ambiguity exists (e.g. item name is vague, budget unclear, no address provided), ask one concise clarifying question before proceeding

3. create draft

   • send POST /drafts with body:

     {
       "requestText": "<user's full request>",
       "category": "<parsed category>",
       "items": [{"name": "<item>", "quantity": <n>, "notes": "<notes>"}],
       "preferences": {
         "budgetMax": <number or null>,
         "dietary": [<array of strings>],
         "allowSubstitutions": <bool>,
         "handoffTarget": "<cart|checkout>"
       },
       "safety": {
         "requireHumanFinalCheckout": true,
         "restrictedItemsAllowed": false
       }
     }
     

   • capture returned draftId
   • output: draftId, service acknowledgment

4. poll draft status

   • call GET /drafts/:id every 2-3 seconds until status reaches cart_ready, checkout_ready, needs_user_input, blocked, or failed
   • timeout after 60 seconds of polling; if still pending, report and ask user to check Chrome manually
   • output: current status, any visible items/prices/address in draft

5. summarize cart

   • when status is cart_ready or checkout_ready, extract and display:
     • store/restaurant name
     • product names, quantities, unit prices
     • any items that could not be found or are out of stock (missing items)
     • substitutions made by the service (with original + substitute)
     • subtotal, shipping, taxes, total (visible in Rappi)
     • delivery address (as shown on screen)
     • payment method label or last 4 digits (if visible and not sensitive)
     • estimated delivery time
     • any warnings (e.g. "some items unavailable", "budget exceeded")
   • output: summary text (markdown or plain, user-facing)

6. offer checkout preparation (if handoffTarget is "cart")

   • ask user: "ready to review at checkout?" or "proceed to checkout for final review?"
   • if user says yes/confirm, proceed to step 7a
   • if user says no, ask what to modify (items, address, payment) and return to step 2

7a. prepare checkout (if requested or if handoffTarget is "checkout")

• call POST /drafts/:id/prepare-checkout
• poll GET /drafts/:id until status is checkout_ready or blocked
• if blocked, report the blocker (e.g. login required, captcha, address validation) and stop
• output: checkout summary, checkout_ready status

7b. request approval

• display final checkout summary (all items, total, address, delivery time, payment method)
• inform user that clicking the approval button or typing the exact phrase will submit the order
• in Telegram: send a message with the summary and a native "Aprobar compra" button; include the approval phrase APRUEBO COMPRA RAPPI <draftId> as a fallback line in message body
• in other channels: request the exact phrase in plain text
• output: approval request (with button or text prompt)

8. receive and validate approval

   • wait for user to click the button or type APRUEBO COMPRA RAPPI <draftId> exactly
   • acceptance criteria: button callback equals APRUEBO COMPRA RAPPI <draftId> OR message text contains that exact phrase as a standalone line or sentence
   • if user types something vague ("ok", "yes", "sí", "adelante") without the exact phrase, ask them to confirm with the required text
   • reject approvals from previous orders, standing instructions, or other chats
   • output: approval confirmed, draftId

9. confirm purchase

   • call POST /drafts/:id/confirm-purchase with body:

     {
       "approvalText": "APRUEBO COMPRA RAPPI <draftId>",
       "approvedBy": "user"
     }
     

   • poll GET /drafts/:id until status is purchased, failed, or blocked
   • output: final order status, order confirmation number (if available)

10. report outcome

    • if status is purchased: report success, confirmation number, estimated delivery time, and next steps
    • if status is failed or blocked: report the exact failure reason (payment declined, address invalid, captcha required, etc.), last visible Rappi state, and guidance on manual recovery
    • do not fabricate confirmation numbers; if Rappi status is unclear, say so

decision points

if service is unavailable on startup:

• try to bootstrap from GitHub automatically using the provided install script
• if bootstrap fails, report exact stderr and blocker; do not proceed until user confirms service is running
• if bootstrap succeeds but health check still fails, ask user to check logs at $HOME/.openclaw/tools/openclaw-rappi/logs/ or manually start the service

if Chrome remote debugging is unavailable:

• ask user to open a new Chrome profile with CDP enabled and log into Rappi:

  mkdir -p "$HOME/.openclaw/rappi-chrome-profile"
  /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
    --remote-debugging-port=9222 \
    --user-data-dir="$HOME/.openclaw/rappi-chrome-profile" \
    --no-first-run --no-default-browser-check \
    https://www.rappi.com.co/
  

• do not proceed until user confirms Chrome is running and logged in

if draft creation fails (POST /drafts returns error):

• check if service is still healthy (GET /health)
• if healthy, report the API error and ask user to refine the request (e.g. "item name too vague", "no address provided")
• if not healthy, restart service and retry

if polling times out (status never reaches terminal state):

• report timeout after 60 seconds
• ask user to check the visible Chrome window and report what they see
• offer manual recovery: user can click items/proceed in Chrome directly, or we can call POST /drafts/adopt-checkout if already at checkout

if draft status is "blocked":

• report the specific blocker (login required, captcha, 2FA, age verification, address validation, payment required, etc.)
• do not attempt to automate sensitive screens (login, captcha, identity, alcohol/tobacco/prescription items)
• ask user to manually complete the blocked step in Chrome, then retry draft or call adopt-checkout

if draft status is "needs_user_input":

• report what input is needed (e.g. "select store", "confirm address", "choose payment method")
• ask user to provide the input via chat or manually in Chrome
• after user provides input, retry polling or call the appropriate service endpoint

if user's request is ambiguous:

• ask one concise clarifying question before creating the draft (e.g. "which restaurant?", "what size?", "confirm address?")
• do not proceed until user clarifies

if visible total exceeds user's stated budget:

• stop and report the excess
• ask user to approve the higher price, remove items, or cancel
• do not proceed to checkout until resolved

if user provides approval text but it differs from the required exact phrase:

• ask user to confirm with the exact phrase: APRUEBO COMPRA RAPPI <draftId>
• reject vague approvals ("ok", "yes", "adelante", "si")
• treat only the exact phrase or matching button callback as valid approval

if checkout summary differs materially from the summary the user approved:

• stop immediately
• report the discrepancy (price changed, items missing, address wrong, payment method different)
• ask user to review in Chrome and re-approve if satisfied, or cancel

if service endpoint is available but returns a 5xx error during confirm-purchase:

• report the error and last known draft state
• ask user if they want to retry the API call or complete the purchase manually in Chrome (if at checkout screen)
• if user chooses manual completion, acknowledge and do not call the API again
• if user chooses retry, call POST /drafts/:id/confirm-purchase once more, then report outcome

if user asks to modify the order after cart is ready:

• if still at cart_ready status, ask what to change and return to step 2 (re-parse and create a new draft)
• if already at checkout_ready or pending approval, ask user to cancel this draft and start a new order request

output contract

successful flow outputs:

• draftId (string): unique identifier for this order draft
• cartSummary (markdown): store name, items with quantities, subtotal, shipping, total, address, delivery estimate, payment method label
• checkoutSummary (markdown): same as cartSummary, used at final approval stage
• approval request message (Telegram button + fallback text, or plain text in other channels) with exact phrase APRUEBO COMPRA RAPPI <draftId>
• order confirmation: status purchased, estimated delivery time, and optional confirmation number from Rappi

blocked/failed flow outputs:

• status (blocked, failed, timeout)
• specific blocker reason (e.g. "login required", "captcha shown", "payment declined", "address invalid", "budget exceeded")
• last known Rappi screen state (text/screenshot if available)
• guidance for manual recovery (e.g. "complete login in Chrome, then tell me when done")

data locations:

• service logs: $HOME/.openclaw/tools/openclaw-rappi/logs/service.out.log, service.err.log
• Chrome profile: $HOME/.openclaw/rappi-chrome-profile
• draft state: held in service memory (no persistent DB guaranteed; service restart may lose draft)

outcome signal

the user knows the skill worked when:

• cart stage: a summarized cart appears in chat showing store, items, total, address, and delivery time; user is asked "ready to review at checkout?"
• checkout stage: final summary is displayed with all prices and address confirmed; user sees the approval button or exact phrase prompt
• purchase confirmation: chat displays "order confirmed" (or equivalent) with estimated delivery time, optionally a confirmation number; order appears in Rappi app
• failures are explicit: if anything blocks (login required, captcha, budget exceeded, payment error), the user sees the exact reason and next steps, not a vague error

the user knows the skill failed when:

• service does not start or remains unhealthy after bootstrap
• Chrome automation never connects or times out
• order creation fails and error reason is unclear
• approval text is rejected because it does not match the required phrase
• order status remains uncertain (service did not confirm purchased)
• visible Rappi state contradicts the summary shown in chat (price mismatch, missing items, wrong address)