```mdx
Impact Assessment
Severity: Moderate
This release adds 100 additive (feature) changes across 42 endpoints in the GitHub REST API, introducing new optional response fields related to repository pull request policies, secret scanning delegated bypass configurations, issue pinning, and Dependabot alert assignees. Because all changes are additive and optional, existing integrations are unlikely to break — but applications that deserialize API responses into strict schemas may encounter unexpected fields.
---
Editor's Note: We consider this a meaningful feature expansion rather than routine maintenance. The simultaneous rollout of pull_request_creation_policy across dozens of repository-bearing endpoints, alongside the security_configuration_id additions to secret scanning bypass reviewers, suggests GitHub is laying groundwork for more granular repository governance controls at both the org and enterprise level. If your integration parses code security configuration responses, we'd recommend auditing your deserialization logic now — the nested reviewers/items path is deep enough that strict schema validators will flag it.
---
Detailed Breakdown
`pull_request_creation_policy` on Repository Objects
What changed: The optional field pull_request_creation_policy has been added to repository objects across a wide range of endpoints. Affected resources include:
GET /app/installations/{installation_id}/access_tokens → repositories/items/pull_request_creation_policyGET /installation/repositories → repositories/items/allOf[subschema #1: Repository]/pull_request_creation_policyGET /issues → /items/repository/pull_request_creation_policyGET /notifications → /items/repository/pull_request_creation_policyGET /events and GET /networks/{owner}/{repo}/events → present on IssuesEvent, IssueCommentEvent, and ForkEvent subschemasWhy this matters: Any service that maps GitHub API responses to typed models — whether via OpenAPI-generated clients, hand-rolled DTOs, or JSON schema validation — may encounter this new field in repository payloads. Strict deserializers configured to reject unknown properties will begin failing on responses from these endpoints. Beyond compatibility, this field signals that GitHub is exposing repository-level PR creation controls through the API, which could be relevant for compliance tooling or internal developer platform dashboards that track repository governance settings.
Migration steps:
1. Update any OpenAPI-generated client code by regenerating from the latest spec at the 41e03c69c44a commit.
2. If you use strict JSON schema validation, add pull_request_creation_policy as an optional string property to your repository schema definitions.
3. Review any code that pattern-matches or switches on repository object fields — this new field may need a handler or an explicit ignore rule.
4. For ForkEvent payloads specifically, note the field appears on the forkee sub-object, not the top-level event.
---
`security_configuration_id` in Secret Scanning Delegated Bypass Reviewer Objects
What changed: The optional field security_configuration_id has been added to reviewer items within secret_scanning_delegated_bypass_options across enterprise and org-level code security configuration endpoints:
GET /enterprises/{enterprise}/code-security/configurations (200 and 201 responses)GET /enterprises/{enterprise}/code-security/configurations/defaults → nested under configuration/GET /enterprises/{enterprise}/code-security/configurations/{configuration_id} (200 response)GET /enterprises/{enterprise}/code-security/configurations/{configuration_id}/defaults → nested under configuration/GET /orgs/{org}/code-security/configurations and related org-scoped equivalentsWhy this matters: The secret_scanning_delegated_bypass_options object controls which reviewers can approve bypasses of secret scanning push protection. Adding security_configuration_id to each reviewer item means a reviewer can now be associated with a specific security configuration rather than being defined globally. For enterprises managing multiple security configurations across different business units, this enables more precise reviewer scoping. Tooling that reads these configurations to build audit reports or sync reviewer lists needs to account for this additional identifier.
Migration steps:
1. Update schema definitions for secret_scanning_delegated_bypass_options/reviewers/items to include security_configuration_id as an optional field.
2. If your tooling aggregates reviewer lists across configurations, update your data model to store the security_configuration_id alongside each reviewer entry.
3. Verify that any UI or reporting layer that renders bypass reviewer information can handle the presence or absence of this field gracefully.
---
`pinned_comment` on Issue Objects
What changed: The optional field pinned_comment has been added to issue objects in the following endpoints:
GET /issues → /items/pinned_commentGET /events → present on IssuesEvent and IssueCommentEvent subschemasGET /networks/{owner}/{repo}/events → same subschemas as aboveWhy this matters: Issue objects returned from these endpoints may now include a pinned_comment property. Applications that render issue data — such as internal triage dashboards or notification processors — should be prepared to display or ignore this field. Strict schema validators will flag it as an unknown property if not accounted for. The field's presence on event payloads means webhook-adjacent polling integrations are also affected.
Migration steps:
1. Add pinned_comment as an optional nullable property to your issue schema definitions.
2. Check event processing pipelines that parse IssuesEvent or IssueCommentEvent payloads for any strict field enumeration.
3. Decide whether your application should surface pinned comment data to end users and implement accordingly.
---
`assignees` on Enterprise Dependabot Alert Objects
What changed: The optional field assignees has been added to Dependabot alert items returned by GET /enterprises/{enterprise}/dependabot/alerts (200 response), at the path /items/assignees.
Why this matters: The assignees field is already present on org-level Dependabot alert responses, so this change brings the enterprise endpoint to parity. Security tooling that aggregates Dependabot alerts across an enterprise and routes them to responsible teams can now read assignee data directly from the enterprise-scoped endpoint rather than making additional org-level calls. If your alert ingestion pipeline builds a data model from this endpoint, the schema needs updating.
Migration steps:
1. Update your enterprise Dependabot alert schema to include assignees as an optional array field.
2. If you previously fetched assignee data by falling back to org-level endpoints, evaluate whether the enterprise endpoint now satisfies your requirements directly.
3. Confirm that downstream alert routing or ticketing logic handles the case where assignees is present but empty.
---
Org-Level Endpoint Additions (Broad Surface Area)
What changed: A large number of org-scoped endpoints received one or more of the above fields on their response schemas. The affected resources include, among others:
/orgs/{org}/actions/permissions/repositories/orgs/{org}/actions/runner-groups/{runner_group_id}/repositories/orgs/{org}/codespaces and member codespace endpoints/orgs/{org}/dependabot/alerts/orgs/{org}/migrations and /orgs/{org}/migrations/{migration_id}/repositories/orgs/{org}/packages and /orgs/{org}/packages/{package_type}/{package_name}/orgs/{org}/projectsV2/{project_number}/items and /drafts/orgs/{org}/properties/schemaWhy this matters: The breadth of affected org endpoints means that any integration consuming org-level data — runner management, package registries, project boards, migrations — may encounter new fields in responses. The risk is low for loosely typed clients, but higher for generated or strictly typed ones.
Migration steps:
1. Regenerate any OpenAPI clients targeting org-scoped endpoints from the updated spec.
2. Run your test suite against recorded API fixtures and update snapshots where new fields appear.
3. For migration-related endpoints, verify that your migration status parsers handle additional repository-level fields without error.
---
Before You Upgrade
1. Audit your deserialization configuration — search your codebase for patterns like additionalProperties: false, @JsonIgnoreProperties(ignoreUnknown = false), or equivalent strict-mode settings in your JSON library of choice. These are the most likely sources of breakage.
2. Regenerate OpenAPI clients — if you use a generated client from the GitHub REST API spec, pull the latest spec at commit 41e03c69c44a and regenerate. Run openapi-generator generate or your equivalent toolchain against the updated YAML/JSON.
3. Check fixture-based tests — run the following to find test files that may contain hardcoded repository or issue response shapes:
```bash
grep -r "pull_request_creation_policy\|pinned_comment\|security_configuration_id" ./tests
```
Absence of results here means your fixtures predate these fields and may need updating.
4. Validate enterprise Dependabot alert ingestion — if you consume /enterprises/{enterprise}/dependabot/alerts, confirm your alert model includes an assignees array field:
```bash
grep -r "dependabot" ./src --include="*.ts" -l
```
5. Review secret scanning bypass reviewer logic — for any code that reads secret_scanning_delegated_bypass_options, trace the path to reviewers/items and confirm your model can accommodate the optional security_configuration_id field without throwing.
6. Test event payload parsers — IssuesEvent and IssueCommentEvent subschemas now carry pinned_comment and pull_request_creation_policy. If you process events from /events or /networks/{owner}/{repo}/events, run a payload through your parser with these fields present:
```json
{ "pinned_comment": null, "pull_request_creation_policy": "allowed" }
```
7. Check ForkEvent handling specifically — the pull_request_creation_policy field on ForkEvent is nested under forkee, not the top-level payload. Confirm your fork event handler accesses payload.forkee before reading repository-level fields.
8. Review org-level runner and package endpoint consumers — for any tooling that lists repositories under runner groups (/orgs/{org}/actions/runner-groups/{runner_group_id}/repositories) or reads package metadata, verify that repository sub-objects in those responses are parsed with a schema that tolerates the new pull_request_creation_policy field.
9. Check project board integrations — /orgs/{org}/projectsV2/{project_number}/items and /drafts are listed as affected. If you build on Projects V2 data, confirm your item and draft models are not strictly enumerated.
10. Confirm no downstream schema registries are affected — if your organization uses a schema registry (e.g., Confluent, AWS Glue) to store GitHub API response shapes for event streaming, plan a schema evolution update before deploying any consumers that will receive the new fields.
---
Sources & Timeline
| Source | URL |
|---|---|
| Commit 41e03c69c44a | https://github.com/github/rest-api-description/commit/41e03c69c44a4b3875fb6ce13a51e0a67a3b3c34 |
| GitHub REST API Spec Diff (635a68e → 41e03c6) | https://github.com/github/rest-api-description/compare/635a68eca82f9dbda054d26b37711d46f2de7564...41e03c69c44a4b3875fb6ce13a51e0a67a3b3c34 |
Last verified: 2026-02-22T06:52:22Z
```