> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Anwendung aktualisieren API: Kundenanwendungen verwalten > Mit PATCH /organizations/me/{org_id}/applications/{app_id}/ aktualisieren Sie in Didit Metadaten von Kundenanwendungen, Brands und Umgebungen. Prompt zum Aktualisieren der Anwendung Prompt in die Zwischenablage kopieren \

\`Partially update one Didit application's metadata (name, public URLs, redirect URIs, description). Credentials (client_id, api_key, uuid) are NEVER changed by this call.

Endpoint:
PATCH https://apx.didit.me/auth/v2/organizations/me/{org_id}/applications/{app_id}/

Authentication:
Authorization: Bearer 
The access token must belong to an OWNER or ADMIN of the organization.

Path parameters:
\- org_id (UUID, required) — Organization that owns the application.
\- app_id (UUID, required) — Application UUID to update.

Request body — PATCH semantics. Send ONLY the fields you want to change. Omitted fields are preserved.
\- name (string, optional) — Display name.
\- website_url (string, URL, optional) — Public homepage.
\- redirect_uris (array of strings, optional) — Allowlisted OAuth-style redirect URIs. The array REPLACES the previous value entirely.
\- terms_url (string, URL, optional) — Terms-of-service link.
\- privacy_url (string, URL, optional) — Privacy policy link.
\- description (string, optional) — Internal note (not shown to end users).
\- products is read-only: a products key in the body is ignored.
\- data_location (string, optional) — The application's data location, chosen when it was created. Naming the location it already has is accepted; any other location answers 400. One exception: the live application created with your organization (at sign-up or by POST /programmatic/verify-email/) has its location chosen by the first update that names data_location, once, while none of its API keys has been used and it has no verification session. Only "eu" (European Union, Ireland) is available today.

What does NOT change:
\- uuid, client_id, api_key — credentials stay the same. Existing integrations keep working; no key rotation happens here.
\- data_location — set when the application is created (see above for the one exception).

curl example — rename and move to a new domain:
curl -X PATCH "https://apx.didit.me/auth/v2/organizations/me//applications//" \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"name": "Acme Production App",
"website_url": "https://app.acme.example"
}'

curl example — add a second redirect URI (full replacement of the array):
curl -X PATCH "https://apx.didit.me/auth/v2/organizations/me//applications//" \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"redirect_uris": [
  "https://acme.example/callback",
  "https://staging.acme.example/callback"
]
}'

Response (200 OK):
The full application record after the change, including products (same shape as GET /organizations/me/{org_id}/applications/{app_id}/). uuid, client_id, and api_key are unchanged.

When to call:
\- Reseller customer rebrands → rename their application.
\- Domain migration → update website_url, terms_url, privacy_url.
\- Add or remove a staging redirect URI.
\- Refresh terms / privacy URLs shown in the verification flow.

Failure modes:
\- 400 — { "": ["Enter a valid URL."] } for malformed website_url / redirect_uris / terms_url / privacy_url.
\- 400 — { "data_location": ["An application's data location can't be changed after it is created."] } for a location other than the application's own, and { "data_location": ["This data location is not available yet."] } for "au" or "mx". Nothing is changed.
\- 503 — { "detail": "We couldn't confirm that this application is unused. Try again in a moment.", "code": "data_location_check_unavailable" } only while choosing the first application's location. Nothing is changed; retry.
\- 401: { "detail": "Invalid access token" } or { "detail": "Expired access token" } when the token is malformed or expired.
\- 403: { "detail": "Only organization owners and admins can manage applications." } when you are a member of the organization but not an owner or admin.
\- 403: { "detail": "Your access to this organization is suspended." } when your membership in the organization is suspended.
\- 403: { "detail": "You do not have permission to perform this action." } when the request has no Authorization header.
\- 404: { "detail": "Organization not found." } when the organization does not exist or you are not a member of it, or { "detail": "Application not found." } when the application is not in that organization.

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\
Einfügen in Verwenden Sie diesen Endpoint, damit jede Anwendung zum Kunden, zur Marke, zur Umgebung oder zum internen Anwendungsfall passt, den sie repräsentiert.Für Reseller ermöglicht dieser Endpoint, jede Kundenanwendung umzubenennen oder zu aktualisieren, ohne Zugangsdaten zwischen Kunden zu teilen. Für direkte Kunden hilft er dabei, Produkte, Regionen oder Umgebungen voneinander zu trennen, während alles unter einer Organisation bleibt.> [!NOTE] > > Dieser Endpoint aktualisiert die Metadaten der Anwendung. Der `api_key` bleibt unverändert, sofern Sie die Zugangsdaten nicht separat rotieren.## DatenstandortDer Datenstandort einer Anwendung (`data_location`) wird beim Anlegen der Anwendung festgelegt und lässt sich danach nicht mehr ändern: Eine Aktualisierung, die den bereits vorhandenen Standort angibt, wird akzeptiert, jeder andere Standort wird mit 400 beantwortet.Die einzige Ausnahme ist die Live-Anwendung, die zusammen mit Ihrer Organisation angelegt wird, bei der Registrierung oder durch die [E-Mail-Verifizierung](https://docs.didit.me/de/auth-api/verify-email.md). Die erste Aktualisierung, die einen `data_location` angibt, legt dessen Standort einmalig fest, sofern keiner der API-Schlüssel der Anwendung verwendet wurde und die Anwendung keine Sitzung für eine Verifizierung hat. Der Schritt **Benennen Sie Ihre erste Anwendung** in der Konsole nutzt dies, um den dort gewählten Standort zu speichern. Derzeit ist als Standort nur `eu` verfügbar, die Europäische Union (Irland). ## OpenAPI ````yaml de/openapi-auth.json PATCH /organizations/me/{org_id}/applications/{app_id}/ openapi: 3.0.0 info: version: 1.0.0 title: Didit Auth API description: >- API für programmatische Registrierung und Authentifizierung für Entwickler und KI-Agenten. Registrierung in 2 API-Aufrufen – kein Browser erforderlich. Die agentenfreundlichste Plattform für Identitätsverifizierung. ## Basis-URL Alle Endpoints in dieser Spezifikation werden unter `https://apx.didit.me/auth/v2` gehostet. Dies ist ein anderer Host als die Verifizierungs-API (`https://verification.didit.me/v3`). Zur Unterscheidung: Dieser Auth-Host stellt Ihre **JWT-Access-Tokens** aus und ermöglicht Ihnen das Auflisten und Verwalten Ihrer **Organisationen** und **Anwendungen**. Auf dem Verifizierungs-Host rufen Sie Sitzungen, Workflows, AML usw. auf und authentifizieren sich mit dem von dieser API zurückgegebenen **`api_key`**. ## So funktioniert der Auth-Flow 1. `POST /programmatic/register/` — E-Mail + Passwort übermitteln. 2. Erhalten Sie einen 6-stelligen alphanumerischen Code per E-Mail. 3. `POST /programmatic/verify-email/` — Code übermitteln. Sie erhalten ein JWT-`access_token`, ein `refresh_token`, eine Organisation und eine Standardanwendung mit `client_id` + `api_key` zurück. 4. Speichern Sie den `api_key`. Verwenden Sie ihn als `x-api-key` für jeden Aufruf von `https://verification.didit.me/v3/...`. 5. Auf jedem zukünftigen Rechner tauscht `POST /programmatic/login/` Ihre E-Mail + Ihr Passwort gegen ein neues JWT aus; rufen Sie anschließend `GET /organizations/me/` und die Anwendungs-Endpoints auf, um Anmeldedaten wiederherzustellen oder zu rotieren. Das JWT wird nur für die **Kontoverwaltungs**-Endpoints in dieser Spezifikation benötigt; der Traffic der Verifizierungs-API verwendet den langlebigen `api_key`, nicht das JWT. ## Konventionen - Alle Request- und Response-Bodys sind JSON (`Content-Type: application/json`). - **Verwenden Sie beim Testen von `POST /programmatic/register/` eine echte, zustellbare E-Mail-Adresse.** Der Endpoint sendet den Verifizierungscode synchron. Daher werden Adressen auf reservierten Test-Domains (`@example.com`, `@example.org`, `@*.test`, `@*.example`, `@*.invalid`) bei der E-Mail-Zustellung abgewiesen und die Anfrage gibt einen `500` zurück. Ersetzen Sie den Platzhalter `you@yourdomain.com` in den Beispielen durch ein Postfach, auf das Sie tatsächlich zugreifen können. - Validierungsfehler geben HTTP `400` mit einem von zwei Envelopes zurück: `{"field": ["message", ...]}` für Probleme auf Feldebene oder `{"detail": "message"}` für Geschäftsregelfehler. Einige wenige Validatoren (Passwortstärke bei der Registrierung, Code-Ablauf bei verify-email) antworten derzeit mit einem einfachen Array `["message"]` anstelle der feldbezogenen Form – dies ist eine bekannte serverseitige Inkonsistenz, daher sollte Client-Code beide Formen akzeptieren. - Authentifizierungsfehler werden als `{"detail": "..."}` mit HTTP `401` (ungültiges Bearer-Token) oder `403` (fehlendes Bearer-Token / unzureichende Berechtigungen) zurückgegeben. - Rate-Limit-Antworten enthalten ein `wait`-Feld mit der Abklingzeit in Sekunden. servers: - url: https://apx.didit.me/auth/v2 description: Produktions-Authentifizierungsserver security: [] tags: - name: Programmatic Auth description: >- Konto-Lebenszyklus mit E-Mail und Passwort: Registrieren, Verifizieren, Anmelden. Gibt das JWT-`access_token` zurück, das Sie für die Account-Management-Endpoints verwenden, sowie (bei Verifizierung) `client_id` und `api_key` Ihrer ersten Anwendung. - name: Account Management description: >- Authentifizierte Endpoints (JWT Bearer), die Organisationen auflisten und Anwendungen erstellen, abrufen oder aktualisieren. Verwenden Sie diese, um den `api_key` wiederherzustellen oder zu rotieren, mit dem Sie Verifizierungs-API-Aufrufe authentifizieren. paths: /organizations/me/{org_id}/applications/{app_id}/: patch: tags: - Account Management summary: Anwendung aktualisieren description: >- Anwendungsmetadaten aktualisieren (Name, URLs, Weiterleitungs-URIs). `api_key` und `client_id` werden niemals rotiert. `products` ist schreibgeschützt: Ein `products`-Schlüssel im Body wird ignoriert. `data_location` kann nach der Erstellung der Anwendung nicht mehr geändert werden, außer einmalig bei der mit Ihrer Organisation erstellten Live-Anwendung, solange diese ungenutzt ist (siehe Anfrage-Body). Erfordert ein Eigentümer-/Admin-JWT. operationId: update_organization_application parameters: - name: org_id in: path required: true description: UUID der Organisation, der die Anwendung gehört. schema: type: string format: uuid example: a1b2c3d4-5678-90ab-cdef-111111111111 - name: app_id in: path required: true description: UUID der zu aktualisierenden Anwendung. schema: type: string format: uuid example: b2c3d4e5-6789-01bc-defg-222222222222 requestBody: required: true description: >- Senden Sie nur die Felder, die Sie ändern möchten. PATCH-Semantik: Fehlende Felder bleiben erhalten. content: application/json: schema: $ref: '#/components/schemas/ApplicationUpdateRequest' examples: RenameCustomerApplication: summary: Umbenennen und auf eine neue Domain verschieben value: name: Acme Production App website_url: https://app.acme.example UpdateRedirectUris: summary: Zweite Redirect-URI hinzufügen value: redirect_uris: - https://acme.example/callback - https://staging.acme.example/callback UpdatePolicies: summary: AGB- und Datenschutz-URLs aktualisieren value: terms_url: https://acme.example/v2/terms privacy_url: https://acme.example/v2/privacy responses: '200': description: >- Anwendung aktualisiert. Die Antwort ist der vollständige Anwendungsdatensatz nach der Änderung, einschließlich `products`; `uuid`, `client_id` und `api_key` bleiben unverändert. content: application/json: schema: $ref: '#/components/schemas/Application' examples: Success: value: uuid: b2c3d4e5-6789-01bc-defg-222222222222 name: Acme Production App client_id: S9LIYGSoWNuGMLHsvEt9dQ api_key: sk_live_example_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx website_url: https://app.acme.example redirect_uris: - https://acme.example/callback terms_url: https://acme.example/terms privacy_url: https://acme.example/privacy description: null created_at: '2025-06-01T10:00:00Z' data_location: eu products: - product: identity status: enabled modules: user_verification: true business_verification: true case_management: true - product: transactions status: disabled modules: travel_rule: true case_management: true - product: authentication status: disabled modules: {} '400': description: >- Validierungsfehler im Request-Body: beispielsweise eine fehlerhafte URL, eine `data_location`, die noch nicht verfügbar ist, oder eine `data_location`, die nicht zur Anwendung gehört. Es wird nichts geändert. content: application/json: schema: $ref: '#/components/schemas/ValidationError' examples: InvalidUrl: value: website_url: - Enter a valid URL. DataLocationFixed: summary: Ein anderer Datenstandort als der der Anwendung value: data_location: - >- An application's data location can't be changed after it is created. DataLocationNotAvailable: summary: Ein Datenstandort, der demnächst verfügbar ist value: data_location: - This data location is not available yet. '401': description: >- Access-Token ist fehlerhaft, ungültig oder abgelaufen. Fordern Sie mit `POST /programmatic/login/` ein neues Token an. content: application/json: schema: $ref: '#/components/schemas/AuthError' examples: InvalidToken: value: detail: Invalid access token ExpiredToken: value: detail: Expired access token '403': description: >- Sie können diese Anwendung nicht aktualisieren. Ein Mitglied der Organisation, das kein Eigentümer oder Administrator ist, erhält `Only organization owners and admins can manage applications.` Ein Eigentümer oder Administrator, dessen Zugriff auf die Organisation ausgesetzt ist, erhält `Your access to this organization is suspended.` Eine Anfrage ohne einen `Authorization`-Header erhält `You do not have permission to perform this action.` content: application/json: schema: $ref: '#/components/schemas/AuthError' examples: NotOwnerOrAdmin: summary: Mitglied, das weder Eigentümer noch Administrator ist value: detail: >- Only organization owners and admins can manage applications. Suspended: summary: Mitgliedschaft ausgesetzt value: detail: Your access to this organization is suspended. MissingToken: summary: Kein Authorization-Header value: detail: You do not have permission to perform this action. '404': description: >- Die Organisation existiert nicht oder Sie sind kein Mitglied von ihr, oder die Anwendung existiert in dieser Organisation nicht. content: application/json: schema: $ref: '#/components/schemas/AuthError' examples: OrganizationNotFound: summary: Organisation nicht gefunden oder Sie sind kein Mitglied value: detail: Organization not found. ApplicationNotFound: summary: Keine solche Anwendung in dieser Organisation value: detail: Application not found. '503': description: >- Nur wenn die Aktualisierung einen anderen Datenstandort für die mit Ihrer Organisation erstellte Live-Anwendung auswählt: Didit konnte nicht bestätigen, dass die Anwendung noch keine Verifizierungssitzung hat, daher wurde nichts geändert. Wiederholen Sie die Anfrage. content: application/json: schema: $ref: '#/components/schemas/ServiceUnavailableError' examples: DataLocationCheckUnavailable: value: detail: >- We couldn't confirm that this application is unused. Try again in a moment. code: data_location_check_unavailable security: - BearerAuth: [] x-codeSamples: - lang: curl label: cURL source: >- curl -X PATCH "https://apx.didit.me/auth/v2/organizations/me/$ORG_ID/applications/$APP_ID/" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Acme Production App", "website_url": "https://app.acme.example" }' - lang: python label: Python source: |- from didit import Didit # Use the access token that account.login returns. client = Didit(account_token="YOUR_ACCESS_TOKEN") result = client.account.applications.update( "a1b2c3d4-5678-90ab-cdef-111111111111", "b2c3d4e5-6789-01bc-defg-222222222222", name="Acme Production App", website_url="https://app.acme.example", ) print(result) - lang: javascript label: Node.js source: |- import Didit from "@didit-protocol/sdk-node"; // Use the access token that account.login returns. const didit = new Didit({ accountToken: "YOUR_ACCESS_TOKEN" }); const result = await didit.account.applications.update( "a1b2c3d4-5678-90ab-cdef-111111111111", "b2c3d4e5-6789-01bc-defg-222222222222", { name: "Acme Production App", website_url: "https://app.acme.example", }, ); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Use the access token that account.login returns.\nclient := didit.NewClient(option.WithAccountToken(\"YOUR_ACCESS_TOKEN\"))\n\nresult, err := client.Account.Applications.Update(ctx, \"a1b2c3d4-5678-90ab-cdef-111111111111\", \"b2c3d4e5-6789-01bc-defg-222222222222\", didit.ApplicationUpdateRequest{\n\tName: didit.String(\"Acme Production App\"),\n\tWebsiteURL: didit.String(\"https://app.acme.example\"),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.ApplicationUpdateRequest; // Use the access token that account.login returns. Didit client = Didit.builder().accountToken("YOUR_ACCESS_TOKEN").build(); var result = client.account().applications().update("a1b2c3d4-5678-90ab-cdef-111111111111", "b2c3d4e5-6789-01bc-defg-222222222222", ApplicationUpdateRequest.builder() .name("Acme Production App") .websiteUrl("https://app.acme.example") .build()); System.out.println(result); - lang: php label: PHP source: >- account->applications->update('a1b2c3d4-5678-90ab-cdef-111111111111', 'b2c3d4e5-6789-01bc-defg-222222222222', [ 'name' => 'Acme Production App', 'website_url' => 'https://app.acme.example', ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Use the access token that account.login returns. didit = Didit::Client.new(account_token: "YOUR_ACCESS_TOKEN") result = didit.account.applications.update( "a1b2c3d4-5678-90ab-cdef-111111111111", "b2c3d4e5-6789-01bc-defg-222222222222", name: "Acme Production App", website_url: "https://app.acme.example" ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Use the access token that account.login returns. using var client = new DiditClient(new DiditClientOptions { AccountToken = "YOUR_ACCESS_TOKEN" }); var result = await client.Account.Applications.UpdateAsync("a1b2c3d4-5678-90ab-cdef-111111111111", "b2c3d4e5-6789-01bc-defg-222222222222", new ApplicationUpdateRequest { Name = "Acme Production App", WebsiteUrl = "https://app.acme.example", }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: ApplicationUpdateRequest: type: object description: >- PATCH-Body für Anwendungsmetadaten. Senden Sie nur die Felder, die Sie ändern möchten; weggelassene Felder bleiben erhalten. `uuid`, `client_id` und `api_key` können nicht aktualisiert werden. `products` ist schreibgeschützt: ein `products`-Schlüssel im Body wird ignoriert. `data_location` kann nach der Erstellung der Anwendung nicht mehr geändert werden: Die Angabe des bereits vorhandenen Standorts wird akzeptiert, und jeder andere Standort gibt 400 zurück. Die einzige Ausnahme ist die mit Ihrer Organisation erstellte Produktionsanwendung: Die erste Aktualisierung, die eine `data_location` benennt, wählt diese einmalig aus, solange noch kein API-Schlüssel der Anwendung verwendet wurde und sie keine Verifizierungssitzung hat. properties: name: type: string description: Anzeigename der Anwendung. example: Acme Production App website_url: type: string description: Mit dieser Anwendung verknüpfte Website- oder App-URL. example: https://app.acme.example redirect_uris: type: array items: type: string description: >- Zulässige Weiterleitungs-URIs für Weiterleitungs-Workflows im OAuth-Stil und Verifizierungs-Weiterleitungs-Workflows. example: - https://acme.example/callback terms_url: type: string description: >- URL der Nutzungsbedingungen, die im Verifizierungsablauf angezeigt wird. privacy_url: type: string description: Im Verifizierungsablauf angezeigte Datenschutzrichtlinien-URL. description: type: string description: Interne Beschreibung für die Anwendung. data_location: $ref: '#/components/schemas/ApplicationDataLocation' Application: type: object description: >- Vollständiger Anwendungsdatensatz. `uuid`, `client_id` und `api_key` ändern sich nach der Erstellung nie. `data_location` ändert sich ebenfalls nicht, außer einmalig bei der mit Ihrer Organisation erstellten Live-Anwendung, bevor diese verwendet wird (siehe Aktualisierungsanfrage). properties: uuid: type: string format: uuid description: Anwendungs-UUID. In nachfolgenden Aufrufen als `{app_id}` verwenden. example: b2c3d4e5-6789-01bc-defg-222222222222 name: type: string description: In der Didit Console angezeigter Anzeigename der Anwendung. example: Acme Production App client_id: type: string description: >- Öffentlicher Client-Identifikator, der sicher in OAuth-ähnliche Abläufe eingebunden werden kann. example: S9LIYGSoWNuGMLHsvEt9dQ api_key: type: string description: >- Langlebiges Secret (auch `client_secret` genannt). Als `x-api-key`-Header für jeden Aufruf an `https://verification.didit.me/v3/...` verwenden (Sitzungen, Workflows, AML usw.). Wie Zugangsdaten behandeln; niemals clientseitig offenlegen. Neue Schlüssel beginnen mit `sk_live_` (Live-Anwendung) oder `sk_test_` (Sandbox-Anwendung), gefolgt von 43 URL-sicheren Zeichen (Buchstaben, Ziffern, `-` und `_`). Schlüssel, die vor diesem Format erstellt wurden, haben kein Präfix und funktionieren weiterhin unverändert. Für 72 Stunden nach der Wiederherstellung Ihres Kontos geben Auflisten, Abrufen und Aktualisieren hier eine leere Zeichenkette anstelle des Schlüssels zurück. example: sk_live_example_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx website_url: type: string nullable: true description: Mit dieser Anwendung verknüpfte Website- oder App-URL. example: https://acme.example redirect_uris: type: array items: type: string description: >- Zulässige Weiterleitungs-URIs für Weiterleitungs-Workflows im OAuth-Stil und Verifizierungs-Weiterleitungs-Workflows. example: - https://acme.example/callback terms_url: type: string nullable: true description: >- URL der Nutzungsbedingungen, die im Verifizierungsablauf angezeigt wird. example: https://acme.example/terms privacy_url: type: string nullable: true description: Im Verifizierungsablauf angezeigte Datenschutzrichtlinien-URL. example: https://acme.example/privacy description: type: string nullable: true description: >- Interne Beschreibung für die Anwendung (wird Endbenutzern nicht angezeigt). created_at: type: string format: date-time example: '2025-06-01T10:00:00Z' data_location: $ref: '#/components/schemas/ApplicationDataLocation' products: type: array readOnly: true description: >- Die Produkte der Anwendung. Immer alle drei, in dieser Reihenfolge: `identity`, `transactions`, `authentication`. Eine neue Anwendung hat `identity` aktiviert, wobei jedes Modul eingeschaltet ist, und `transactions` sowie `authentication` deaktiviert. Schreibgeschützt: Ein `products`-Schlüssel im Body einer Erstellung oder Aktualisierung wird ignoriert. items: $ref: '#/components/schemas/ApplicationProduct' example: - product: identity status: enabled modules: user_verification: true business_verification: true case_management: true - product: transactions status: disabled modules: travel_rule: true case_management: true - product: authentication status: disabled modules: {} ValidationError: description: >- Validierungsfehler-Body. Der vorgesehene Envelope ist eine `{field: ["message", ...]}`-Map für Fehler auf Feldebene oder ein Single-Key-Envelope `{detail: "..."}` für Geschäftsregel-Fehler. Einige wenige Validatoren (Passwortstärke bei der Registrierung, Code-Gültigkeit bei verify-email) antworten derzeit mit einem einfachen Array `["message"]` – eine bekannte serverseitige Inkonsistenz. Das untenstehende Schema behält diesen Zweig mit einfachem Array bei, damit aus dieser Spezifikation generierter Client-Code heutige Antworten deserialisiert. Neuer Client-Code sollte dies jedoch als die relevante feldbezogene Form (`{password: [...]}` oder `{code: [...]}`) behandeln, und der Serververtrag wird sich an diese Struktur anpassen. oneOf: - type: object additionalProperties: type: array items: type: string example: email: - Enter a valid email address. - type: object properties: detail: type: string example: detail: An account with this email already exists. - type: array items: type: string example: - Invalid or expired verification code. AuthError: type: object description: >- Fehler-Envelope für Authentifizierung / Autorisierung / nicht gefundene Ressource. properties: detail: type: string example: Invalid access token ServiceUnavailableError: type: object description: >- Die Anfrage konnte derzeit nicht abgeschlossen werden und es wurde nichts geändert. Versuchen Sie es gleich noch einmal. properties: detail: type: string example: >- We couldn't confirm that this application is unused. Try again in a moment. code: type: string example: data_location_check_unavailable ApplicationDataLocation: type: string enum: - eu - au - mx description: >- Wo die Verifizierungsdaten der Anwendung gespeichert und verarbeitet werden, ausgewählt bei der Erstellung der Anwendung. `eu` ist die Europäische Union (Irland), die Standardeinstellung. `au` (Australien, Sydney) und `mx` (Mexiko) folgen in Kürze: Eine Anfrage, die diese angibt, führt zu einer 400-Antwort `This data location is not available yet.`. Die Sandbox-Anwendung einer Organisation befindet sich immer in der Europäischen Union. example: eu ApplicationProduct: type: object description: >- Ein Produkt einer Anwendung und dessen Status. Schreibgeschützt: Die Anwendungs-Endpoints geben es zurück und ignorieren es im Anfrage-Body. properties: product: type: string enum: - identity - transactions - authentication description: >- `identity` (Identitätsverifizierung), `transactions` (Transaktionsüberwachung) oder `authentication` (Authentifizierung). example: identity status: type: string enum: - enabled - early_access - disabled description: >- Gibt an, ob das Produkt für diese Anwendung aktiviert ist. `early_access` gilt nur für `authentication`, das Didit für Sie aktiviert. example: enabled modules: type: object additionalProperties: type: boolean description: >- Modulschalter des Produkts, jeweils `true` oder `false`. `identity` enthält `user_verification`, `business_verification` und `case_management`. `transactions` enthält `travel_rule` und `case_management`. `authentication` enthält keine (`{}`). `case_management` ist eine Einstellung, die sowohl unter `identity` als auch unter `transactions` angezeigt wird und daher in beiden denselben Wert hat. example: user_verification: true business_verification: true case_management: true required: - product - status - modules securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- RS256-signiertes JWT `access_token`, das von `POST /programmatic/login/` oder `POST /programmatic/verify-email/` zurückgegeben wird. Als `Authorization: Bearer ` senden. Die Standardlebensdauer beträgt 86400 Sekunden (24 Stunden). Dieses Token ist nur für die Account-Management-Endpoints auf `apx.didit.me/auth/v2` gültig. Die Verifizierungs-API (`verification.didit.me/v3`) verwendet stattdessen den langlebigen `api_key` als `x-api-key`. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.