docs: fix 4 typos in documentation

archive/collaborate/session-definitions.md

@@ -8,7 +8,7 @@ toc: false
 
 # Session Definitions
 
-In Blackbard Collaborate, Sessions are what lies at the center of everything. This is the virtual room that you enroll users to, share content, and host your live course events. The purpose of this document is to define the settings available to you, the developer, when you create a new session through the Collaborate REST API.
+In Blackboard Collaborate, Sessions are what lies at the center of everything. This is the virtual room that you enroll users to, share content, and host your live course events. The purpose of this document is to define the settings available to you, the developer, when you create a new session through the Collaborate REST API.
 
 For illustration, here is a sample session event that would be sent to POST /sessions.
 
@@ -63,7 +63,7 @@ The following table defines the available settings in the sample JSON package ab
 |     createdTimezone      |                                          The time zone to create the room in                                          |           “America/New_York”           |
 |    courseRoomEnabled     |   A Boolean specific to Learn that describes whether this room is automatically associated with a course   |                 FALSE                  |
 |       boundaryTime       |          Number of minutes a user can join a session before the start time\. Must be 0, 15, 30, 45, or 60\.           |                   15                   |
-|  ParticipantCanUseTools  |  A Boolean that describes whether a use can use tools, such as application sharing, screen sharing, timer, and polls  |                  TRUE                  |
+|  ParticipantCanUseTools  |  A Boolean that describes whether a user can use tools, such as application sharing, screen sharing, timer, and polls  |                  TRUE                  |
 |      occurrenceType      |                                 Single\-Use or Perpetual session\. Must be “S” or “P”                                 |                  “S”                   |
 |      recurrenceRule      |                                A JSON object describing recurrence rules for a session                                |                                        |
 |    recurrenceEndType     |       The method to describe the end of the sessions recurrence\. Must be “on_date” or “after_occurence_count”        |               “on_date”                |

rest-apis/learn/getting-started/framework.md

@@ -20,7 +20,7 @@ and the Developer Portal continue to mature.
 
 There are three actors in the REST API use case:
 
-1. **Developer:**: This is the person who writes an application that uses the new REST APIs. Through the application the developer manages authorization using the registered application’s OAuth Key and Secret, any data sent to or received from Learn, and tracks application entitlements required for operation. _Developers are limited to non-production testing pursuant to the applicable REST Developer Agreements._
+1. **Developer:** This is the person who writes an application that uses the new REST APIs. Through the application the developer manages authorization using the registered application’s OAuth Key and Secret, any data sent to or received from Learn, and tracks application entitlements required for operation. _Developers are limited to non-production testing pursuant to the applicable REST Developer Agreements._
 
 2. **Learn Administrator**: By default, no Applications can access the REST APIs. A Learn Administrator must enable each app from the Learn Admin Panel before access is granted. This is done by creating an integration using the Learn Admin REST API Integrations tool using the developer provided application Id\* and a User with the required entitlements as specified by the developer.
 
@@ -31,7 +31,7 @@ There are three actors in the REST API use case:
 The REST API Framework Actors, interactions, and data paths
 ![RESTDiagram.png](/assets/img/framework-1.png)
 
-- **NOTE**: We do NOT support a model where the developer of the REST Application requires the Learn Administrator to get the Application ID, key, and secret for installing the developer’s application on the Learn system. The developer will get one APP ID, key and secret for the one application. The developer is responsible for configuring the key and secret on their server. For security reasons, the key and secret should never be shared with the client or any other another party. The REST Application can determine which institution requests are coming from by examining the FQDN in the requests. There is no need for installing a separate Application ID for a given vendors application on each Learn instance.
+- **NOTE**: We do NOT support a model where the developer of the REST Application requires the Learn Administrator to get the Application ID, key, and secret for installing the developer’s application on the Learn system. The developer will get one APP ID, key and secret for the one application. The developer is responsible for configuring the key and secret on their server. For security reasons, the key and secret should never be shared with the client or any other party. The REST Application can determine which institution requests are coming from by examining the FQDN in the requests. There is no need for installing a separate Application ID for a given vendors application on each Learn instance.
 
 #### How These Three Actors Work Together to Enable Learn REST Integrations