---
title: "Test en agent fra start til slutt (API)"
description: "Kjør engangssimuleringer, parallelle scenariobatcher og pakker for utgivelsesporter gjennom ThunderPhone API-et, slik at regresjoner i agenten fanges opp før kundene hører dem."
---

<Note>
  Foretrekker du dashbordet? Den samme funksjonaliteten finnes i **Simuleringer**
  (`/dashboard/simulations`), inkludert AI-generering av scenarioer — se
  [Simuler en samtale](/nb/guides/simulate-a-call). Denne siden dekker den
  programmatiske metoden.
</Note>

Å iterere på en AI-agent betyr å iterere på prompten, verktøyene
og måten den håndterer grensetilfeller på. **Simulerings-API-et** kjører ekte
samtaler mot en agent ved hjelp av en scenarioprompt du oppgir. Å målrette
mot en agent oppretter en bot-til-bot-kjøring; å målrette mot et telefonnummer
oppretter en SIP-loopback-kjøring. Hver kjøring produserer en ekte samtalelogg med
transkripsjon, vurdering og fakturering, slik at du ser nøyaktig hvordan agenten
oppfører seg og hva den koster.

Bruk det til:

- Røyktester før utrulling etter hver promptendring
- Regresjonssuiter koblet til CI (koble webhooken `test-call.completed`
  → la byggingen feile hvis poengsummen faller)
- Belastningstesting av samtidighetsgrenser

## Engangskjøring: enkeltkjøring

```bash
curl -X POST https://api.thunderphone.com/v1/simulations \
  -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
  }'
```

Felt:

| Felt | Type | Påkrevd | Beskrivelse |
|-------|------|----------|-------------|
| `target_type` | streng | ja | `agent` eller `phone_number` |
| `target_id` | heltall | ja | Agent-ID-en (eller telefonnummer-ID-en) |
| `direction` | streng | nei | `outbound` (standard; testinnringer ringer opp) eller `inbound` (testinnringer svarer) |
| `scenario_prompt` | streng | nei | Styrer hva testboten sier |
| `language` / `primary_language` | streng | nei | Språk for testinnringeren; koder som ikke støttes, avvises |
| `simulator_product` | streng | nei | `testing` (standard) eller `spark` for en mer menneskelignende simulert innringer, for eksempel konsultasjonstester for varm overføring |
| `consent_to_charge` | boolsk | **ja** | Må være `true`. Estimatet fakturerer både den valgte agenten og den simulerte innringeren til en fast pris per minutt, i tillegg til eventuelle telefoniøkter |
| `target_number` | streng | nei | E.164-overstyring for den eksterne siden; ellers brukes plattformens testnummer |

`mode` er skrivebeskyttet og avledes fra `target_type`: `agent` produserer
`mode="bot"`, mens `phone_number` produserer `mode="sip"`.

Svaret er et [simuleringskjøringsobjekt](/api-reference/test-calls#test-call-run-object)
med `status="queued"`. Poll til `status` blir `completed` eller
`failed`; når `call_id` er angitt, laster du inn transkripsjonen via
[`GET /v1/calls/{call_id}/transcript`](/api-reference/calls#get-transcript).

## Batcher: parallelle scenarioer

Kjør N scenarioer samtidig — nyttig for regresjonssuiter som
treffer alle kjente grensetilfeller parallelt:

```bash
curl -X POST https://api.thunderphone.com/v1/simulations/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
  }'
```

Svaret inneholder en `run_ids`-liste med ID-er for underkjøringer. Hent
batchstatus:

```bash
curl https://api.thunderphone.com/v1/simulations/batches/{batch_id} \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY"
```

`run_count` er begrenset til 20; `stagger_seconds` fordeler oppstarten
for å unngå å overbelaste agenten (0–60 s).

## Koble det til CI

Opprett en utgivelsesportpakke på siden **Simuleringer**
(`/dashboard/simulations`) — velg agenten, legg til scenarioer manuelt eller
klikk **Generer scenarioer med KI** for å utarbeide dem fra agentens
prompt (med en valgfri gjennomgang av grenseverdier), og grupper dem i en pakke.
En pakke låser scenarioene og agenten, samt en minimum bestått-rate og en
valgfri regel om null kritiske feil. Beståtte kjøringer blir det aksepterte
referansegrunnlaget; senere overganger fra bestått til ikke bestått returneres som regresjoner.

Bruk en [API-nøkkel for organisasjonen](/api-reference/developer-api-keys) i CI.
Dette skriptet utløser pakken, spør til vurderingen og sammenligningen er
fullført, og avslutter med en ikke-null-status med mindre avgjørelsen er `pass`:

```bash
#!/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` returnerer `202` med
kjørings-ID-en. `GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id}` returnerer
`status`, `verdict`, `pass_rate`, `critical_failure_count` og
referansegrunnlagets `regressions`-liste. Begge endepunktene binder organisasjonen
i URL-en til API-nøkkelens organisasjon.

## Kjør en pakke etter en tidsplan

Åpne agentens **Simuler**-fane, velg **Utgivelsesportpakker**, og opprett eller
rediger en pakke. Slå på **Kjør etter en tidsplan**, velg **Frekvens** og
**Tidssone**, og angi deretter **Minutt over hel time**, **Lokal tid** eller **Dag**
som vist. Velg **Lagre pakke**. Hvis du fjerner avmerkingen for **Kjør etter en tidsplan**,
fjernes tidsplanen i dashbordet.

### Via API

PATCH pakken for å legge til eller erstatte tidsplanen. Se [Pakker (utgivelsesporter)](/api-reference/test-scenarios#suites-release-gates) for det fullstendige
pakkeobjektet og endepunktene.

```bash
curl -X PATCH https://api.thunderphone.com/v1/suites/{suite_id} \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "schedule": {
      "enabled": true,
      "frequency": "daily",
      "timezone": "America/Chicago",
      "hour": 6,
      "minute": 30
    }
  }'
```

`frequency` kan være `hourly`, `daily` eller `weekly`. Bruk en IANA-tidssone.
Timeplaner hver time bruker `minute`; daglige tidsplaner bruker `hour` og `minute`;
ukentlige tidsplaner bruker også `weekday`, der mandag er `0` og søndag er `6`.
Pakkesvaret inkluderer `next_run_at` og `last_run_at`.

Tidspunkter følger sommertidendringene i den valgte tidssonen. Planlagte kjøringer
vises i pakkens kjøringshistorikk og bruker gjeldende agent, scenarioer,
kriterier og aksepterte referansegrunnlag. Hvert genererte testanrop sender
`test-call.completed`; det finnes ingen webhook for fullføring på pakkenivå. Planlagte
anrop faktureres til samme simuleringspris som manuelle pakkekjøringer og registrerer
`trigger: "schedule"` på pakkekjøringen.

For å sette en tidsplan på pause uten å endre tidspunktet, PATCH det komplette
eksisterende tidsplanobjektet med `"enabled": false`. `frequency` er påkrevd;
utelatt tidssone og tidsfelt tilbakestilles til standardverdiene, så inkluder de
eksisterende verdiene. Send `"schedule": null` for å fjerne tidsplanen.

## Mønstre

### Regresjonskorpus per prompt

Vedlikehold en JSON-fil med tupler av `{name, scenario_prompt, expected_outcome}`.
Ved hver promptendring kjører du hele settet som en batch. Sammenlign
transkripsjonene og vurderingene med forrige kjøring.

### Røyketest per utgivelse

Én enkelt batch med fem scenarioer for vanlig bruk som du kjører etter hver
distribuering. Latensfølsom, så behold `stagger_seconds: 0`.

### Latensbenchmarking

Kjør identiske scenarioer mot ulike produktnivåer (`spark`,
`bolt`, `storm-base`). Sammenlign `call.graded`-skårene og
`duration_seconds` fra hver resulterende samtalelogg.

---

## Neste trinn

<CardGroup cols={2}>
  <Card title="Referanse for testsamtaler" icon="flask" href="/api-reference/test-calls">
    Alle spørringsparametere, statuskoder og batchformater.
  </Card>
  <Card title="AI-vurdering" icon="chart-line" href="/api-reference/calls#ai-call-grading">
    Gi automatisk poengsum til hver testkjøring for å følge kvaliteten over tid.
  </Card>
  <Card title="Feilrapporter" icon="triangle-exclamation" href="/api-reference/issue-reports">
    Marker spesifikke tester for menneskelig gjennomgang.
  </Card>
  <Card title="Webhook for test-call.completed" icon="bolt" href="/nb/webhooks/events">
    Strøm resultater til CI / Slack / PagerDuty.
  </Card>
</CardGroup>