--- title: "Einstellungen für Verifizierungen" description: "Legen Sie fest, wie lange Verify-Codes gültig bleiben, nach wie vielen falschen Prüfungen eine Verifizierung fehlschlägt, wie lange die Wartezeit vor einem erneuten Senden ist und auf welcher Website Codes automatisch ausgefüllt werden." canonical: "https://bird.com/de-de/dokumentation/guides/verify/settings" --- # Einstellungen für Verifizierungen Der Tab **General** der Seite [**Configure**](https://bird.com/dashboard/w/verify/configure) legt fest, wie sich jede Verifizierung in Ihrem Workspace verhält. Dort steuern Sie, wie lange ein Code gültig bleibt, nach wie vielen falschen Versuchen eine Verifizierung endet, wie bald ein neuer Code gesendet werden kann und zu welcher Website der Code gehört. Jedes Feld zeigt den wirksamen Wert: Ihren eigenen Wert, wenn Sie einen festgelegt haben, andernfalls den Plattform-Standardwert von Bird. Ein Feld wird gespeichert, sobald Sie es verlassen. **Duration**, **Maximum Retries** und **Website** werden beim Erstellen einer Verifizierung festgelegt, daher gilt eine Änderung nur für neue Verifizierungen. Eine Änderung von **Retry Delay** gilt ab dem nächsten Create-Aufruf, auch für eine bereits laufende Verifizierung. Um eine Einstellung zu ändern, benötigen Sie die Berechtigung `verify_management` auf der Ebene `write`, die in den Rollen `admin` und `developer` enthalten ist. Die Rolle `analyst` kann die Seite ansehen. Siehe [Benutzer, Teams und Rollen](/docs/guides/users-teams-roles#workspace-roles). ![Der Tab General der Seite Configure mit den Feldern Duration, Maximum Retries, Retry Delay und Website](/images/docs/dashboard-verify-configure-general.png) ## Ablauf einer Verifizierung | Einstellung | Was sie steuert | Standardwert | Bereich | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------- | | **Duration** | Wie lange eine Verifizierung offen bleibt. Eine Prüfung nach Ablauf dieses Zeitfensters liefert den Grund `expired`, und die Verifizierung endet mit dem Grund `ttl_elapsed`. | 10 Minuten | 1 bis 999 Minuten | | **Maximum Retries** | Nach wie vielen falschen Codes eine Verifizierung endet. Der letzte falsche Code lässt sie mit dem Grund `attempts_exhausted` fehlschlagen. | 5 | 1 bis 10 | | **Retry Delay** | Die Wartezeit für erneutes Senden: die Mindestwartezeit, bevor ein weiterer Code an denselben Empfänger gesendet wird. | 60 Sekunden | 0 bis 3.600 Sekunden | - **Duration** beginnt, sobald die Verifizierung erstellt wird. Ein erneutes Senden oder ein Wechsel auf einen anderen Kanal sendet einen neuen Code, behält aber den ursprünglichen Ablaufzeitpunkt bei. Ein spätes erneutes Senden verlängert das Zeitfenster also nicht. Halten Sie den Wert für Authentifizierungsabläufe bei höchstens 10 Minuten; die [Best Practices](/docs/guides/verify/best-practices#keep-the-lifetime-at-ten-minutes-or-less) erklären, warum. - **Maximum Retries** zählt falsche Codes über alle Codes hinweg, die für die Verifizierung gesendet wurden. Ein erneutes Senden setzt den Wert also nicht zurück. Wenn eine Prüfung mit einem falschen Code die Verifizierung offen lässt, meldet sie die verbleibenden Versuche in `attempts_remaining`. - **Retry Delay** greift, wenn Sie für denselben Empfänger erneut create aufrufen. Innerhalb der Wartezeit gibt der Aufruf die laufende Verifizierung zurück, ohne einen neuen Code zu senden. [Den Code über einen anderen Kanal senden](/docs/guides/verify/sending-verifications#send-the-code-on-another-channel) ist davon ausgenommen, weil ein Kanalwechsel eine andere Anfrage ist als die erneute Anforderung desselben Kanals. Setzen Sie den Wert auf 0, um bei jedem create-Aufruf einen neuen Code zu senden, innerhalb der Limits pro Empfänger aus [Abuse guardrails](/docs/guides/verify/sending-verifications#abuse-guardrails). Die Codelänge legen Sie nicht auf dieser Seite fest. Codes bestehen standardmäßig aus sechs Ziffern, und `options.code_length` legt für eine einzelne Verifizierung 4 bis 8 Ziffern fest; siehe [Optionen](/docs/guides/verify/sending-verifications#options). ## Automatisches Ausfüllen **Website** gibt die Website an, auf der Ihre Nutzer ihre Codes eingeben, etwa `https://login.example.com`. Ist eine Website festgelegt, können Browser den Code auf dieser Website und auf keiner anderen anbieten. Der Nutzer muss den Code dann nicht kopieren. Lassen Sie das Feld leer, um Codes ohne Angabe einer Website zu senden. Geben Sie die Website als `https://` gefolgt von der Domain in Kleinbuchstaben an, ohne Port, Pfad oder abschließenden Schrägstrich. Eine internationalisierte Domain verwenden Sie in ihrer `xn--`-Form, zum Beispiel `https://xn--bcher-kva.example` für `bücher.example`. Jede andere Form wird abgelehnt, und die Fehlermeldung nennt die einzugebende Form, sofern es eine gibt. Verwenden Sie genau die Website, auf der das Codefeld angezeigt wird: Ein Formular auf `login.example.com` benötigt `https://login.example.com`, nicht `https://example.com`. Sobald eine Verifizierung eine Website hat, fügt Verify sie den Code-Nachrichten hinzu: - **SMS**: Die Nachricht endet mit einer Zeile wie `@login.example.com #123456`. Kennzeichnen Sie Ihr Codeeingabefeld mit `autocomplete="one-time-code"`, damit Safari und andere Browser den Code anbieten, und rufen Sie auf der Seite die [WebOTP API](https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API) auf, wenn der Browser den Code ohne Antippen einfügen soll. Die zusätzliche Zeile kann ein weiteres SMS-Segment erfordern: In vielen Sprachen mit Unicode-Kodierung, etwa Arabisch, Griechisch oder Russisch, belegt ein gebundener Code zwei Segmente statt einem, was die SMS-Kosten verdoppelt. Eine lange Domain kann in anderen Sprachen dieselbe Wirkung haben. - **E-Mail**: Die Nachricht enthält einen `OTP-Token`-Header mit dem Code und der Website, wie im [OTP-Token Internet-Draft, Revision 01](https://datatracker.ietf.org/doc/draft-goto-otp-token/01/) definiert. E-Mail-Programme beginnen erst, diesen Header auszuwerten. Behandeln Sie ihn daher als Ergänzung zum Code in der Nachricht. Die Website wird beim Erstellen einer Verifizierung festgelegt. Ein erneutes Senden, ein Fallback auf einen anderen Kanal oder ein weiterer create-Aufruf für denselben Empfänger behält sie bei. ### Code pro Anfrage an eine Website binden Eine Anfrage kann mit `options.autofill_origin` eine eigene Website angeben, die **Website** für diese Verifizierung ersetzt. Nutzen Sie dies, wenn ein Workspace mehrere Websites bedient. Wenn das Codefeld in einem Cross-Origin-iframe liegt, etwa in einem Zahlungsformular, das in den Checkout eines Shops eingebettet ist, setzen Sie `options.autofill_origin` auf die Website des iframes und `options.autofill_top_level_origin` auf die Seite im Browser-Tab. Die SMS-Zeile nennt dann beide Websites, wie in `@shop.example #123456 @pay.example`, was in jeder Sprache ein Segment hinzufügen kann. Chrome füllt dieses Formular automatisch aus, wenn die Seite das iframe direkt einbettet und ihm `allow="otp-credentials"` gewährt. E-Mails enthalten bei diesen Verifizierungen keinen `OTP-Token`-Header, da der Header nur eine Website nennen kann. Die Anfrage wird mit `422` abgelehnt, wenn die Top-Level-Website fehlerhaft ist, wenn weder in der Anfrage noch auf dieser Seite eine Website festgelegt ist oder wenn sie mit dieser Website übereinstimmt. ### Registrierte SMS-Absender Wenn Sie SMS über Ihren eigenen registrierten Absender senden, etwa eine US-10DLC-Kampagne, fügen Sie der Kampagne eine Beispielnachricht mit der gebundenen Zeile am Ende hinzu, bevor Sie eine Website festlegen. Netzbetreiber können Nachrichten filtern, die von den registrierten Beispielen der Kampagne abweichen. ## Fehlerbehebung - **Die Website wird abgelehnt.** Der Wert hat nicht das erforderliche Format. Geben Sie das Format ein, das die Meldung vorschlägt, zum Beispiel `https://example.com` für `https://Example.com/`. - **Der Browser bietet den Code nicht an.** Prüfen Sie, ob die Website exakt mit der Adresse der Seite übereinstimmt, einschließlich einer etwaigen Subdomain, und ob das Codefeld `autocomplete="one-time-code"` hat. Prüfen Sie bei einem iframe, ob die Anfrage beide Websites festlegt und die einbettende Seite `allow="otp-credentials"` gewährt. Das automatische Ausfüllen hängt auch vom Browser ab: Chrome liest die SMS-Zeile über WebOTP und Safari über seine eigene Code-Autofill-Funktion, während Firefox WebOTP nicht unterstützt ([Browserunterstützung](https://caniuse.com/mdn-api_otpcredential)). - **Ein Code ist abgelaufen, bevor der Nutzer ihn eingegeben hat.** Prüfen Sie die zeitliche Abfolge der Versuche im [Verify-Log](/docs/guides/verify/verify-log), bevor Sie **Duration** erhöhen. Meist ist ein langsamer Zustellweg die Ursache, und ein längeres Zeitfenster schwächt den Code. ## Nächste Schritte - [Verifizierungen senden](/docs/guides/verify/sending-verifications): Verifizierungen erstellen und prüfen, einschließlich Optionen pro Anfrage. - [Ziele](/docs/guides/verify/destinations): Kanäle und deren Reihenfolge für jedes Zielland festlegen. - [Absender und Branding](/docs/guides/verify/senders): die Nachrichten ansehen, die Verify sendet, und den Absender für jeden Kanal auswählen. ## Related resources - [Verify phone numbers at signup](/learn/series/verify-phone-numbers-at-signup) (video) - [What does OTP mean? One-time passwords explained](/explained/verify/what-does-otp-mean) (answer) - [Customer verification](/verify-api) (product) - [Build your first integration](/learn/paths/integration) (course) [Get an implementation brief](/learn/workspace?topic=verify)