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

# Bestehende Integration migrieren

> Zwei Konstanten ändern. Dann die Stellen lesen, an denen sich das Verhalten unterscheidet.

Diese API setzt den üblichen asynchronen Task-Vertrag um. Für die unterstützten Endpunkte bleiben die Anfrage- und
Antwortschemata unverändert, sodass ein funktionierender Client in der Regel keine Codeänderungen braucht.

## Die Migration

```diff theme={null}
- const BASE = "https://api.your-current-provider.example"
+ const BASE = "https://api.querying.ai"
```

Richten Sie Ihre API-Schlüssel-Konstante auf einen querying.ai-Schlüssel. Webhook-URL, Idempotenzschlüssel, Task-Typen
und das Parsen der Antworten bleiben, wie sie sind.

## Was umgesetzt ist

<CardGroup cols={2}>
  <Card title="Unterstützt" icon="check">
    `POST /v1/async/task`

    `POST /v1/async/task/batch`

    `GET /v1/async/task/{id}`

    Webhook-Callbacks
  </Card>

  <Card title="Nicht umgesetzt" icon="x">
    Synchrone `/v1/monitor/*`-Endpunkte

    `/v1/async/status`
  </Card>
</CardGroup>

Die synchrone `/v1/monitor/*`-Familie fehlt bewusst. Jede Engine hier läuft asynchron; eine Anfrage, die für die Dauer
einer Abfrage blockiert, bietet dieser Dienst nicht an.

## Wo sich das Verhalten unterscheidet

<AccordionGroup>
  <Accordion title="1. Kein Ratenbegrenzer: Batches nutzen" icon="gauge">
    Es gibt kein Ratenlimit pro Schlüssel. Für große Volumen nutzen Sie die Batch-Einreichung, um Roundtrips zu sparen.

    Siehe [Regionen und Best Practices](/de/engines/capacity).
  </Accordion>

  <Accordion title="2. Credits gelten pro Engine" icon="coins">
    `credits` ist als Teil des Umschlags in jeder Antwort enthalten. Antworten beim Einreichen und Pollen melden
    `{ "creditsToCharge": 0, "creditsCharged": 0 }`; Webhooks melden die Credit-Kosten der Engine (1–3 Credits je nach Engine).

    Fehlgeschlagene Tasks werden nicht berechnet. Credit-Guthaben sehen Sie im Dashboard.
  </Accordion>

  <Accordion title="3. Manche Engine × Region-Paare werden sofort abgelehnt" icon="ban">
    Eine Kombination kann gar nicht bedient werden: `CHATGPT`/`PERPLEXITY`/`GEMINI` nach `CN`, wo kein Exit verfügbar ist
    und die Anfrage das Ziel nie erreicht. Sie scheitert sofort mit `422 REGION_UNSUPPORTED`, statt angenommen zu werden.
    `422 REGION_UNAVAILABLE` deckt die vorübergehende Variante desselben Falls ab.

    Ein Client, der davon ausgeht, dass jede wohlgeformte Einreichung angenommen wird, braucht hier eine Verzweigung.
    Siehe [Regionen](/de/engines/capacity).
  </Accordion>

  <Accordion title="4. include-Flags sind meist wirkungslos" icon="toggle-left">
    Die `payload.include`-Flags werden akzeptiert, doch die meisten Engines liefern eine Antwort mit fester Form und
    ignorieren sie. Nur ChatGPT berücksichtigt alle; `GEMINI` berücksichtigt nur `markdown` und `rawResponse`.

    Wenn Sie etwa `html` von Gemini anfordern, wird das stillschweigend ignoriert: kein Fehler, kein Feld. Siehe die
    [Tabelle der unterstützten Flags](/de/engines/overview).
  </Accordion>

  <Accordion title="5. Ein zusätzlicher Statuscode: 422" icon="hash">
    Die Fehlerbehandlung ist ansonsten konventionell: Validierungsfehler liefern `400`, `401` meldet `MISSING_API_KEY`,
    `404` meldet `RESOURCE_NOT_FOUND`, und `details` nennt das fehlerhafte Feld.

    Neu ist nur das oben beschriebene `422`-Paar (`REGION_UNSUPPORTED`, `REGION_UNAVAILABLE`). Wir teilen Ihnen vorab mit,
    wenn eine Region nicht bedient werden kann. Ein Client, der nie ein `422` behandeln musste, wird sie also zu sehen bekommen.
  </Accordion>

  <Accordion title="6. Ein fehlgeschlagener Task erhält einen `error`-String auf oberster Ebene" icon="triangle-alert">
    `GET /v1/async/task/{id}` auf einen `FAILED`-Task liefert ein `error`-Feld auf oberster Ebene, das das
    Task-Status-Schema sonst nicht definiert, und zwar als **einfachen String**, nicht als Objekt
    `{code, message, timestamp}` wie bei Fehlern auf Anfrageebene.

    ```json theme={null}
    { "success": true, "task": { "status": "FAILED", "...": "..." }, "error": "ENGINE_TIMEOUT: The engine did not answer before the task deadline." }
    ```

    Ein Client, der ein gesetztes `body.error` als fehlgeschlagene *Anfrage* deutet, missversteht einen erfolgreich
    abgerufenen fehlgeschlagenen *Task*. Verzweigen Sie stattdessen nach `task.status`.
  </Accordion>
</AccordionGroup>

<Note>
  Diese Verhaltensweisen wurden durch Aufrufe dieser API ermittelt, nicht durch das Lesen eines Schemas. Weichen eine
  veröffentlichte Spezifikation und eine tatsächliche Antwort voneinander ab, dokumentieren diese Seiten die tatsächliche Antwort.
</Note>

## Den passenden `taskType` wählen

Ruft Ihre bisherige Integration einen Endpunkt pro Engine auf, entspricht der Engine-Name einem `taskType`:

| Bisher aufgerufen | `taskType` |
| - | - |
| ChatGPT | `CHATGPT` |
| Perplexity | `PERPLEXITY` |
| Gemini | `GEMINI` |
| Google AI Mode | `AIMODE` |
| Google AI Overview | `GOOGLE` |
| Naver | `NAVER_AI_BRIEF` / `NAVER_AI_TAB` |

<Note>
  Dass `GOOGLE` „AI Overview“ bedeutet, ist eine Namenskonvention, kein Google-Produktname. Die Antwort ist ein
  SERP-Umschlag mit `aioverview` als nullbarem Element; siehe [die GOOGLE-Form](/de/engines/overview).
</Note>

## Die Umstellung prüfen

Lassen Sie Ihre bestehende Integration eine Zeit lang parallel zu dieser laufen und vergleichen Sie die Felder, die Sie
tatsächlich nutzen, in der Praxis `response.text`, `response.sources[]` und `response.markdown`. Ein Schattenvergleich
erkennt Formabweichungen, die eine Schemaprüfung übersieht, etwa eine befüllte, aber anders sortierte Quellenliste.