# SMS Trigger Implementation Status (Repo Check)

This document explains what SMS “triggers” exist in your codebase, what parts are definitely wired, and what parts appear missing/uninvoked. It is based on reading the SMS-related controllers/services/jobs in both:
- `voicebot-api/`
- `voicebot-api-live/`

## A) Where SMS Triggers are configured

### 1) Trigger CRUD (UI / admin)
SMS trigger CRUD endpoints are implemented in:
- `voicebot-api/app/Http/Controllers/Api/SmsTriggerController.php`
- `voicebot-api-live/app/Http/Controllers/Api/SmsTriggerController.php`

These controllers create and manage per-business trigger tables:
- `{$businessId}_sms_triggers` (table is created on demand by `SmsService::ensureSmsTriggerTable()`)

The trigger records include:
- `bot_id` (agent/bot identifier; nullable means “all bots”)
- `trigger_event` (allowed values include `end_of_call, call_started, call_failed, call_transferred`)
- `to_number` (optional; if empty, SMS recipient is taken from call data)
- `sms_content` (template text)
- `provider_id` (optional; if unset, uses fallback provider order configured for the business)

### 2) Trigger “execution semantics” vs stored trigger_event
Even though the trigger model allows multiple `trigger_event` types at the CRUD layer, the actual call-end SMS processing logic (see section C) only loads triggers for `end_of_call`.

## B) The SMS sending system (providers)

Your SMS provider abstraction exists and has concrete implementations:
- `TwilioSmsProvider` (`voicebot-api-live/app/Services/SmsProviders/TwilioSmsProvider.php`, same idea also exists in `voicebot-api/`)
- `MCubeSmsProvider` (`voicebot-api-live/app/Services/SmsProviders/MCubeSmsProvider.php`)
- `PlivoSmsProvider` (`voicebot-api-live/app/Services/SmsProviders/PlivoSmsProvider.php`)

### Provider selection + fallback
Provider routing is centralized in:
- `voicebot-api-live/app/Services/SmsProviderManager.php`

Key behavior:
- Reads all active provider integrations for the business from DB (joins `business_sms_integrations` + `sms_providers`).
- Sorts/iterates by `priority` (lower number = higher priority).
- If `provider_id` is specified in a trigger, the manager tries the preferred provider first.
- If the chosen provider fails, it falls back to the next provider(s) until one succeeds or all fail.

So: provider failover is implemented; whether it “works in production” depends on credentials being correct and the provider endpoints being reachable.

## C) How SMS is actually sent after a call ends

### 1) There is an “after call” job implementation
There is a queue job class intended to process SMS triggers when a call ends:
- `voicebot-api/app/Jobs/SendSmsAfterCallJob.php`
- `voicebot-api-live/app/Jobs/SendSmsAfterCallJob.php`

This job calls:
- `SmsService::processCallEndTriggers($businessId, $conversationId)`

### 2) The job’s service logic exists and only handles `end_of_call`
The SMS trigger processing service is implemented in:
- `voicebot-api/app/Services/SmsService.php`
- `voicebot-api-live/app/Services/SmsService.php`

Important behavior confirmed by reading the service:
- It loads triggers using `trigger_event = end_of_call`
- It replaces template variables (examples: `{customer_name}`, `{phone_number}`, `{agent_name}`, `{call_duration}`, `{call_summary}`, `{business_name}`, `{date}`, `{time}`)
- It sends via `SmsProviderManager::sendSmsWithFallback()`
- It writes results into a per-business SMS log table:
  - `{$businessId}_sms_logs`

### 3) Missing piece found: I cannot find any dispatcher for `SendSmsAfterCallJob`
Across the repo, I searched for:
- `SendSmsAfterCallJob` references that dispatch/enqueue it
- any call to `processCallEndTriggers()` besides the job itself

Result:
- The only references to `SendSmsAfterCallJob` are the job class files themselves.
- The only code path invoking `processCallEndTriggers()` is inside the job + a manual test script.

Additionally:
- There is no match for `SendSmsAfterCallJob::dispatch(...)` in the codebase.

Conclusion:
- The “after-call SMS triggers via queue job” logic is implemented, but it appears **not automatically wired** (no dispatch entry point found in this repo).

What you CAN verify quickly:
- Check your queue worker logs: do you see `SendSmsAfterCallJob` being processed?
- If not, after-call triggers will not fire automatically.

## D) The “SMS MCP tool send” path (this one looks wired)

### 1) MCP server endpoints expose a tool to send SMS immediately
The MCP server implementation exists in:
- `voicebot-api/app/Http/Controllers/Api/SmsTriggerController.php`
- `voicebot-api-live/app/Http/Controllers/Api/SmsTriggerController.php`

The MCP controller defines:
- MCP discovery endpoints (`indexMcp`)
- a tool call handler that supports a tool named `send`
- a `sendViaMcp` method that sends SMS immediately using `SmsProviderManager::sendSmsWithFallback()`

### 2) This MCP “send” does not require `trigger_event`
This MCP tool flow is different from the DB “trigger_event” model:
- It sends immediately
- It does not check trigger_event like `end_of_call`

So if your ElevenLabs agent is calling the MCP tool, SMS sending should work even if the after-call job dispatch is missing.

## E) Manual test scripts (proof that the end-of-call logic works if invoked)

There are manual scripts that run the SMS trigger service directly:
- `voicebot-api/manual_trigger_test.php`
- `voicebot-api-live/manual_trigger_test.php`

These scripts call:
- `SmsService::processCallEndTriggers($businessId, $conversationId)`

So the SMS trigger logic is functionally testable when invoked directly.

## F) Summary: “who is it working?”

### Working (confirmed by code paths present)
1. SMS provider sending implementation + fallback:
   - Twilio + MCube + Plivo providers exist
   - `SmsProviderManager` tries providers with fallback on failure
2. MCP tool-based SMS sending:
   - `SmsTriggerController` exposes a `send` tool and can send SMS directly
3. After-call SMS logic exists:
   - `SmsService::processCallEndTriggers()` processes `end_of_call` triggers
   - SMS logs are written into `{$businessId}_sms_logs`
   - `SendSmsAfterCallJob` calls that service

### Not confirmed / appears not wired automatically
4. Automatic dispatch/execution of `SendSmsAfterCallJob` for real calls:
   - I could not find any dispatch call in the repository
   - meaning “DB trigger_event end_of_call firing in production” may not happen unless an external scheduler/worker dispatch exists outside this repo

## G) Next checks I recommend (no code changes)
1. Confirm which app is active in your environment:
   - `voicebot-api-live` vs `voicebot-api`
2. Confirm your queue worker logs:
   - Are `SendSmsAfterCallJob` messages being consumed/processed?
3. Confirm MCP routing:
   - Ensure the MCP server URL that ElevenLabs is using actually routes to `SmsTriggerController` in your deployed API.