We’ve just changed /api/lia/outbound to align with the CPO spec. Now, when calling it from Make, we’re getting a 500 Internal Server Error.

Request body being sent:

```json
{
  "customer_id": "TEST-123",
  "payments_remaining": 12,
  "campaign": "TEST_12_PCP",
  "asset_type": "new",
  "channel": "whatsapp",
  "sandbox_mode": true,
  "from_number": "whatsapp:+44YOUR_SANDBOX_OR_BUSINESS_NUMBER"
}
URL: /api/lia/outbound
Method: POST
The HTTP module reports: 500 Internal Server Error with no extra detail.

I need you to:

────────────────────────
TASK 1 – Reproduce and inspect the error

In the Replit environment, reproduce the error for this exact payload:

Either by:

Using a small Python test script with httpx or requests against the running server, OR

Using FastAPI’s TestClient within the codebase and calling /api/lia/outbound directly, OR

Checking the Dashboard_Server logs for the last 500 thrown by /api/lia/outbound.

Capture the full Python traceback for the 500 error.

Identify exactly where it is failing:

e.g. NameError, KeyError, attribute missing, stage not defined, campaign lookup bug, etc.

────────────────────────
TASK 2 – Fix the underlying bug (don’t hide it)

Based on the traceback, fix the actual cause of the 500.

Common likely causes given the recent changes:

A variable like stage or date_from/date_to is referenced before assignment in one branch.

The new stage-derivation code is not handling some path (e.g. missing payments_remaining or default).

The new sandbox / campaign lookup logic returns None and the downstream code assumes a dict.

Requirements:

Do NOT just wrap the logic in a broad try/except that returns 500 with a generic message.

Fix the logic so that:

For valid sandbox payloads (like the one above), it returns 200 with a valid outbound payload.

For genuinely invalid requests, it returns a clear 4xx (e.g. 400) with a helpful JSON {"detail": "...reason..."}.

────────────────────────
TASK 3 – Confirm outbound response shape

For the test payload above, I expect a 200 OK with JSON matching this contract:

json
Copy code
{
  "message_text": "<string – final WhatsApp body to send>",
  "conversation_id": "<uuid-string>",
  "to_number": "whatsapp:+44...", 
  "stage": "12"
}
Where:

stage is derived from payments_remaining (12 → "12"), not from the campaign key.

asset_type is "new" or "used" and is used to select the correct template (EOT_12_NEW or EOT_12_USED).

message_text is a real opener (not an error string).

conversation_id is the dp_conversations.conversation_id created/used for this outbound.

────────────────────────
TASK 4 – Basic logging improvement (optional but helpful)

If not already present, add a small log entry around the outbound handler so that future 500s from /api/lia/outbound log:

the conversation_id (if known),

the campaign,

the payments_remaining,

sandbox_mode,

and the exception message.

You can use the existing logging setup – this is just to make debugging easier next time.

────────────────────────
WHEN DONE

Reply with:

The exception cause you found (e.g. “NameError: stage not defined in process_outbound_message”) and the fix you applied.

The final response-building snippet for /api/lia/outbound (showing message_text, conversation_id, to_number, stage).

A sample of the successful JSON response for the test payload above (you can redact phone numbers, but keep the structure).

yaml
Copy code