We now want /api/lia/outbound to populate the to_number field using dp_customer.phone_mobile, so that Make/Twilio can use the API response directly. Context: - dp_customer has column phone_mobile (e.g. '+447972194025'). - OutboundResponse currently returns: - message_text - conversation_id - to_number (often null) - stage - /api/lia/outbound already receives a valid customer_id (UUID). ──────────────────────── TASK – Populate to_number from dp_customer.phone_mobile 1. Open app/lia_outbound.py and locate the place where OutboundResponse is created in process_outbound_message (or equivalent). It currently looks like: return OutboundResponse( message_text=message_text, conversation_id=str(conversation_id), to_number=to_number, # often None stage=stage, ) 2. Before building the OutboundResponse, add logic to: - Look up the customer from dp_customer by payload.customer_id. - If a row exists and phone_mobile is not null/empty: - Build to_number as: "whatsapp:" + phone_mobile e.g. phone_mobile = '+447972194025' to_number = 'whatsapp:+447972194025' - If no row is found OR phone_mobile is null/empty: - Raise an HTTP 400 error with a clear message, for example: HTTPException( status_code=400, detail="No mobile phone number found for this customer_id in dp_customer" ) 3. Apply this behaviour for BOTH sandbox_mode true and false: - sandbox_mode continues to control whether this is a “test” run, - but if a phone number exists, to_number should still be included in the JSON response so Make/Twilio can be wired consistently in test and production. 4. Do NOT change: - How message_text is generated, - How conversation_id or stage are derived, - Any LLM/URE logic. ──────────────────────── TEST After the change, call /api/lia/outbound with this payload: ```json { "customer_id": "44f01301-7a59-4e34-b0a8-d0d89e061aab", "payments_remaining": 12, "campaign": "TEST_12_PCP", "asset_type": "new", "channel": "whatsapp", "sandbox_mode": true, "from_number": "whatsapp:+44YOUR_SANDBOX_OR_BUSINESS_NUMBER" }