update titles for REST API classroom, billing, branches, checks, code of conduct docs (#49057)

content/actions/using-workflows/events-that-trigger-workflows.md

@@ -41,7 +41,7 @@ Some events have multiple activity types. For these events, you can specify whic
 
 {% data reusables.actions.branch-requirement %}
 
-Runs your workflow when branch protection rules in the workflow repository are changed. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)." For information about the branch protection rule APIs, see "[AUTOTITLE](/graphql/reference/objects#branchprotectionrule)" in the GraphQL API documentation or "[AUTOTITLE](/rest/branches)" in the REST API documentation.
+Runs your workflow when branch protection rules in the workflow repository are changed. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)." For information about the branch protection rule APIs, see "[AUTOTITLE](/graphql/reference/objects#branchprotectionrule)" in the GraphQL API documentation or "[AUTOTITLE](/rest/branches)."
 
 For example, you can run a workflow when a branch protection rule has been `created` or `deleted`:
 
@@ -65,7 +65,7 @@ on:
 
 {% data reusables.actions.branch-requirement %}
 
-Runs your workflow when activity related to a check run occurs. A check run is an individual test that is part of a check suite. For information, see "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)." For information about the check run APIs, see "[AUTOTITLE](/graphql/reference/objects#checkrun)" in the GraphQL API documentation or "[AUTOTITLE](/rest/checks#runs)" in the REST API documentation.
+Runs your workflow when activity related to a check run occurs. A check run is an individual test that is part of a check suite. For information, see "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)." For information about the check run APIs, see "[AUTOTITLE](/graphql/reference/objects#checkrun)" in the GraphQL API documentation or "[AUTOTITLE](/rest/checks#runs)."
 
 For example, you can run a workflow when a check run has been `rerequested` or `completed`.
 
@@ -95,7 +95,7 @@ on:
 
 {% endnote %}
 
-Runs your workflow when check suite activity occurs. A check suite is a collection of the check runs created for a specific commit. Check suites summarize the status and conclusion of the check runs that are in the suite. For information, see "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)." For information about the check suite APIs, see "[AUTOTITLE](/graphql/reference/objects#checksuite)" in the GraphQL API documentation or "[AUTOTITLE](/rest/checks#suites)" in the REST API documentation.
+Runs your workflow when check suite activity occurs. A check suite is a collection of the check runs created for a specific commit. Check suites summarize the status and conclusion of the check runs that are in the suite. For information, see "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)." For information about the check suite APIs, see "[AUTOTITLE](/graphql/reference/objects#checksuite)" in the GraphQL API documentation or "[AUTOTITLE](/rest/checks#suites)."
 
 For example, you can run a workflow when a check suite has been `completed`.
 

content/admin/policies/enforcing-policy-with-pre-receive-hooks/creating-a-pre-receive-hook-script.md

@@ -86,7 +86,7 @@ The `$GITHUB_VIA` variable is available in the pre-receive hook environment when
 | :- | :- | :- |
 | <pre>auto-merge deployment api</pre> | Automatic merge of the base branch via a deployment created with the API | "[AUTOTITLE](/rest/deployments#create-a-deployment)" in the REST API documentation |
 | <pre>blob#save</pre> | Change to a file's contents in the web interface | "[AUTOTITLE](/repositories/working-with-files/managing-files/editing-files)" |
-| <pre>branch merge api</pre> | Merge of a branch via the API | "[AUTOTITLE](/rest/branches#merge-a-branch)" in the REST API documentation |
+| <pre>branch merge api</pre> | Merge of a branch via the API | "[AUTOTITLE](/rest/branches#merge-a-branch)" |
 | <pre>branches page delete button</pre> | Deletion of a branch in the web interface | "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository#deleting-a-branch)" |
 | <pre>git refs create api</pre> | Creation of a ref via the API | "[AUTOTITLE](/rest/git#create-a-reference)" in the REST API documentation |
 | <pre>git refs delete api</pre> | Deletion of a ref via the API | "[AUTOTITLE](/rest/git#delete-a-reference)" in the REST API documentation |

content/apps/creating-github-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app.md

@@ -49,7 +49,7 @@ Checks include check runs, check suites, and commit statuses.
 
 1. When someone pushes code to the repository, {% data variables.product.prodname_dotcom %} automatically sends the `check_suite` event with an action of `requested` to all {% data variables.product.prodname_github_apps %} installed on the repository that have the `checks:write` permission. This event lets the apps know that code was pushed to the repository, and that {% data variables.product.prodname_dotcom %} has automatically created a new check suite.
 1. When your app receives this event, it can add check runs to that suite.
-1. Your check runs can include annotations that are displayed on specific lines of code. Annotations are visible in the **Checks** tab. When you create an annotation for a file that is part of the pull request, the annotations are also shown in the **Files changed** tab. For more information, see the `annotations` object in the "[AUTOTITLE](/rest/checks/runs#create-a-check-run)" documentation.
+1. Your check runs can include annotations that are displayed on specific lines of code. Annotations are visible in the **Checks** tab. When you create an annotation for a file that is part of the pull request, the annotations are also shown in the **Files changed** tab. For more information, see the `annotations` object in "[AUTOTITLE](/rest/checks/runs#create-a-check-run)."
 
 For more information about checks, see "[AUTOTITLE](/rest/checks)" and "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)."
 
@@ -662,7 +662,7 @@ In the code block that starts with `helpers do`, where it says `# ADD CREATE_CHE
     end
 ```
 
-This code calls the "[AUTOTITLE](/rest/checks#create-a-check-run)" endpoint using the Octokit [create_check_run method](https://msp-greg.github.io/octokit/Octokit/Client/Checks.html#create_check_run-instance_method).
+This code calls the `POST /repos/{owner}/{repo}/check-runs` endpoint using the Octokit [create_check_run method](https://msp-greg.github.io/octokit/Octokit/Client/Checks.html#create_check_run-instance_method). For more information about the endpoint, see "[AUTOTITLE](/rest/checks#create-a-check-run)."
 
 To create a check run, only two input parameters are required: `name` and `head_sha`. In this code, we name the check run "Octo RuboCop," because we'll use RuboCop to implement the CI test later in the tutorial. But you can choose any name you'd like for the check run. For more information about RuboCop, see the [RuboCop documentation](https://docs.rubocop.org/rubocop/index.html).
 
@@ -749,7 +749,7 @@ In the code block that starts with `helpers do`, where it says `# ADD INITIATE_C
     end
 ```
 
-The code above calls the "[Update a check run](/rest/checks#update-a-check-run)" endpoint using the [`update_check_run` Octokit method](https://msp-greg.github.io/octokit/Octokit/Client/Checks.html#update_check_run-instance_method), and updates the check run that you already created.
+The code above calls the `PATCH /repos/{owner}/{repo}/check-runs/{check_run_id}` endpoint using the [`update_check_run` Octokit method](https://msp-greg.github.io/octokit/Octokit/Client/Checks.html#update_check_run-instance_method), and updates the check run that you already created. For more information about the endpoint, see "[AUTOTITLE](/rest/checks#update-a-check-run)."
 
 Here's what this code is doing. First, it updates the check run's status to `in_progress` and implicitly sets the `started_at` time to the current time. In Part 2 of this tutorial, you'll add code that kicks off a real CI test under `***** RUN A CI TEST *****`. For now, you'll leave that section as a placeholder, so the code that follows it will just simulate that the CI process succeeds and all tests pass. Finally, the code updates the status of the check run again to `completed`.
 
@@ -998,7 +998,7 @@ The following steps will show you how to test that the code works and view the e
 
 The `@output` variable contains the parsed JSON results of the RuboCop report. As shown in the example output in the previous step, the results contain a `summary` section that your code can use to quickly determine if there are any errors. The following code will set the check run conclusion to `success` when there are no reported errors. RuboCop reports errors for each file in the `files` array, so if there are errors, you'll need to extract some data from the file object.
 
-The REST API endpoints to manage check runs allow you to create annotations for specific lines of code. When you create or update a check run, you can add annotations. In this tutorial you will update the check run with annotations, using the "[Update a check run](/rest/checks/runs#update-a-check-run)" endpoint.
+The REST API endpoints to manage check runs allow you to create annotations for specific lines of code. When you create or update a check run, you can add annotations. In this tutorial you will update the check run with annotations, using the `PATCH /repos/{owner}/{repo}/check-runs/{check_run_id}` endpoint. For more information about the endpoint, see "[AUTOTITLE](/rest/checks/runs#update-a-check-run)."
 
 The API limits the number of annotations to a maximum of 50 per request. To create more than 50 annotations, you will have to make multiple requests to the "Update a check run" endpoint. For example, to create 105 annotations you would need to make three separate requests to the API. The first two requests would each have 50 annotations, and the third request would include the five remaining annotations. Each time you update the check run, annotations are appended to the list of annotations that already exist for the check run.
 

content/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps.md

@@ -86,7 +86,7 @@ Name | Description
 **`workflow`** | Grants the ability to add and update {% data variables.product.prodname_actions %} workflow files. Workflow files can be committed without this scope if the same file (with both the same path and contents) exists on another branch in the same repository. Workflow files can expose `GITHUB_TOKEN` which may have a different set of scopes. For more information, see "[AUTOTITLE](/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)."{% ifversion not fpt %}
 **`admin:enterprise`** | Gives full control of enterprise functionality. For more information, see "[AUTOTITLE](/graphql/guides/managing-enterprise-accounts)" in the GraphQL API documentation.<br><br>Includes `manage_runners:enterprise`{% ifversion ghec or ghes %}, `manage_billing:enterprise`,{% endif %} and `read:enterprise`.
 &emsp;`manage_runners:enterprise` | Gives full control over self-hosted runners within the enterprise. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)." {% ifversion ghec or ghes %}
-&emsp;`manage_billing:enterprise` | Read and write enterprise billing data. For more information, see "[AUTOTITLE](/rest/billing)" in the REST API documentation. {% endif %}
+&emsp;`manage_billing:enterprise` | Read and write enterprise billing data. For more information, see "[AUTOTITLE](/rest/billing)." {% endif %}
 &emsp;`read:enterprise` | Read all data on an enterprise profile. Does not include profile data of enterprise members or organizations.{% endif %}{% ifversion read-audit-scope %}
 **`read:audit_log`** | Read audit log data.{% endif %}
 {% note %}

content/billing/managing-billing-for-github-advanced-security/viewing-your-github-advanced-security-usage.md

@@ -137,7 +137,7 @@ You can retrieve {% data variables.product.prodname_advanced_security %} usage i
 
 {% ifversion ghec %}
 
-For organization-level data, use the `/orgs/{org}/settings/billing/advanced-security` endpoint. For more information, see "[AUTOTITLE](/rest/billing#get-github-advanced-security-active-committers-for-an-organization)" in the {% data variables.product.prodname_dotcom %} REST API documentation.
+For organization-level data, use the `/orgs/{org}/settings/billing/advanced-security` endpoint. For more information, see "[AUTOTITLE](/rest/billing#get-github-advanced-security-active-committers-for-an-organization)."
 
 {% endif %}
 

content/rest/billing/billing.md

@@ -1,5 +1,7 @@
 ---
-title: Billing
+title: REST API endpoints for billing
+shortTitle: Billing
+allowTitleToDifferFromFilename: true
 intro: Use the REST API to get billing information for an enterprise.
 topics:
   - API

content/rest/billing/index.md

@@ -1,5 +1,7 @@
 ---
-title: Billing
+title: REST API endpoints for billing
+shortTitle: Billing
+allowTitleToDifferFromFilename: true
 intro: Use the REST API to get billing information for an enterprise.
 topics:
   - API

content/rest/branches/branch-protection.md

@@ -1,5 +1,6 @@
 ---
-title: Protected branches
+title: REST API endpoints for protected branches
+shortTitle: Protected branches
 intro: Use the REST API to manage protected branches.
 versions: # DO NOT MANUALLY EDIT. CHANGES WILL BE OVERWRITTEN BY A 🤖
   fpt: '*'

content/rest/branches/branches.md

@@ -1,5 +1,7 @@
 ---
-title: Branches
+title: REST API endpoints for branches
+shortTitle: Branches
+allowTitleToDifferFromFilename: true
 intro: Use the REST API to modify branches and their protection settings.
 versions: # DO NOT MANUALLY EDIT. CHANGES WILL BE OVERWRITTEN BY A 🤖
   fpt: '*'

content/rest/branches/index.md

@@ -1,5 +1,6 @@
 ---
-title: Branches
+title: REST API endpoints for branches and their settings
+shortTitle: Branches
 intro: Use the REST API to modify branches and their protection settings.
 allowTitleToDifferFromFilename: true
 versions:

content/rest/checks/index.md

@@ -1,5 +1,7 @@
 ---
-title: Checks
+title: REST API endpoints for checks
+shortTitle: Checks
+allowTitleToDifferFromFilename: true
 intro: 'Use the REST API to build {% data variables.product.prodname_github_apps %} that run powerful checks against the code changes in a repository.'
 redirect_from:
   - /v3/checks

content/rest/checks/runs.md

@@ -1,5 +1,6 @@
 ---
-title: Check Runs
+title: REST API endpoints for check runs
+shortTitle: Check runs
 intro: Use the REST API to manage check runs.
 versions: # DO NOT MANUALLY EDIT. CHANGES WILL BE OVERWRITTEN BY A 🤖
   fpt: '*'

content/rest/checks/suites.md

@@ -1,5 +1,6 @@
 ---
-title: Check Suites
+title: REST API endpoints for check suites
+shortTitle: Check suites
 intro: Use the REST API to manage check suites.
 versions: # DO NOT MANUALLY EDIT. CHANGES WILL BE OVERWRITTEN BY A 🤖
   fpt: '*'

content/rest/classroom/classroom.md

@@ -1,5 +1,5 @@
 ---
-title: Classroom
+title: REST API endpoints for {% data variables.product.prodname_classroom %}
 shortTitle: Classroom
 intro: 'Use the REST API to interact with {% data variables.product.prodname_classroom %}.'
 versions: # DO NOT MANUALLY EDIT. CHANGES WILL BE OVERWRITTEN BY A 🤖

content/rest/classroom/index.md

@@ -1,5 +1,6 @@
 ---
-title: Classroom
+title: REST API endpoints for {% data variables.product.prodname_classroom %}
+shortTitle: Classroom
 intro: 'Use the REST API to interact with {% data variables.product.prodname_classroom %}.'
 topics:
   - API

content/rest/codes-of-conduct/codes-of-conduct.md

@@ -1,5 +1,7 @@
 ---
-title: Codes of conduct
+title: REST API endpoints for codes of conduct
+shortTitle: Codes of conduct
+allowTitleToDifferFromFilename: true
 intro: Use the REST API to get information about codes of conduct.
 versions: # DO NOT MANUALLY EDIT. CHANGES WILL BE OVERWRITTEN BY A 🤖
   fpt: '*'

content/rest/codes-of-conduct/index.md

@@ -1,5 +1,7 @@
 ---
-title: Codes of conduct
+title: REST API endpoints for codes of conduct
+shortTitle: Codes of conduct
+allowTitleToDifferFromFilename: true
 intro: Use the REST API to get information about codes of conduct.
 versions:
   fpt: '*'

content/rest/guides/using-the-rest-api-to-interact-with-checks.md

@@ -69,7 +69,7 @@ If a check run is in an incomplete state for more than 14 days, then the check r
 
 As soon as you receive the [`check_suite`](/webhooks-and-events/webhooks/webhook-events-and-payloads#check_suite) webhook, you can create the check run, even if the check is not complete. You can update the `status` of the check run as it completes with the values `queued`, `in_progress`, or `completed`, and you can update the `output` as more details become available. A check run can contain timestamps, a link to more details on your external site, detailed annotations for specific lines of code, and information about the analysis performed.
 
-Annotations add information from your check run to specific lines of code. Each annotation includes an `annotation_level` property, which can be `notice`, `warning`, or `failure`. The annotation also includes `path`, `start_line`, and `end_line` to specify what location the annotation refers to. The annotation includes a `message` to describe the result. For more information, see "[AUTOTITLE](/rest/checks/runs)" in the REST API reference documentation.
+Annotations add information from your check run to specific lines of code. Each annotation includes an `annotation_level` property, which can be `notice`, `warning`, or `failure`. The annotation also includes `path`, `start_line`, and `end_line` to specify what location the annotation refers to. The annotation includes a `message` to describe the result. For more information, see "[AUTOTITLE](/rest/checks/runs)."
 
 A check can also be manually re-run in the GitHub UI. See "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks#checks)" for more details. When this occurs, the GitHub App that created the check run will receive the [`check_run`](/webhooks-and-events/webhooks/webhook-events-and-payloads#check_run) webhook requesting a new check run. If you create a check run without creating a check suite, GitHub creates the check suite for you automatically.