Merge branch '827_Dokumentation_Tippfehler_in_der_Dokumentation_korrigieren' into 'main'

827_Dokumentation_Tippfehler_in_der_Dokumentation_korrigieren(planning#827)

See merge request !310

docs/getting-started/event-log/events.mdx

@@ -9,7 +9,7 @@ Rechtecke stehen für Ereignisse. Blau dargestellte Ereignisse werden vom Zustel
 
 ![Statusdiagramm](/images/status/status.svg)
 
-Das Akzeptieren oder Zurückweisen von Einreichungen auf einer rein technischen Ebene und trifft keine Aussage über die fachliche Korrektheit der Einreichungen.
+Das Akzeptieren oder Zurückweisen von Einreichungen findet auf einer rein technischen Ebene statt und trifft keine Aussage über die fachliche Korrektheit der Einreichungen.
 Gründe für technische Rückweisungen wären beispielsweise Probleme bei der Entschlüsselung oder Validierungsfehler der Datenstrukturen.
 In der folgenden Tabelle sind die möglichen Ereignisse, ihre Beschreibungen und die Autoren aufgeführt und beschrieben.
 

docs/getting-started/event-log/overview.mdx

@@ -11,15 +11,15 @@ Wie mit den Security-Event-Token (SET) umgegangen wird, wird in diesem Abschnitt
 
 ## Hintergrund
 
-Für die Übermittlung von Einreichungen zwischen Sendern und Empfängern soll gewährleistet werden, dass alle Schritte nachweissicher dokumentiert werden, um im Streitfall den Ablauf eines erfolgten Übermittlungsvorgang zweifelsfrei zu dokumentieren.
+Für die Übermittlung von Einreichungen zwischen Sendern und Empfängern soll gewährleistet werden, dass alle Schritte nachweissicher dokumentiert werden, um im Streitfall den Ablauf eines erfolgten Übermittlungsvorgangs zweifelsfrei zu dokumentieren.
 Zudem sollen diese Nachweise außerhalb der Submission API und der damit verbundenen Systeme genutzt werden können, damit diese Dritten einfach zur Verfügung gestellt werden können.
 SETs erfüllen diese Anforderungen durch folgende Merkmale:
 
 - Für jedes SET wird ein eindeutiger Herausgeber definiert (`iss`)
 - Jedes SET kann eindeutig einem konkreten fachlichen Kontext zugeordnet werden (`sub`)
-  - Mehrere SETs aus unterschiedliche fachlichen Kontexten können zu einem gemeinsamen Vorgang zusammengeführt werden (`txn`)
+  - Mehrere SETs aus unterschiedlichen fachlichen Kontexten können zu einem gemeinsamen Vorgang zusammengeführt werden (`txn`)
 - SETs können für unterschiedliche Ereignisse ausgeprägt werden und innerhalb dieser Ereignisse können Detailinformationen ergänzt werden, die diese Ereignisse näher beschreiben
-  - Über ein Zeitstempel (`iat`) können diese Ereignisse zudem konkreten Zeitpunkt zugeordnet werden
+  - Über einen Zeitstempel (`iat`) können diese Ereignisse zudem konkreten Zeitpunkt zugeordnet werden
 - Durch eine Signatur im JWS Format wird sichergestellt, dass alle SETs ihre Integrität erhalten und eindeutig dem Schlüsselinhaber als Ersteller zugeordnet werden können.
 
 Die Nutzung ist aber nicht auf die Klärung von Streitigkeiten zu technischen Übermittlungen beschränkt. SETs können aufgrund dieser Merkmale unter anderem auch für folgende Zwecke genutzt werden:
@@ -27,9 +27,10 @@ Die Nutzung ist aber nicht auf die Klärung von Streitigkeiten zu technischen Ü
 - oder als Nachweis für den Start von Fristen in Verwaltungsverfahren, die in der Regel dann beginnen, wenn eine zuständige Stelle Kenntnis von einer Einreichung hat oder wenn diese Einreichung in den Hoheitsbereich der empfangenden Stelle gelangt.
 
 In der Submission API werden SETs durch den Zustelldienst und das empfangende System erstellt.
-Während die SETs des Zustelldienstes dazu dienen, die korrekte Übermittlung an den Zustelldienst und die Inkenntnissetzung von empfangende Systemen über neue Einreichungen dokumentieren, sollen SETs des empfangenden Systems die Bestätigung oder Ablehnung der technische Verarbeitbarkeit einer Einreichung nachweisen.
+Während die SETs des Zustelldienstes dazu dienen, die korrekte Übermittlung an den Zustelldienst und die Inkenntnissetzung von empfangende Systemen über neue Einreichungen zu dokumentieren, sollen SETs des empfangenden Systems die Bestätigung oder Ablehnung der technischen Verarbeitbarkeit einer Einreichung nachweisen.
 
-Diese Zusammenhänge werden vereinfacht im folgenden Sequenzdiagramm veranschaulicht. Zusätzlich wird ersichtlich mit welchem Schlüssel die Einträge des Ereignisprotokoll jeweils signiert werden, d. h., mit dem Schlüssel des Zustelldienstes oder dem des empfangenden Systems.
+Diese Zusammenhänge werden vereinfacht im folgenden Sequenzdiagramm veranschaulicht. 
+Zusätzlich wird ersichtlich, mit welchem Schlüssel die Einträge des Ereignisprotokolls jeweils signiert werden, d. h., mit dem Schlüssel des Zustelldienstes oder dem des empfangenden Systems.
 
 <Mermaid>
 sequenceDiagram;

docs/getting-started/event-log/set-creation.mdx

@@ -9,7 +9,7 @@ import TabItem from '@theme/TabItem'
 
 ## Ereignis Payload {#ereignis-payload}
 
-Je nach SET ist ein Ereignis-Payload für das darin vorkommendes Ereignis vorgesehen.
+Je nach SET ist ein Ereignis-Payload für das darin vorkommende Ereignis vorgesehen.
 Auf der Seite [Ereignisse](./events.mdx) finden Sie eine Liste der Ereignisse und deren Struktur.
 
 :::caution Warnung
@@ -178,7 +178,7 @@ Mehr zu der Ereignis spezifischen Payload finden Sie auf dieser Seite under [Ere
 :::caution Warnung
 Für die SET Payload wird unter `$schema` ein Schema zur Validierung definiert.
 Entspricht ein SET Payload nicht dem definierten Schema wird es z.B. vom Zustelldienst und vom Empfänger zurückgewiesen.
-Es ist aktuell noch möglich kein `$schema` an zu geben. Dadurch findet keine Validation auf Seiten des Zustelldienst und des Empfänger statt.
+Es ist aktuell noch möglich, kein `$schema` anzugeben. Dadurch findet keine Validierung aufseiten des Zustelldienstes und des Empfängers statt.
 Dies wird in unspezifizierter Zukunft `deprecated` und alle SETs müssen dann ein valides Schema verwenden und angeben.
 
 Derzeit ist es auch noch möglich, Ereignisse auch ohne [Ereignis Payload](#ereignis-payload) zu senden.
@@ -191,7 +191,7 @@ Derzeit ist die Version [1.0.0](https://schema.fitko.de/fit-connect/set-payload/
 Mit diesem Schema `1.0.0` stellt auch der Zustelldienst seine SETs aus.
 Bis auf weiteres kann auch noch die Version [0.1.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) verwendet werden.
 Inhaltlich ist sie deckungsgleich mit der Version `1.0.0`.
-Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankündigung `deprecated` und sollte nicht mehr verwendet werden.
+Die Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit der Ankündigung `deprecated` bezeichnet und sollte nicht mehr verwendet werden.
 :::
 
 ```json
@@ -220,7 +220,7 @@ Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankünd
 
 ## SET Header
 
-Der Header eines SET enthält immer die gleichen drei Angaben.
+Der Header eines SETs enthält immer die gleichen drei Angaben.
 
 ```json
 {
@@ -243,7 +243,7 @@ values={[
 
 <TabItem value="java">
 
-Das Erzeugen eines SET besteht aus drei Schritten.
+Das Erzeugen eines SETs besteht aus drei Schritten.
 
 ```java
   public static SignedJWT buildEvent(String issuer, UUID caseId, UUID submissionId, FitConnectEvent event, Map<String, Object> payload, JWK jwk) {

docs/getting-started/event-log/set-validation.mdx

@@ -32,7 +32,7 @@ In der Payload des signierten SET MÜSSEN die folgenden [standardisierten Felder
 
 | Feld      | Inhalt                                             | Erläuterung                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 |-----------|----------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `$schema` | URL Referenz auf das verwendete SET-Payload-Schema | Gibt das SET-Payload-Schema an, dem das SET entspricht. Dieses Schema wird auch vom Zustelldienst validert. <br/><br/> Aktuell ist es noch möglich kein `$schema` anzugeben. In diesem Fall findet keine Validation im Zustelldienst statt und ist auch keine client-seitige Validierung möglich. Siehe [Einleitung](#einleitung) <br/><br/> Das Schema kann zur client-seitigen Validierung der SET Payload von der referenzierten URL bezogen werden. Auch eine client-seitige Validierung durch statisch hinterlegten Schema Versionen ist möglich, solange die von uns vorgegebenen Versionen unterstützt werden. Derzeit ist die Version [1.0.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) des SET-Payload-Schemas aktuell. Mit diesem Schema `1.0.0` stellt auch der Zustelldienst seine SETs aus. Bis auf Weiteres kann auch noch die Version [0.1.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) verwendet werden. Inhaltlich ist sie deckungsgleich mit der Version `1.0.0`. Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankündigung `deprecated` und sollte nicht mehr verwendet werden. <br/><br/> Aktuell muss eine SET-Payload Validation beide SET-Payload-Schema Versionen (`0.1.0` und `1.0.0`) sowie ein fehlendes SET-Payload-Schema unterstüzten. |
+| `$schema` | URL Referenz auf das verwendete SET-Payload-Schema | Gibt das SET-Payload-Schema an, dem das SET entspricht. Dieses Schema wird auch vom Zustelldienst validert. <br/><br/> Aktuell ist es noch möglich kein `$schema` anzugeben. In diesem Fall findet keine Validation im Zustelldienst statt und ist auch keine client-seitige Validierung möglich. Siehe [Einleitung](#einleitung) <br/><br/> Das Schema kann zur client-seitigen Validierung der SET Payload von der referenzierten URL bezogen werden. Auch eine client-seitige Validierung durch statisch hinterlegte Schema-Versionen ist möglich, solange die von uns vorgegebenen Versionen unterstützt werden. Derzeit ist die Version [1.0.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) des SET-Payload-Schemas aktuell. Mit diesem Schema `1.0.0` stellt auch der Zustelldienst seine SETs aus. Bis auf Weiteres kann auch noch die Version [0.1.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) verwendet werden. Inhaltlich ist sie deckungsgleich mit der Version `1.0.0`. Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankündigung `deprecated` und sollte nicht mehr verwendet werden. <br/><br/> Aktuell muss eine SET-Payload Validation beide SET-Payload-Schema Versionen (`0.1.0` und `1.0.0`) sowie ein fehlendes SET-Payload-Schema unterstüzten. |
 | `jti`     | UUID des Token                                     | Die JWT ID ist eine eindeutige ID des SET bzw. JWT. Es wird eine zufällige UUID verwendet.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | `iss`     | ID des Token Issuers                               | Diese Angabe dient dazu, um herauszufinden, wer den Token ausgestellt hat. Für SETs, die vom Zustelldienst ausgestellt sind, wird die Host-Adresse (API-URL) verwendet. Bei SETs von empfangenden Systemen ist die `destinationId`, an der dieser die Submission schickt.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | `iat`     | Timestamp (UNIX-Format)                            | Zeitpunkt der Ausstellung des SET.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
@@ -330,7 +330,7 @@ boolean verifyZustelldienstSignature(SignedJWT securityEventToken, String keyId)
 </Tabs>
 
 :::tip Hinweis
-In der [Staging- und Produktivumgebung](../environments.mdx) ist das vom Zustelldienst für die Signaur der SET genutzte Schlüsselpaar über ein Zertifikat aus der Verwaltungs-PKI abgesichert (Attribut `x5c` des JWK).
+In der [Staging- und Produktivumgebung](../environments.mdx) ist das vom Zustelldienst für die Signatur der SET genutzte Schlüsselpaar über ein Zertifikat aus der Verwaltungs-PKI abgesichert (Attribut `x5c` des JWK).
 Für eine vollständige Prüfung der Authentizität der augestellen SET SOLLTE daher – analog zur Prüfung der öffentlichen Schlüssel im Rahmen der Verschlüsselung – [eine Zertifikatsprüfung durchgeführt werden](../../sending/encrypt.mdx#certificateValidation).
 :::
 
@@ -455,6 +455,6 @@ boolean verifyClientSignature(SignedJWT securityEventToken, String keyId) {
 </Tabs>
 
 :::tip Hinweis
-In der [Staging- und Produktivumgebung](../environments.mdx) ist das von empfangenden Systemen (Subscriber) für die Signaur der SET genutzte Schlüsselpaar über ein Zertifikat aus der Verwaltungs-PKI abgesichert (Attribut `x5c` des JWK).
+In der [Staging- und Produktivumgebung](../environments.mdx) ist das von empfangenden Systemen (Subscriber) für die Signatur der SET genutzte Schlüsselpaar über ein Zertifikat aus der Verwaltungs-PKI abgesichert (Attribut `x5c` des JWK).
 Für eine vollständige Prüfung der Authentizität der augestellen SET SOLLTE daher – analog zur Prüfung der öffentlichen Schlüssel im Rahmen der Verschlüsselung – [eine Zertifikatsprüfung durchgeführt werden](../../sending/encrypt.mdx#certificateValidation).
 :::

docs/receiving/certificate.mdx

@@ -36,7 +36,7 @@ Dieses Skript erstellt zwei JSON Web Keys (JWKs):
 - ein JWK mit einem [öffentlichen Schlüssel zum Verschlüsseln](../details/crypto.md#vorgaben-zur-ver--und-entschl%C3%BCsselung-von-daten) <br/>
 - ein JWK mit einen [öffentlichen Schlüssel zum Überprüfen von Signaturen](../details/crypto.md#vorgaben-zur-signaturerstellung-und--pr%C3%BCfung).
 
-Diese beiden JWKs mit öffentlichen Schlüsseln benötigen Sie zum Konfiguration eines Zustellpunkts im Self-Service-Portal der FITKO. <br/>
+Diese beiden JWKs mit öffentlichen Schlüsseln benötigen Sie zur Konfiguration eines Zustellpunkts im Self-Service-Portal der FITKO. <br/>
 Zudem erzeugt das Skript zwei weitere JWKs: Diese JWKs enthalten die privaten Schlüssel, die zu den öffentlichen Schlüsseln gehören. <br/>
 
 ### Herunterladen der FIT-Connect Tools

docs/receiving/decrypt.mdx

@@ -24,7 +24,7 @@ Die vollständigen Beispiele finden Sie [hier](https://git.fitko.de/fit-connect/
 }>
 <TabItem value="java">
 
-Wenn ein empfangendes System (z.B. eine Fachanwendung oder virtuelle Poststelle) einen Einreichung erhält, kann es diese
+Wenn ein empfangendes System (z.B. eine Fachanwendung oder virtuelle Poststelle) eine Einreichung erhält, kann es diese
 mithilfe des privaten Schlüssels und der Java-Bibliothek [`nimbus-jose-jwt`](https://connect2id.com/products/nimbus-jose-jwt) entschlüsseln.
 
 ```xml

docs/receiving/destination.mdx

@@ -35,7 +35,7 @@ In diesem Bereich vergeben Sie einen Namen, unter dem der Zustellpunkt im Self-S
 
 Sie können Ihr empfangendes System per Callback (Webhook) [über neue Einreichungen informieren lassen](./notification.mdx).
 Die Nutzung eines Callbacks ist grundsätzlich optional, wird jedoch empfohlen.
-Tragen Sie dafür die Adresse des Callbacks und ein Geheimis zur Absicherung ein.
+Tragen Sie dafür die Adresse des Callbacks und ein Geheimnis zur Absicherung ein.
 Die Nutzung eines Callbacks ohne ein Geheimnis ist nicht möglich.
 
 <div class="center">
@@ -43,7 +43,7 @@ Die Nutzung eines Callbacks ohne ein Geheimnis ist nicht möglich.
        src={useBaseUrl('/images/ssp/add-destination-section-2.png')}/>
 </div>
 
-Um im Fehlerfall Kontakt aufzunehmen benötigt der Betreiber des Zustelldienstes Kontaktdaten der Organisation, die den Zustellpunkt betreibt.
+Um im Fehlerfall Kontakt aufzunehmen, benötigt der Betreiber des Zustelldienstes Kontaktdaten der Organisation, die den Zustellpunkt betreibt.
 
 <div class="center">
   <img width="600" alt="Formular zum Anlegen eines neuen Zustellpunktes - Teil 3"
@@ -51,7 +51,7 @@ Um im Fehlerfall Kontakt aufzunehmen benötigt der Betreiber des Zustelldienstes
 </div>
 
 Aktivieren Sie die von Ihnen unterstützten Antwortkanäle.
-Sofern Sie keinen Antwortkanal anbieten oder der Antragsteller keinen den angebotenen Kanäle nutzen kann, müssen Sie ihm auf dem Postweg antworten.
+Sofern Sie keinen Antwortkanal anbieten oder der Antragsteller keinen der angebotenen Kanäle nutzen kann, müssen Sie ihm auf dem Postweg antworten.
 
 <div class="center">
   <img width="600" alt="Formular zum Anlegen eines neuen Zustellpunktes - Teil 4"
@@ -85,7 +85,7 @@ In diesem Bereich dürfen **nur die öffentlichen Schlüssel** Ihres Fachverfahr
 
 Unter <b>Verwaltungsleistungen</b> werden ein eindeutiger Leistungsindikator, eine Region aus der eine Anfrage zulässig ist sowie die URI des verwendeten Fachschemas erwartet.
 
-Wurden alle Informationen und Schlüssel in korrekter Form übergeben wird der Zustellpunkt erstellt.
+Wurden alle Informationen und Schlüssel in korrekter Form übergeben, wird der Zustellpunkt erstellt.
 
 <div class="center">
   <img width="600" alt="Destination wurde erfolgreich angelegt"

docs/receiving/overview.mdx

@@ -5,7 +5,7 @@ title: Überblick
 import Mermaid from '@site/src/components/Mermaid'
 
 In den folgenden Abschnitten werden alle notwendigen Schritte für den Empfang von Einreichungen und deren Verarbeitung beschrieben.
-Der komplette Prozess vom Anlegen eines Zustellpunktes bis zur Bestätigung des erfolgreichen Antrgsempfangs ist im unten dargestellte Prozessablauf beschrieben.
+Der komplette Prozess vom Anlegen eines Zustellpunktes bis zur Bestätigung des erfolgreichen Antragsempfangs ist im unten dargestellten Prozessablauf beschrieben.
 
 An FIT-Connect angebundene Subscriber rufen Einreichungen immer selbst aktiv bei FIT-Connect ab (via GET-Requests).
 Subscriber müssen also **nicht** über einen offenen Port aus dem Internet erreichbar sein, um Einreichungen empfangen zu können.

docs/receiving/process-and-acknowledge.mdx

@@ -22,7 +22,7 @@ Um diese Events bzw. ein entsprechendes Event korrekt an den Zustelldienst zu ve
 ## Erstellung und Versand eines Security Event Token (SET)
 
 Ein Security Event Token (SET) kann dann über den Endpunkt <ApiLink api="submission-api" to="/v1/cases/{caseId}/events" withMethod="post" /> im zugehörigen Vorgang hinterlegt werden und ist anschließend für sendende Systeme abrufbar.
-Bei der Übermittlung des das SET an den Zustelldienst wird dieses vom Zustelldienst syntaktisch und auf eine korrekte Signatur geprüft.
+Bei der Übermittlung des SETs an den Zustelldienst wird dieses vom Zustelldienst syntaktisch und auf eine korrekte Signatur geprüft.
 Sind alle Prüfungen erfolgreich durchlaufen, wird das SET im Event Log abgespeichert.
 
 Der öffentliche Schlüssel des hierbei verwendeten Schlüsselpaares muss zuvor [über das Self-Service-Portal](destination.mdx) oder [über die Submission API](../details/destination-management.mdx#bearbeiten-eines-zustellpunktes) im Zustelldienst hinterlegt werden.
@@ -90,8 +90,8 @@ private static void validateTrueOrElseThrow(boolean expression, String msg) {
 
 ```
 
-  Die Payload- und Header-Attribute des SET müssen wie oben beschrieben definiert werden (siehe markierte Zeilen). Mehr Informationen zu dem SET Aufbau finden Sie unter [SET Erzeugen](../getting-started/event-log/set-creation.mdx)
-  Im dritten markierten Block wird das SET mit dem Schlüssel signiert. Anschließend kann der serialisierte Wert an den Endpunkt <ApiLink api="submission-api" to="/v1/cases/{caseId}/events" withMethod="post" /> gesendet werden.
+  Die Payload- und Header-Attribute des SETs müssen wie oben beschrieben definiert werden (siehe markierte Zeilen). Mehr Informationen zu dem SET-Aufbau finden Sie unter [SET Erzeugen](../getting-started/event-log/set-creation.mdx)
+  Im folgenden Block wird das SET mit dem Schlüssel signiert. Anschließend kann der serialisierte Wert an den Endpunkt <ApiLink api="submission-api" to="/v1/cases/{caseId}/events" withMethod="post" /> gesendet werden.
 
   ```java
   // Schlüssel validieren

docs/receiving/verification.mdx

@@ -7,7 +7,7 @@ import Tabs from '@theme/Tabs'
 import TabItem from '@theme/TabItem'
 
 Nachdem das empfangende System eine Einreichung empfangen hat, muss es diese überprüfen.
-Nach der Überprüfung muss entweder ein Empfangsbestätigung ("accept submission") oder Zurückweisung ("reject submission")
+Nach der Überprüfung muss entweder eine Empfangsbestätigung ("accept submission") oder eine Zurückweisung ("reject submission")
 gesendet werden.
 Dies ist wichtig, um neben der Prüfung von technischen Fehlern auch einen [bösartigen Austausch von einzelnen Anlagen](#integrity) zu verhindern.
 
@@ -243,7 +243,7 @@ Starten wir mit den **Fachdaten**:
 
     a. Wenn ja: Die Integrität der Fachdaten ist sichergestellt.
 
-    b. Wenn nein: Die Integrität der Fachdaten ist nicht gestellt. Die Fachdaten wurden durch ein Zwischensystem verändert!
+    b. Wenn nein: Die Integrität der Fachdaten ist nicht sichergestellt. Die Fachdaten wurden durch ein Zwischensystem verändert!
 
 <!-- TODO: Beschreibung, was im Fall einer Integritätsverletzung getan werden sollte. -->
 
@@ -255,7 +255,7 @@ Nun zu den **Anhängen**:
 
     a. Wenn ja: Die Integrität des Anhangs ist sichergestellt.
 
-    b. Wenn nein: Die Integrität des Anhangs ist nicht gestellt. Der Anhang wurden durch ein Zwischensystem verändert!
+    b. Wenn nein: Die Integrität des Anhangs ist nicht sichergestellt. Der Anhang wurde durch ein Zwischensystem verändert!
 
 <!-- TODO: Beschreibung, was im Fall einer Integritätsverletzung getan werden sollte. -->
 
@@ -375,7 +375,7 @@ Nun zu den **Anhängen**:
 
 Stimmt der Identifier `publicServiceType/identifier` im Metadatensatz mit dem der Submission `serviceType/identifier` (in der Submission API) überein?
 
-Die Verwarbeitung sollte mit dem `identifier` aus dem Metadatensatz fortgesetzt werden.
+Die Verarbeitung sollte mit dem `identifier` aus dem Metadatensatz fortgesetzt werden.
 
 ```json
 {

docs/sending/accept-reject.mdx

@@ -562,7 +562,7 @@ Der Hash der Anlage im Metadatensatz (`contentStructure/attachments[]/hash`) pas
 Bei Fehlern, die sich auf die Konsistenz der Daten in FIT-Connect beziehen,
 wenden Sie sich bitte an den [FIT-Connect Service Desk](/contact).
 Geben Sie hierbei, soweit vorhanden, die IDs des Vorgangs (`destinationId`, `submissionId`, `caseId`) sowie die
-verwendete Client-ID (nicht das Secret!) an.
+verwendete Client-ID (nicht das Client-Secret!) an.
 
 #### Inkonsistentes Ereignis-Protokoll {#invalid-event-log}
 

docs/sending/get-destination.mdx

@@ -36,7 +36,7 @@ Das Ergebnis der Anfrage enthält daher neben der eigentlichen (Teil-)Ergebnisme
 Die zurückgegebene Teilergebnismenge ist standardmäßig auf 100 Einträge limitiert und kann über den GET-Parameter `limit` auf maximal 500 Einträge erweitert werden.
 Über den GET-Parameter `offset` können weitere Teilmengen der Ergebnismenge ermittelt werden.
 
-Der Endpunkt <ApiLink api="routing-api" to="/routes" /> ist auf die Anzahl von Anfragen in Zeitfenstern beschränkt. Es kann also vorkommen, das der Dienst einen `HTTP-Status-Code` `429` zurückliefert. Um diese Beschränkung auswerten zu können liefert der Endpunkt entspechende [RateLimit-Headers](../getting-started/rate-limiting.md) bei jeder Antwork zurück.
+Der Endpunkt <ApiLink api="routing-api" to="/routes" /> ist auf die Anzahl von Anfragen in Zeitfenstern beschränkt. Es kann also vorkommen, das der Dienst einen `HTTP-Status-Code` `429` zurückliefert. Um diese Beschränkung auswerten zu können liefert der Endpunkt entspechende [RateLimit-Headers](../getting-started/rate-limiting.md) bei jeder Antwort zurück.
 
 Beispiele für das Ermitteln der benötigten Daten:
 
@@ -159,12 +159,12 @@ Ein Beispiel für ein JWKS ist in folgendem Ausschnitt dargestellt:
 }
 ```
 
-Zur Prüfung der Signatur der Adressierungsinformationen muss der passenden Schlüssel mit der im `kid`-Header der Adressierungsinformationen hinterlegten Schlüssel-ID im JWKS ermittelt werden.
+Zur Prüfung der Signatur der Adressierungsinformationen muss der passende Schlüssel mit der im `kid`-Header der Adressierungsinformationen hinterlegten Schlüssel-ID im JWKS ermittelt werden.
 Anschließend kann mit diesem und einer entsprechenden Bibliothek eine Signaturprüfung erfolgen.
 
 #### Prüfung von Leistungsschlüssel/ARS {#checkservices}
 Zusätzlich sollte geprüft werden, ob der gegenüber der Routing-API angefragte Leistungsschlüssel und ARS zu einer der in den Adressierungsinformationen angegeben Kombinationen aus Leistungsschlüssel und ARS passt.
-Erfolgt eine Anfrage auf Basis einer über die Routing API ermittelten Area-ID (anhand einer Postleitzahl bzw. eines Gebeitsnamens), so muss an dieser Stelle auf das korrekte Mapping des Routingdienstes zw. Postleitzahl/Gebeitsnamen und ARS vertraut werden, sodass eine Prüfung des ARS durch den Sender keinen Mehrwert bietet und daher ausgelassen werden kann.
+Erfolgt eine Anfrage auf Basis einer über die Routing API ermittelten Area-ID (anhand einer Postleitzahl bzw. eines Gebietsnamens), so muss an dieser Stelle auf das korrekte Mapping des Routingdienstes zw. Postleitzahl/Gebietsnamen und ARS vertraut werden, sodass eine Prüfung des ARS durch den Sender keinen Mehrwert bietet und daher ausgelassen werden kann.
 
 #### Code-Beispiel
 
@@ -313,7 +313,7 @@ eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjNTNjd6UVE3QWFMdHFuSkthV2Y3N0FjM1d3
 ```
 
 #### Erzeugung der vollständigen Signatur inklusive Payload
-Die Prüfung der Signatur kann nur auf einer vollständige Signatur erfolgen.
+Die Prüfung der Signatur kann nur auf einer vollständigen Signatur erfolgen.
 Für die Umwandlung einer Detached Signature in eine gewöhnliche JSON Web Signature muss der Payload (`destinationParameters`) als Base64-URL-Encoded String der Signature hinzugefügt werden.
 
 Dabei ist für das JSON des Payload zu beachten, dass
@@ -459,7 +459,7 @@ Die zurückgegebene Teilergebnismenge ist standardmäßig auf 100 Einträge limi
 
 Die `id` eines Gebietes aus der Ergebnismenge kann im Endpunkt <ApiLink api="routing-api" to="/areas" /> als Identifikator (`areaId`) eines verwaltungspolitischen Gebietes verwendet werden.
 
-Der Endpunkt <ApiLink api="routing-api" to="/areas" /> ist auf die Anzahl von Anfragen in Zeitfenstern beschränkt. Es kann also vorkommen, das der Dienst einen `HTTP-Status-Code` `429` zurückliefert. Um diese Beschränkung auswerten zu können liefert der Endpunkt entspechende [RateLimit-Headers](../getting-started/rate-limiting.md) bei jeder Antwork zurück.
+Der Endpunkt <ApiLink api="routing-api" to="/areas" /> ist auf die Anzahl von Anfragen in Zeitfenstern beschränkt. Es kann also vorkommen, das der Dienst einen `HTTP-Status-Code` `429` zurückliefert. Um diese Beschränkung auswerten zu können liefert der Endpunkt entspechende [RateLimit-Headers](../getting-started/rate-limiting.md) bei jeder Antwort zurück.
 
 Beispiele für die Suche:
 

docs/sending/start-submission.mdx

@@ -21,7 +21,7 @@ Der Endpunkt erwartet folgende Parameter:
 
 - Eine Destination-ID. Dies ist die eindeutige UUID des Zustellpunktes, an den die Einreichung vermittelt werden soll (`destinationId`). Im Artikel [Zustellpunkt Ermitteln](../sending/get-destination.mdx) wird beschrieben wie diese ermittelt werden kann.
 - Die Liste der angekündigten Anlagen (`announcedAttachments`). Dies ist eine Liste der Attachment-IDs aller Anlagen, die mit der Einreichung hochgeladen werden sollen. Die Liste enthält [eine UUIDv4](https://de.wikipedia.org/wiki/Universally_Unique_Identifier#(Pseudo)zuf%C3%A4llig_generierte_UUIDs_(Version_4)) für jedes Attachment. Die UUIDs müssen vom sendenden System selbst generiert werden. Für alle `announcedAttachments` muss anschließend das jeweilige Attachment hochgeladen werden (siehe [Anlagen hochladen](./attachments.mdx), bevor sich die Einreichung im Schritt [Einreichung versenden](submit.mdx) abschließen lässt.
-- Der Typ der Verwaltungsleistung (`serviceType`). Dies ist eine Beschreibung der Art der Verwaltungsleistung. Die angegebene Verwaltungsleistung muss der Verwaltungsleistung der Einreichung und einem der angebotenen Verwaltungsleistung des Zustellpunkts entsprechen. Für die jeweilige Verwaltungsleistung muss immer sowohl ein Name (`name`), als auch ein eindeutiger Identifier (`identifier`) angegeben werden. Der Identifier besteht aus einem einem Leistungsschlüssel und dem Präfix `urn:de:fim:leika:leistung:`. Ist für die gegebene Verwaltungsleistung kein Leistungsschlüssel vorhanden, kann die Verwaltungsleistung übergangsweise über die Angabe einer anderen eindeutigen Schema-URN beschrieben werden. Bestehende Leistungssschlüssel können [über das FIM-Portal](https://fimportal.de/) oder [über die LeiKa-Suche (inoffiziell)](https://opengovtech.de/leika/) ermittelt werden.
+- Der Typ der Verwaltungsleistung (`serviceType`). Dies ist eine Beschreibung der Art der Verwaltungsleistung. Die angegebene Verwaltungsleistung muss der Verwaltungsleistung der Einreichung und einem der angebotenen Verwaltungsleistung des Zustellpunkts entsprechen. Für die jeweilige Verwaltungsleistung muss immer sowohl ein Name (`name`), als auch ein eindeutiger Identifier (`identifier`) angegeben werden. Der Identifier besteht aus einem Leistungsschlüssel und dem Präfix `urn:de:fim:leika:leistung:`. Ist für die gegebene Verwaltungsleistung kein Leistungsschlüssel vorhanden, kann die Verwaltungsleistung übergangsweise über die Angabe einer anderen eindeutigen Schema-URN beschrieben werden. Bestehende Leistungssschlüssel können [über das FIM-Portal](https://fimportal.de/) oder [über die LeiKa-Suche (inoffiziell)](https://opengovtech.de/leika/) ermittelt werden.
 - Optional kann hier auch ein Callback hinterlegt werden, um Benachrichtigungen über neue Events der Einreichung zu erfahren. Näheres dazu wird im Artikel [Verwendung von Callbacks](../details/callbacks.mdx) beschrieben.
 
 :::note Hinweis

docs/sending/submit.mdx

@@ -13,7 +13,7 @@ Diese PUT Methode kann nur erfolgreich durchgeführt werden, wenn folgende Bedin
 - Alle angekündigten Anlagen (`announcedAttachments` im Endpunkt <ApiLink api="submission-api" to="/v1/submissions" withMethod="post" />) wurden hochgeladen.
 - Sowohl der Metadatensatz als auch der Fachdatensatz müssen verschlüsselt im JWE-Format vorliegen.
 
-Wenn die Nutzung dieses Endpunkts erfolgreich war, wechselt die Einreichung in den Status `submitted` und die vollständige Einreichung (Anlagen, Metadatensatz und Fachdatz) liegt nun für das empfangende System zum Abruf bereit.
+Wenn die Nutzung dieses Endpunkts erfolgreich war, wechselt die Einreichung in den Status `submitted` und die vollständige Einreichung (Anlagen, Metadatensatz und Fachdatensatz) liegt nun für das empfangende System zum Abruf bereit.
 Bei nicht erfolgter Abholung einer Einreichung durch ein empfangendes System (Fachverfahren) erfolgt eine Benachrichtigung des technischen Kontakts auf Empfängerseite 3 Tage nach Eingang der Einreichung. 
 Sollte sich eine Einreichung mehr als 14 Tage im Status `submitted` befinden, wird [diese automatisch vom Server abgewiesen](../getting-started/notifications-and-deletion-deadlines.mdx) und in den Status `rejected` überführt.