Code review fixes.

Author: samod

fern/docs/pages/adaas/delete-phases.mdx

@@ -6,23 +6,23 @@ In the most common extraction use cases, there is nothing to do and snap-ins may
 ### Triggering event
 
 Airdrop initiates the data delete phase when the sync is deleted from DevRev.
-It is started by sending the worker a message with eventType: `EXTRACTION_DATA_DELETE`.
+It is started by sending the worker a message with with event of type `EVENT_TYPE`: `EXTRACTION_DATA_DELETE`.
 
 ### Snap-in response
 
-The worker must respond to Airdrop with a message with eventType `EXTRACTION_DATA_DELETE_DONE` when done or
+The worker must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_DATA_DELETE_DONE` when done or
 `EXTRACTION_DATA_DELETE_ERROR` in case of an error.
 
 ## Attachments deletion
 
 
 ### Triggering event
 
-Airdrop initiates the attachments delete phase when the Sync is deleted from DevRev.
-It is started by sending the span-in a message with eventType: `EXTRACTION_ATTACHMENTS_DELETE`.
+Airdrop initiates the attachments delete phase when the sync data is deleted from DevRev.
+It is started by sending the span-in a message with with event of type `EVENT_TYPE`: `EXTRACTION_ATTACHMENTS_DELETE`.
 
 ### Snap-in response
 
-The snap-in must respond to Airdrop with a message with eventType `EXTRACTION_ATTACHMENTS_DELETE_DONE` when done,
+The snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_ATTACHMENTS_DELETE_DONE` when done,
 or `EXTRACTION_ATTACHMENTS_DELETE_ERROR` in case of an error.
 

fern/docs/pages/adaas/extracting-attachments.mdx

@@ -1,26 +1,27 @@
-For the attachment extraction phase of the import process, the extractor has to upload each attachment to DevRev’s S3 using the `S3Interact` API.
+For the attachment extraction phase of the import process, the extractor has to upload each attachment to DevRev’s S3
+using the `S3Interact` API.
 
 ## Triggering event
 
-Airdrop initiates the Attachment Extraction by starting the snap-in with a message with eventType `EXTRACTION_ATTACHMENTS_START`
-when transitioning to the Data Extraction phase.
+Airdrop initiates the attachment extraction by starting the snap-in with a message with with event of type `EVENT_TYPE` `EXTRACTION_ATTACHMENTS_START`
+when after the data is extracted, transformed and loaded to DevRev.
 
-During the Attachment Extraction phase,
-the snap-in extracts attachments from the External System and uploads them as Artifacts to DevRev.
+During the attachment extraction phase,
+the snap-in extracts attachments from the external system and uploads them as artifacts to DevRev.
 
-The snap-in must respond to Airdrop with a message with eventType `EXTRACTION_ATTACHMENTS_PROGRESS` together with an optional progress estimate and relevant Artifacts
+The snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_ATTACHMENTS_PROGRESS` together with an optional progress estimate and relevant Artifacts
 when it extracts some data and the maximum snap-in runtime (12 minutes) has been reached.
 
-The snap-in must respond to Airdrop with a message with eventType `EXTRACTION_ATTACHMENTS_DELAY` and specify a back-off time
-when the extraction has been rate-limited by the External System and back-off is required.
+The snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_ATTACHMENTS_DELAY` and specify a back-off time
+when the extraction has been rate-limited by the external system and back-off is required.
 
-In both cases, Airdrop starts the snap-in with a message with eventType `EXTRACTION_ATTACHMENTS_CONTINUE`.
+In both cases, Airdrop starts the snap-in with a message with with event of type `EVENT_TYPE` `EXTRACTION_ATTACHMENTS_CONTINUE`.
 The restart is immediate (in case of `EXTRACTION_ATTACHMENTS_PROGRESS`) or delayed
 (in case of `EXTRACTION_ATTACHMENTS_DELAY`).
 
-Once the Attachment Extraction phase is done, the snap-in must respond to Airdrop with a message with eventType `EXTRACTION_ATTACHMENTS_DONE`.
+Once the attachment extraction phase is done, the snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_ATTACHMENTS_DONE`.
 
-If Attachment Extraction failed, the snap-in must respond to Airdrop with a message with eventType `EXTRACTION_ATTACHMENTS_ERROR`.
+If attachment extraction failed, the snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_ATTACHMENTS_ERROR`.
 
 ## Snap-in response
 

fern/docs/pages/adaas/extracting-data.mdx

@@ -8,25 +8,25 @@ so that it can extract only items created and/or updated since this date in the
 
 ## Triggering event
 
-Airdrop initiates data extraction by starting the snap-in with a message with eventType `EXTRACTION_DATA_START`
+Airdrop initiates data extraction by starting the snap-in with a message with with event of type `EVENT_TYPE` `EXTRACTION_DATA_START`
 when transitioning to the data extraction phase.
 
 During the data extraction phase, the snap-in extracts data from an external system,
 prepares batches of data and uploads them in the form of Artifacts to DevRev.
 
-The snap-in must respond to Airdrop with a message with eventType `EXTRACTION_DATA_PROGRESS`,
+The snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_DATA_PROGRESS`,
 together with an optional progress estimate and relevant artifacts
 when it extracts some data and the maximum ADaaS snap-in runtime (12 minutes) has been reached.
 
 If the extraction has been rate-limited by the external system and back-off is required, the snap-in must respond to
-Airdrop with a message with eventType `EXTRACTION_DATA_DELAY` and specifying back-off time with `delay` attribute.
+Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_DATA_DELAY` and specifying back-off time with `delay` attribute.
 
-In both cases, Airdrop starts the snap-in with a message with eventType `EXTRACTION_DATA_CONTINUE`.
+In both cases, Airdrop starts the snap-in with a message with with event of type `EVENT_TYPE` `EXTRACTION_DATA_CONTINUE`.
 The restarting is immediate (in case of `EXTRACTION_DATA_PROGRESS`) or delayed (in case of `EXTRACTION_DATA_DELAY`).
 
-Once the data extraction is done, the snap-in must respond to Airdrop with a message with eventType `EXTRACTION_DATA_DONE`.
+Once the data extraction is done, the snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_DATA_DONE`.
 
-If data extraction failed in any moment of extraction, the snap-in must respond to Airdrop with a message with eventType `EXTRACTION_DATA_ERROR`.
+If data extraction failed in any moment of extraction, the snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_DATA_ERROR`.
 
 ## Snap-in response
 

fern/docs/pages/adaas/extracting-external-sync-units.mdx

@@ -17,12 +17,12 @@ For GitHub, this would be the repository, for example `cli` in `github.com/devre
 
 External sync unit extraction is executed only during the initial import.
 It extracts external sync units available in the external system,
-so that the end user can choose which external sync unit should be airdropped.
+so that the end user can choose which external sync unit should be airdropped during the creation of an **Import** on DevRev App.
 
-Airdrop initiates the external sync unit extraction phase by starting the worker with a message with eventType:
+Airdrop initiates the external sync unit extraction phase by starting the worker with a message with with event of type `EVENT_TYPE`:
 `EXTRACTION_EXTERNAL_SYNC_UNITS_START` to start the external sync unit extraction.
 
-The snap-in must respond to Airdrop with a message with `eventType` `EXTRACTION_EXTERNAL_SYNC_UNITS_DONE`
+The snap-in must respond to Airdrop with a message with `with event of type `EVENT_TYPE`` `EXTRACTION_EXTERNAL_SYNC_UNITS_DONE`
 with a list of external sync units as a payload, or `EXTRACTION_EXTERNAL_SYNC_UNITS_ERROR` in case of an error.
 
 ## Snap-in response

fern/docs/pages/adaas/extracting-metadata.mdx

@@ -1,20 +1,18 @@
 
 During the extract metadata phase, the ADaaS snap-in must provide an `external_domain_metadata.json` file on each sync run. This file provides a structured way of describing external system's domain system, describe its domain entities, types, and what are their relationships, and other metadata.
 
-The `external_domain_metadata.json` is submitted in each sync run and is one of the input for the transformation phase.
-
 The extraction function of the snap-in must provide a valid metadata file. DevRev provides a JSON schema and a CLI tool `chef-cli` to validate the proposed schema.
 
 
 ## Triggering event
 
-Airdrop initiates the Metadata Extraction by starting the snap-in with a message with eventType: `EXTRACTION_METADATA_START`.
+Airdrop initiates the Metadata Extraction by starting the snap-in with a message with with event of type `EVENT_TYPE`: `EXTRACTION_METADATA_START`.
 
 During the Metadata Extraction phase,
 the snap-in extracts relevant metadata from an External System
 to prepare and upload the Initial Domain Mapping to DevRev.
 
-The snap-in must respond to Airdrop with a message with eventType `EXTRACTION_METADATA_DONE` when done,
+The snap-in must respond to Airdrop with a message with with event of type `EVENT_TYPE` `EXTRACTION_METADATA_DONE` when done,
 or `EXTRACTION_METADATA_ERROR` in case of an error.
 
 ## Snap-in response

fern/docs/pages/adaas/getting-started.mdx

@@ -10,7 +10,7 @@ then `Create a new repository`.
    - [nodejs](https://nodejs.org/en/download/package-manager) (version 18.x.x+ or higher)
 4. Copy `Makefile.variable.example` to `Makefile.variable` and fill in the required variables.
 5. Configure a keyring for the external system in the `manifest.yaml`.
-See [Creating a Keyring](https://www.notion.so/Creating-a-Keyring-aa497671dc1b423fae70f7a0c14fba3a?pvs=21).
+See [Keyrings](../references/keyrings/introduction.mdx).
 6. Deploy a draft version of your Snap-In to you DevOrg using `make deploy`.
 7. Install the snap-in in your DevRev DevOrg on the web by navigating to **Settings** -> **Snap-ins** -> **Install snap-in**.
 8. Define the `Connection`.
@@ -24,7 +24,8 @@ They are called **Connections** in the DevRev app.
 
 Keyrings provide a secure way to store and manage credentials within your DevRev Snap-In.
 This eliminates the need to expose sensitive information like passwords
-or access tokens directly within your code or configuration files, enhancing overall security.
+or access tokens directly within your code or configuration files, enhancing overall security. They also provide a valid
+token by abstracting Oauth token renewal from the end user.
 
 A keyring is used by a worker to authenticate to the external system in API calls. They includes the key (for example,
 a PAT token or API key), its type, the organization ID for which a key is valid, and in some cases the organization name.
@@ -34,8 +35,6 @@ Read more about keyrings in the [developer documentation](/snapin-development/re
 
 ## Observability
 
-snap-ins are snap-ins, and they inherit observability methodology from snap-ins.
-
 To observe logs from your snap-in in your development environment use `devrev snap_in_package logs | jq`.
 To open logs in your favorite editor use `devrev snap_in_package logs | code -`