> ## Documentation Index
> Fetch the complete documentation index at: https://dugble.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# SMS Events

> Inspect the delivery event history for an SMS message.

Dugble records delivery events as an SMS moves through the sending pipeline and the downstream provider reports delivery outcomes.

## List message events

Retrieve events for a message with:

```http theme={null}
GET /sms/{message_id}/events
```

For example:

```bash theme={null}
curl "https://api.dugble.com/sms/$MESSAGE_ID/events?limit=50" \
  -H "Authorization: Bearer $DUGBLE_API_KEY" \
  -H "Accept: application/json"
```

## Pagination

SMS event history currently supports a `limit` parameter only.

| Parameter | Description                                                                        |
| --------- | ---------------------------------------------------------------------------------- |
| `limit`   | Maximum events to return. Defaults to 100 when omitted, zero, or greater than 100. |

Unlike Email events, SMS events do not currently expose an `offset` parameter in the service contract.

## Event data

An event can include a unique event ID, event type, occurrence time, provider, and optional code or message.

```json theme={null}
{
  "success": true,
  "data": {
    "object": "list",
    "data": [
      {
        "id": "49a3999c-0ce1-4ea6-ab68-afcd6dc2e794",
        "type": "delivered",
        "occurred_at": "2026-08-25T09:00:05Z",
        "provider": "provider-name"
      }
    ]
  }
}
```

## Events and message status

The SMS resource exposes `last_event` as the latest known state. Use the event list when you need the delivery history behind that state.

Common SMS states include `queued`, `processing`, `submitted`, `sent`, `delivered`, `undelivered`, `rejected`, `failed`, `expired`, `unknown`, and `canceled`.

## Refresh provider status

When you need the latest state directly from the provider, Dugble also exposes `POST /sms/{message_id}/sync-status` for messages that have already been submitted to a provider.

## Real-time processing

For applications that need to react automatically to delivery changes, use webhooks instead of repeatedly polling message events.

See [Webhooks](/docs/webhooks/introduction) for event delivery to your application.