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

# Anruf beendet

> Payload, die telli sendet, wenn ein Anruf einen Endzustand erreicht

## Anrufergebnis

Drei Felder beschreiben, was passiert ist. Auf ihnen solltest du aufbauen:

* `state` — wo sich der Anruf in seinem Lebenszyklus befindet
* `status` — wie er ausgegangen ist, sobald er beendet wurde
* `follow_up` — das von telli geplante Follow-up, falls vorhanden

<Warning>
  `call_status` ist veraltet und wird entfernt. Verwende stattdessen `state`, `status` und `follow_up`.
</Warning>

Das alte Feld lässt sich wie folgt auf die neuen abbilden:

| `call_status` | `state`       | `status`        | `follow_up` |
| ------------- | ------------- | --------------- | ----------- |
| `INITIATED`   | `queued`      | `null`          | `null`      |
| `RINGING`     | `ringing`     | `null`          | `null`      |
| `IN_PROGRESS` | `in_progress` | `null`          | `null`      |
| `IN_PROGRESS` | `processing`  | `null`          | `null`      |
| `COMPLETED`   | `ended`       | `connected`     | `null`      |
| `ANSWERED`    | `ended`       | `connected`     | gesetzt     |
| `NOT_REACHED` | `ended`       | `not_connected` | `null`      |
| `VOICEMAIL`   | `ended`       | `voicemail`     | `null`      |
| `ERROR`       | `ended`       | `failed`        | `null`      |

`call_status` ist in beide Richtungen verlustbehaftet: `IN_PROGRESS` unterscheidet nicht zwischen `in_progress` und `processing`, und `COMPLETED` und `ANSWERED` unterscheiden sich nur darin, ob ein Follow-up geplant wurde.

## Analysefelder

Die Payload enthält zwei Arten von Analysedaten, und **ihre Formate unterscheiden sich**.

`call_analysis` enthält die integrierte Analyse von telli. Jeder Eintrag hat einen booleschen `value`; Einträge, die zusätzliche Details unterstützen, haben außerdem `details`:

```json theme={null}
{
  "appointment": {
    "value": true,
    "details": "2025-02-18T15:30:00Z"
  }
}
```

`call_outcome` enthält die [benutzerdefinierten Analysefelder](/de/deep-dives/call-analysis), die du in telli konfigurierst. Die Einträge sind nach Feldnamen benannt und enthalten den extrahierten `value` sowie das Schema, gegen das er validiert wurde:

```json theme={null}
{
  "custom_lost_reason": {
    "value": "PRODUCT_TOO_EXPENSIVE",
    "fieldSchema": {
      "type": ["string", "null"],
      "enum": ["CUSTOMER_NOT_INTERESTED", "CUSTOMER_PREVIOUSLY_CONTACTED", "PRODUCT_TOO_EXPENSIVE"]
    }
  }
}
```

Ein `call_outcome`-Eintrag kann zusätzlich `reason` enthalten, das erklärt, warum der Agent diesen Wert gewählt hat, sowie `error`, wenn die Extraktion fehlgeschlagen ist.

## Erfasste Daten

Wenn der Agent [Datenerfassungs-Aufgaben](/de/deep-dives/collected-data) hat, zeigt `collected_data`, was während des Anrufs erfasst und bestätigt wurde:

```json theme={null}
{
  "email": {
    "status": "confirmed",
    "value": "user@example.com"
  },
  "case_number": {
    "status": "declined",
    "value": null
  }
}
```

Nur Einträge mit `confirmed` enthalten einen Wert, auf den du dich verlassen solltest. Wenn keine Datenerfassungs-Aufgaben konfiguriert sind oder keine ausgelöst wurde, ist `collected_data` leer oder `null` — behandle beide Fälle.

## Wiederholungsversuche

Automatische Wiederholungen innerhalb einer geplanten Sequenz teilen sich eine `loop_id`, und `attempt` zählt darin hoch. Wird derselbe Kontakt erneut geplant, beginnt eine neue Schleife — verwende daher `contact_id`, um einen Kontakt über Sequenzen hinweg zu verfolgen.


## OpenAPI

````yaml openapi-v2.json webhook call_ended
openapi: 3.1.1
info:
  title: telli API
  version: 2.0.0
  description: telli V2 API
servers:
  - url: https://api.telli.com
    description: prod
security:
  - BearerAuth: []
paths: {}
components:
  securitySchemes:
    BearerAuth:
      type: http
      scheme: bearer
      description: API key authentication. Use your telli API key as the bearer token.

````