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

# Протестуйте агента наскрізно (API)

> Запускайте заздалегідь підготовлені сценарії через API тестових дзвінків для вашого агента, щоб виявляти регресії до того, як їх почують клієнти.

<Note>
  Надаєте перевагу дашборду? Та сама можливість доступна в **Simulations**
  (`/dashboard/simulations`), зокрема генерація сценаріїв за допомогою ШІ — дивіться
  [Симуляція дзвінка](/uk/guides/simulate-a-call). На цій сторінці описано
  програмний спосіб.
</Note>

Ітерації над ШІ-агентом означають ітерації над його промптом, інструментами
та способом обробки крайніх випадків. **API test-calls** виконує реальні
дзвінки (бот-до-бота або SIP loopback) до агента за наданим вами промптом
сценарію — кожен запуск створює реальний журнал дзвінка з транскриптом,
оцінюванням і тарифікацією, тож ви точно бачите, як поводиться агент
і скільки це коштує.

Використовуйте його для:

* Smoke-тестів перед розгортанням після кожного редагування промпту
* Регресійних наборів, підключених до CI (підключіть вебхук `test-call.completed`
  → завершуйте збірку з помилкою, якщо оцінка знизиться)
* Стрес-тестування лімітів одночасних викликів

## Одноразовий запуск: один прогін

```bash theme={null}
curl -X POST https://api.thunderphone.com/v1/test-calls \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_type":     "agent",
    "target_id":       12,
    "direction":       "outbound",
    "scenario_prompt": "You are a polite caller asking about refund policy for order 12345.",
    "consent_to_charge": true
  }'
```

Поля:

| Поле                | Тип              | Обов’язкове | Опис                                                                     |
| ------------------- | ---------------- | ----------- | ------------------------------------------------------------------------ |
| `target_type`       | рядок            | так         | `agent` або `phone_number`                                               |
| `target_id`         | ціле число       | так         | Ідентифікатор агента (або ідентифікатор номера телефону)                 |
| `direction`         | рядок            | так         | `outbound` (бот здійснює дзвінок) або `inbound` (бот відповідає)         |
| `scenario_prompt`   | рядок            | ні          | Визначає, що говорить тестовий бот                                       |
| `mode`              | рядок            | ні          | `bot` (бот-до-бота, за замовчуванням) або `sip` (SIP loopback)           |
| `consent_to_charge` | логічне значення | **так**     | Має бути `true`. Тестові дзвінки коштують у 2× більше за звичайний тариф |
| `target_number`     | рядок            | ні          | Перевизначення Caller ID бота (E.164)                                    |

Відповідь містить [об’єкт запуску тестового дзвінка](/api-reference/test-calls#test-call-run-object)
зі `status="queued"`. Опитуйте статус, доки `status` не стане `completed` або
`failed`; щойно буде задано `call_id`, завантажте транскрипт через
[`GET /v1/calls/{call_id}/transcript`](/api-reference/calls#get-transcript).

## Пакети: паралельні сценарії

Запускайте N сценаріїв одночасно — це корисно для регресійних наборів, які
паралельно перевіряють кожен відомий крайній випадок:

```bash theme={null}
curl -X POST https://api.thunderphone.com/v1/test-call-batches \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_type":     "agent",
    "target_id":       12,
    "direction":       "outbound",
    "run_count":       5,
    "stagger_seconds": 2,
    "scenario_prompts": [
      "Ask about refund policy.",
      "Ask for hours of operation.",
      "Complain about a delayed shipment.",
      "Ask to speak with a human.",
      "Ask an unrelated trivia question."
    ],
    "consent_to_charge": true
  }'
```

Відповідь містить список `run_ids` з ідентифікаторами дочірніх запусків. Отримайте
статус пакета:

```bash theme={null}
curl https://api.thunderphone.com/v1/test-call-batches/{batch_id} \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY"
```

`run_count` обмежено значенням 20; `stagger_seconds` розподіляє запуски в часі,
щоб не перевантажувати агента (0–60 с).

## Інтегруйте в CI

Створіть набір контрольних перевірок релізу на сторінці **Симуляції**
(`/dashboard/simulations`) — виберіть агента, додайте сценарії вручну або
натисніть **Згенерувати сценарії за допомогою ШІ**, щоб створити їхні чернетки на основі
промпту агента (з необов’язковою перевіркою граничних випадків), і згрупуйте їх у набір.
Набір фіксує свої сценарії та агента, а також мінімальний рівень успішності й
необов’язкове правило нульової кількості критичних збоїв. Успішні запуски стають
прийнятою базовою лінією; подальші переходи з успішного результату до невдалого
повертаються як регресії.

Використовуйте [API-ключ організації](/api-reference/developer-api-keys) у CI.
Цей скрипт запускає набір, опитує статус, доки не завершаться оцінювання та порівняння,
і завершується з ненульовим кодом, якщо вердикт не `pass`:

```bash theme={null}
#!/usr/bin/env bash
set -euo pipefail

: "${THUNDERPHONE_API_KEY:?Set THUNDERPHONE_API_KEY}"
: "${THUNDERPHONE_ORG_ID:?Set THUNDERPHONE_ORG_ID}"
: "${THUNDERPHONE_SUITE_ID:?Set THUNDERPHONE_SUITE_ID}"

base="https://api.thunderphone.com/v1/orgs/${THUNDERPHONE_ORG_ID}/suites/${THUNDERPHONE_SUITE_ID}"
auth="Authorization: Bearer ${THUNDERPHONE_API_KEY}"

run_id="$(curl --fail --silent --show-error -X POST "${base}/run" \
  -H "$auth" -H "Content-Type: application/json" -d '{}' | jq -r '.id')"

deadline=$((SECONDS + 1800))
while (( SECONDS < deadline )); do
  result="$(curl --fail --silent --show-error \
    "${base}/runs/${run_id}" -H "$auth")"
  status="$(jq -r '.status' <<<"$result")"
  if [[ "$status" == "completed" ]]; then
    jq . <<<"$result"
    [[ "$(jq -r '.verdict' <<<"$result")" == "pass" ]]
    exit
  fi
  sleep 10
done

echo "ThunderPhone suite timed out" >&2
exit 1
```

`POST /v1/orgs/{org_id}/suites/{suite_id}/run` повертає `202` з
ідентифікатором запуску. `GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id}` повертає
`status`, `verdict`, `pass_rate`, `critical_failure_count` і список базових
`regressions`. Обидві кінцеві точки прив’язують організацію в URL
до організації API-ключа.

## Шаблони

### Корпус регресій для кожного промпту

Ведіть JSON-файл із кортежами `{name, scenario_prompt, expected_outcome}`.
Після кожної зміни промпту запускайте повний набір як пакет; порівнюйте
транскрипти та оцінки з попереднім запуском.

### Smoke-тест для кожного релізу

Один пакет із п’яти сценаріїв щасливого шляху, який ви запускаєте після кожного
розгортання. Чутливий до затримки, тому зберігайте `stagger_seconds: 0`.

### Бенчмаркінг затримки

Запускайте ідентичні сценарії для різних рівнів продукту (`spark`,
`bolt`, `storm-base`). Порівнюйте оцінки `call.graded` і
`duration_seconds` з кожного отриманого журналу виклику.

***

## Наступні кроки

<CardGroup cols={2}>
  <Card title="Довідник тестових викликів" icon="flask" href="/api-reference/test-calls">
    Усі параметри запитів, коди стану та структури пакетів.
  </Card>

  <Card title="Оцінювання ШІ" icon="chart-line" href="/api-reference/calls#ai-call-grading">
    Автоматично оцінюйте кожен тестовий запуск, щоб відстежувати якість із часом.
  </Card>

  <Card title="Звіти про проблеми" icon="triangle-exclamation" href="/api-reference/issue-reports">
    Позначайте конкретні тести для перевірки людиною.
  </Card>

  <Card title="Вебхук test-call.completed" icon="bolt" href="/uk/webhooks/events">
    Передавайте результати у ваші CI / Slack / PagerDuty.
  </Card>
</CardGroup>