shapi-cli 0.0.0-stage → 0.2.0

package/advisories/salesforce-soap-login-broad-ip-range-token-required.json

@@ -0,0 +1,30 @@
+{
+  "id": "salesforce-soap-login-broad-ip-range-token-required",
+  "provider": "salesforce",
+  "title": "SOAP login() from a broad IP range needs a security token from 2026-12-15",
+  "summary": "Starting 2026-12-15 in sandboxes and 2027-01-31 in production, SOAP API login() for a user whose org or profile login IP range is broad (larger than /8 IPv4 or /29 IPv6) fails without a security token (or mTLS); username and password alone fail with TOKEN_REQUIRED (Login History result 1502). It applies to login() on /services/Soap/c/{v} and /services/Soap/u/{v} in API 31.0-64.0.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/services/Soap/*/*",
+    "hosts": [
+      "login.salesforce.com",
+      "test.salesforce.com"
+    ]
+  },
+  "changeClass": "auth",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2025-08-25",
+    "url": "https://help.salesforce.com/s/articleView?id=005132110&type=1"
+  },
+  "effectiveDate": "2026-12-15",
+  "severity": "critical",
+  "migrationNote": "Preferably switch the integration to an External Client App with OAuth 2.0 before 2026-12-15 (sandbox) / 2027-01-31 (production). As a stopgap, append the user's security token to the password in the login() call, or narrow the org Network Access or profile Login IP Ranges so they are no longer broad; test with the 'SOAP API login() Security Remediation' release update.",
+  "sources": [
+    "https://help.salesforce.com/s/articleView?id=005132110&type=1"
+  ],
+  "status": "verified"
+}

package/advisories/salesforce-soap-login-disabled-when-unused.json

@@ -0,0 +1,30 @@
+{
+  "id": "salesforce-soap-login-disabled-when-unused",
+  "provider": "salesforce",
+  "title": "SOAP login() turned off in orgs with no use in six months, from 2026-12-15",
+  "summary": "In a one-time check on 2026-12-15 (sandboxes) and 2027-01-31 (production), Salesforce disables SOAP API login() in orgs that had no SOAP login() call in the previous six months; after that, login() fails in that org. Rarely run jobs (annual, seasonal, disaster recovery) can look inactive and then break. One call by any user in the window keeps login() on.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/services/Soap/*/*",
+    "hosts": [
+      "login.salesforce.com",
+      "test.salesforce.com"
+    ]
+  },
+  "changeClass": "auth",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2025-08-25",
+    "url": "https://help.salesforce.com/s/articleView?id=005132110&type=1"
+  },
+  "effectiveDate": "2026-12-15",
+  "severity": "critical",
+  "migrationNote": "Check Login History (API Type SOAP Enterprise/Partner) and the API Total Usage event log (API_FAMILY SOAP, API_RESOURCE login) for every integration that uses SOAP login(), including rarely run jobs, and move them to an External Client App with OAuth 2.0 before 2026-12-15 (sandbox) / 2027-01-31 (production).",
+  "sources": [
+    "https://help.salesforce.com/s/articleView?id=005132110&type=1"
+  ],
+  "status": "verified"
+}

package/advisories/salesforce-soap-login-use-any-api-auth-required.json

@@ -0,0 +1,31 @@
+{
+  "id": "salesforce-soap-login-use-any-api-auth-required",
+  "provider": "salesforce",
+  "title": "SOAP login() requires the Use Any API Auth permission from 2026-12-01",
+  "summary": "Salesforce enforces a new control on SOAP API login() in all orgs on 2026-12-01: login() succeeds only for users with the Use Any API Auth user permission, and otherwise is rejected with INSUFFICIENT_ACCESS. It is already the default in new orgs. It applies to login() on the Enterprise (/services/Soap/c/{v}) and Partner (/services/Soap/u/{v}) endpoints in API 31.0-64.0; login() is already unavailable in 65.0 and later.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/services/Soap/*/*",
+    "hosts": [
+      "login.salesforce.com",
+      "test.salesforce.com"
+    ]
+  },
+  "changeClass": "auth",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2025-08-25",
+    "url": "https://help.salesforce.com/s/articleView?id=005132110&type=1"
+  },
+  "effectiveDate": "2026-12-01",
+  "severity": "critical",
+  "migrationNote": "Assign the Use Any API Auth permission (permission set or profile) to every integration user that still calls SOAP login(), and test with the 'Assign Use Any API Auth Permission for SOAP login()' release update. Plan the real fix at the same time: authenticate through an External Client App with OAuth 2.0 (JWT bearer or client credentials for server-to-server, web server flow for user-driven apps), because login() is retired in Summer '27.",
+  "sources": [
+    "https://help.salesforce.com/s/articleView?id=005132110&type=1",
+    "https://developer.salesforce.com/docs/platform/api/guide/api-eol-soap.html"
+  ],
+  "status": "verified"
+}

package/advisories/shopify-admin-api-2026-01-unsupported.json

@@ -0,0 +1,33 @@
+{
+  "id": "shopify-admin-api-2026-01-unsupported",
+  "provider": "shopify",
+  "title": "Shopify Admin API version 2026-01 becomes unsupported on 2027-01-16",
+  "summary": "Admin API version 2026-01 is accessible until January 16, 2027 15:00 UTC. After that, requests to /admin/api/2026-01/... (REST and GraphQL) and webhooks pinned to 2026-01 fall forward to the oldest accessible stable version without an error, so responses can change shape silently. Every app still pinned to 2026-01 is hit.",
+  "endpoint": {
+    "method": "*",
+    "path": "/admin/api/2026-01/**"
+  },
+  "changeClass": "version-sunset",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": null,
+    "url": "https://shopify.dev/docs/api/usage/versioning"
+  },
+  "effectiveDate": "2027-01-16",
+  "severity": "critical",
+  "migrationNote": "Move the version segment in your Admin API URLs and webhook subscriptions to a supported version (2026-04 or later; 2026-10 is the latest stable), work through the release notes for every version in between, and check the X-Shopify-API-Version response header to confirm Shopify is not falling forward.",
+  "recipeId": "apply-fix",
+  "fix": {
+    "path": {
+      "from": "/admin/api/2026-01/",
+      "to": "/admin/api/2026-10/"
+    }
+  },
+  "sources": [
+    "https://shopify.dev/docs/api/usage/versioning"
+  ],
+  "status": "verified"
+}

package/advisories/shopify-admin-api-2026-04-unsupported.json

@@ -0,0 +1,33 @@
+{
+  "id": "shopify-admin-api-2026-04-unsupported",
+  "provider": "shopify",
+  "title": "Shopify Admin API version 2026-04 becomes unsupported on 2027-04-16",
+  "summary": "Admin API version 2026-04 is accessible until April 16, 2027 15:00 UTC. After that, requests to /admin/api/2026-04/... (REST and GraphQL) and webhooks pinned to 2026-04 fall forward to the oldest accessible stable version without an error, so responses can change shape silently. Every app still pinned to 2026-04 is hit.",
+  "endpoint": {
+    "method": "*",
+    "path": "/admin/api/2026-04/**"
+  },
+  "changeClass": "version-sunset",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": null,
+    "url": "https://shopify.dev/docs/api/usage/versioning"
+  },
+  "effectiveDate": "2027-04-16",
+  "severity": "high",
+  "migrationNote": "Move the version segment in your Admin API URLs and webhook subscriptions to a supported version (2026-07 or later; 2026-10 is the latest stable), work through the release notes for every version in between, and check the X-Shopify-API-Version response header to confirm Shopify is not falling forward.",
+  "recipeId": "apply-fix",
+  "fix": {
+    "path": {
+      "from": "/admin/api/2026-04/",
+      "to": "/admin/api/2026-10/"
+    }
+  },
+  "sources": [
+    "https://shopify.dev/docs/api/usage/versioning"
+  ],
+  "status": "verified"
+}

package/advisories/shopify-global-catalog-rest-api-shutdown.json

@@ -0,0 +1,24 @@
+{
+  "id": "shopify-global-catalog-rest-api-shutdown",
+  "provider": "shopify",
+  "title": "Shopify Global Catalog REST API stops serving traffic on 2026-11-02",
+  "summary": "The Global Catalog REST API on discover.shopifyapps.com (/global/v2/search, /global/v2/p/{upid}, /global/v2/p/by-variant/{vid}, POST /global/v2/lookup, including saved-catalog requests) stops serving traffic on November 2, 2026, and requests to it will fail. Anything still calling it must move to the Global Catalog MCP server.",
+  "endpoint": {
+    "method": "*",
+    "path": "/global/v2/**"
+  },
+  "changeClass": "version-sunset",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-10-09",
+    "url": "https://shopify.dev/changelog/posts/global-catalog-rest-api-stops-serving-traffic-on-november-2-2026"
+  },
+  "effectiveDate": "2026-11-02",
+  "severity": "critical",
+  "migrationNote": "Switch to the Global Catalog MCP server at https://catalog.shopify.com/api/ucp/mcp: use the search_catalog tool instead of GET /global/v2/search, get_product instead of the single-product and by-variant lookups, and lookup_catalog (up to 50 items per request) instead of POST /global/v2/lookup.",
+  "sources": ["https://shopify.dev/changelog/posts/global-catalog-rest-api-stops-serving-traffic-on-november-2-2026"],
+  "status": "verified"
+}

package/advisories/shopify-non-expiring-offline-tokens-rejected.json

@@ -0,0 +1,27 @@
+{
+  "id": "shopify-non-expiring-offline-tokens-rejected",
+  "provider": "shopify",
+  "title": "Shopify rejects non-expiring offline access tokens from public apps on 2027-01-01",
+  "summary": "Starting January 1, 2027, every public app (including ones created before April 1, 2026) must use expiring offline access tokens to call the Admin API. Shopify enforces this on GraphQL Admin API requests: a request with a non-expiring token gets 403 Forbidden with \"Non-expiring access tokens are no longer accepted for the Admin API\", and merchants lose access until they re-authenticate. Custom apps and merchant-created apps are not affected.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/admin/api/{version}/graphql.json"
+  },
+  "changeClass": "auth",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-05-20",
+    "url": "https://shopify.dev/changelog/posts/expiring-offline-access-tokens-required-for-all-public-apps-as-of-january-1-2027"
+  },
+  "effectiveDate": "2027-01-01",
+  "severity": "critical",
+  "migrationNote": "Exchange each stored non-expiring token for an expiring one with POST /admin/oauth/access_token (grant_type=urn:ietf:params:oauth:grant-type:token-exchange, subject_token_type and requested_token_type urn:shopify:params:oauth:token-type:offline-access-token, expiring=1), store the access token, refresh token and expiry, and refresh before expiry; on the official app templates set future.expiringOfflineAccessTokens: true and redeploy. Check API Health in the Dev Dashboard to confirm the app is migrated.",
+  "sources": [
+    "https://shopify.dev/changelog/posts/expiring-offline-access-tokens-required-for-all-public-apps-as-of-january-1-2027",
+    "https://shopify.dev/docs/apps/build/authentication-authorization/migrate-to-expiring-offline-access-tokens"
+  ],
+  "status": "verified"
+}

package/advisories/shopify-script-tags-stop-running.json

@@ -0,0 +1,27 @@
+{
+  "id": "shopify-script-tags-stop-running",
+  "provider": "shopify",
+  "title": "Shopify script tags stop running on storefronts on 2027-03-01",
+  "summary": "Script tags are deprecated in every Admin API version. Since October 1, 2026 the REST ScriptTag resource rejects POST and PUT and the GraphQL scriptTagCreate and scriptTagUpdate mutations return a user error; on March 1, 2027 Shopify stops injecting existing script tags into storefronts, so their JavaScript no longer loads. Listing and deleting script tags keeps working.",
+  "endpoint": {
+    "method": "*",
+    "path": "/admin/api/{version}/script_tags**"
+  },
+  "changeClass": "version-sunset",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-08-24",
+    "url": "https://shopify.dev/changelog/online-store-script-tags-deprecation"
+  },
+  "effectiveDate": "2027-03-01",
+  "severity": "high",
+  "migrationNote": "Stop creating or updating script tags (POST /admin/api/{version}/script_tags.json and PUT .../script_tags/{script_tag_id}.json already fail). Move storefront scripts to app embed blocks in a theme app extension, and analytics or conversion scripts to a web pixel; then delete the old script tags. Pinning an older API version does not delay this.",
+  "sources": [
+    "https://shopify.dev/changelog/online-store-script-tags-deprecation",
+    "https://shopify.dev/docs/api/admin-rest/latest/resources/scripttag"
+  ],
+  "status": "verified"
+}

package/advisories/slack-files-upload-retired.json

@@ -0,0 +1,28 @@
+{
+  "id": "slack-files-upload-retired",
+  "provider": "slack",
+  "title": "files.upload Web API method sunset on 2025-11-12",
+  "summary": "Slack deprecated files.upload. Apps created on or after 2024-05-16 could not use it, and Slack's reference page says the method stops working and is sunset on 2025-11-12 for existing apps too (the date was moved from 2025-03-11). Code that still uploads through files.upload fails with method_deprecated or deprecated_endpoint errors.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/api/files.upload"
+  },
+  "changeClass": "version-sunset",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2025-03-17",
+    "url": "https://docs.slack.dev/changelog/2025/03/17/files-upload-extension"
+  },
+  "effectiveDate": "2025-11-12",
+  "severity": "critical",
+  "migrationNote": "Replace files.upload with the two-step flow: call files.getUploadURLExternal (filename, length) to get an upload_url and file_id, POST the file bytes to upload_url, then call files.completeUploadExternal with the file_id(s) and the channel_id, initial_comment or thread_ts you used to pass to files.upload. The official Slack SDKs wrap this as files_upload_v2 / filesUploadV2 / uploadV2.",
+  "sources": [
+    "https://docs.slack.dev/reference/methods/files.upload",
+    "https://docs.slack.dev/changelog/2025/03/17/files-upload-extension",
+    "https://docs.slack.dev/changelog/2024-04-a-better-way-to-upload-files-is-here-to-stay"
+  ],
+  "status": "verified"
+}

package/advisories/stripe-checkout-session-ui-mode-values-renamed.json

@@ -0,0 +1,53 @@
+{
+  "id": "stripe-checkout-session-ui-mode-values-renamed",
+  "provider": "stripe",
+  "title": "Stripe 2026-03-25.dahlia renames Checkout Session ui_mode values",
+  "summary": "From API version 2026-03-25.dahlia, Checkout Session ui_mode values hosted, embedded and custom are replaced by hosted_page, embedded_page and elements (and form is added). Creating a session with an old value fails, and code that compares the returned ui_mode to the old strings stops matching once the account or SDK is upgraded.",
+  "endpoint": {
+    "method": "*",
+    "path": "/v1/checkout/sessions/**"
+  },
+  "changeClass": "enum-added",
+  "trigger": {
+    "enums": [
+      {
+        "field": "ui_mode"
+      }
+    ]
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-03-25",
+    "url": "https://docs.stripe.com/changelog/dahlia/2026-03-25/updates-available-checkout-session-ui-modes"
+  },
+  "effectiveDate": "2026-03-25",
+  "severity": "high",
+  "migrationNote": "When moving to 2026-03-25.dahlia or later, send ui_mode hosted_page instead of hosted, embedded_page instead of embedded and elements instead of custom, and update every comparison of session.ui_mode (including checkout.session webhook handlers) to the new values; handle the new form value too.",
+  "recipeId": "apply-fix",
+  "fix": {
+    "enums": [
+      {
+        "field": "ui_mode",
+        "values": [
+          {
+            "from": "hosted",
+            "to": "hosted_page"
+          },
+          {
+            "from": "embedded",
+            "to": "embedded_page"
+          },
+          {
+            "from": "custom",
+            "to": "elements"
+          }
+        ]
+      }
+    ]
+  },
+  "sources": [
+    "https://docs.stripe.com/changelog/dahlia/2026-03-25/updates-available-checkout-session-ui-modes",
+    "https://docs.stripe.com/api/checkout/sessions/create"
+  ],
+  "status": "verified"
+}

package/advisories/twilio-conference-list-default-in-progress.json

@@ -0,0 +1,27 @@
+{
+  "id": "twilio-conference-list-default-in-progress",
+  "provider": "twilio",
+  "title": "Twilio Conference list returns only in-progress conferences by default from 2026-09-30",
+  "summary": "Starting September 30, 2026 (rollout delayed from July 13, 2026), GET /2010-04-01/Accounts/{AccountSid}/Conferences.json without a Status filter returns only in-progress conferences instead of in-progress and completed ones. Code that lists conferences without Status and expects completed ones gets silently incomplete results.",
+  "endpoint": {
+    "method": "GET",
+    "path": "/2010-04-01/Accounts/{AccountSid}/Conferences.json"
+  },
+  "changeClass": "required-field",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-09-23",
+    "url": "https://www.twilio.com/en-us/changelog/conference-list-endpoint-july-2026"
+  },
+  "effectiveDate": "2026-09-30",
+  "severity": "critical",
+  "migrationNote": "Pass Status=completed explicitly when you need completed conferences (reporting, billing or cleanup jobs), and make a second request without it for in-progress ones if you need both; do not rely on the unfiltered list containing completed conferences.",
+  "sources": [
+    "https://www.twilio.com/en-us/changelog/conference-list-endpoint-july-2026",
+    "https://www.twilio.com/en-us/changelog/conference-list-endpoint-rollout-extended"
+  ],
+  "status": "verified"
+}

package/advisories/twilio-notify-end-of-life.json

@@ -0,0 +1,28 @@
+{
+  "id": "twilio-notify-end-of-life",
+  "provider": "twilio",
+  "title": "Twilio Notify reaches end of life (reported for 2027-01-31)",
+  "summary": "Twilio Notify (notify.twilio.com, e.g. POST /v1/Services/{ServiceSid}/Notifications) has been unsupported and closed to new customers since October 2022, and is reported to reach end of life for existing customers on January 31, 2027, after which Notify API requests are expected to fail. That date comes from Twilio's help-center article as quoted by a third party; Twilio's own January 2024 changelog gave December 31, 2025, so the exact date is not confirmed on a primary page.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/v1/Services/{ServiceSid}/Notifications"
+  },
+  "changeClass": "version-sunset",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2024-01-23",
+    "url": "https://www.twilio.com/en-us/changelog/notify-api-end-of-life-further-extension-notice"
+  },
+  "effectiveDate": "2027-01-31",
+  "severity": "critical",
+  "migrationNote": "Move bulk SMS sends to the Messaging API (or Twilio's Bulk Messaging API) and push notifications to a direct APNs/FCM integration or another push provider, then remove Notify Services and Bindings. Confirm the final shutdown date with Twilio support or the Console before planning around it.",
+  "sources": [
+    "https://www.courier.com/blog/twilio-notify-end-of-life",
+    "https://www.twilio.com/en-us/changelog/notify-api-end-of-life-further-extension-notice",
+    "https://www.twilio.com/docs/notify/api/notification-resource"
+  ],
+  "status": "unverified"
+}

package/advisories/twilio-rcs-undelivered-error-code-30046.json

@@ -0,0 +1,27 @@
+{
+  "id": "twilio-rcs-undelivered-error-code-30046",
+  "provider": "twilio",
+  "title": "Twilio RCS unconfirmed-delivery error code changed from 30036 to 30046",
+  "summary": "Since August 10, 2026, an RCS message that cannot be delivered to an unreachable device fails with error code 30046 (Message delivery not confirmed) instead of 30036 (Validity Period Expired). Custom SMS failover logic that checks error_code or ErrorCode for 30036 no longer fires; Twilio's native SMS fallback is not affected.",
+  "endpoint": {
+    "method": "GET",
+    "path": "/2010-04-01/Accounts/{AccountSid}/Messages/{Sid}.json"
+  },
+  "changeClass": "enum-added",
+  "trigger": {
+    "enums": [{ "field": "error_code" }]
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-07-09",
+    "url": "https://www.twilio.com/en-us/changelog/rcs-error-code-changing"
+  },
+  "effectiveDate": "2026-08-10",
+  "severity": "medium",
+  "migrationNote": "Wherever you branch on error_code (Message resource) or ErrorCode (status callbacks) to trigger SMS failover for RCS, treat 30046 the same as 30036, and test the fallback path.",
+  "sources": [
+    "https://www.twilio.com/en-us/changelog/rcs-error-code-changing",
+    "https://www.twilio.com/docs/messaging/api/message-resource"
+  ],
+  "status": "verified"
+}

package/advisories/twilio-voice-insights-conference-participant-removed.json

@@ -0,0 +1,28 @@
+{
+  "id": "twilio-voice-insights-conference-participant-removed",
+  "provider": "twilio",
+  "title": "Twilio Voice Insights Call Summary drops attributes.conference_participant on 2026-08-01",
+  "summary": "On August 1, 2026 Twilio removed the conference_participant attribute from the Voice Insights Call Summary (GET /v1/Voice/{CallSid}/Summary on insights.twilio.com) and the matching Event Streams event; attributes now returns null for every call. Code that reads attributes.conference_participant gets nothing, and code that dereferences attributes can throw.",
+  "endpoint": {
+    "method": "GET",
+    "path": "/v1/Voice/{CallSid}/Summary"
+  },
+  "changeClass": "field-rename",
+  "trigger": {
+    "fields": ["attributes.conference_participant"]
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-07-01",
+    "url": "https://www.twilio.com/en-us/changelog/voice-insights-removal-conference-participant-field"
+  },
+  "effectiveDate": "2026-08-01",
+  "severity": "medium",
+  "migrationNote": "Stop reading attributes.conference_participant and treat attributes as nullable. Get conference data from the Conference Insights API or Conference Insights Event Streams instead.",
+  "sources": [
+    "https://www.twilio.com/en-us/changelog/voice-insights-removal-conference-participant-field",
+    "https://www.twilio.com/docs/voice/voice-insights/api/call/details-call-summary",
+    "https://www.twilio.com/docs/voice/voice-insights/api/call/call-summary-resource"
+  ],
+  "status": "verified"
+}

package/advisories/x-activity-api-pascalcase-event-types-removed.json

@@ -0,0 +1,31 @@
+{
+  "id": "x-activity-api-pascalcase-event-types-removed",
+  "provider": "x",
+  "title": "X Activity API event types renamed from PascalCase to dot-separated lowercase",
+  "summary": "From 2026-03-18 the X Activity API (XAA) uses dot-separated lowercase event_type values such as profile.update.bio instead of PascalCase names such as ProfileBioUpdate. Subscriptions created with, or event handlers that switch on, the old names stop matching.",
+  "endpoint": {
+    "method": "*",
+    "path": "/2/activity/**"
+  },
+  "changeClass": "enum-added",
+  "trigger": {
+    "enums": [
+      {
+        "field": "event_type"
+      }
+    ]
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-03-13",
+    "url": "https://docs.x.com/changelog"
+  },
+  "effectiveDate": "2026-03-18",
+  "severity": "high",
+  "migrationNote": "Send the new lowercase names (for example profile.update.bio, follow.follow, post.create) in POST /2/activity/subscriptions and update every filter, switch statement and deserializer that reads event_type from the activity stream or webhook payloads.",
+  "sources": [
+    "https://docs.x.com/changelog",
+    "https://docs.x.com/x-api/activity/introduction"
+  ],
+  "status": "verified"
+}

package/advisories/x-self-serve-follow-writes-removed.json

@@ -0,0 +1,27 @@
+{
+  "id": "x-self-serve-follow-writes-removed",
+  "provider": "x",
+  "title": "Following users removed from X API self-serve tiers",
+  "summary": "X's 2026-04-16 changelog says Following via the API has been removed from all self-serve tiers (Free, Basic, Pro, pay-per-use), leaving it to Enterprise. POST /2/users/{id}/following calls with self-serve credentials are rejected; X does not document the status code.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/2/users/{id}/following"
+  },
+  "changeClass": "scope-change",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-04-16",
+    "url": "https://docs.x.com/changelog"
+  },
+  "effectiveDate": "2026-04-16",
+  "severity": "critical",
+  "migrationNote": "Remove or feature-flag follow actions for self-serve apps and show users a clear message (for example a link to the profile so they can follow in the X app), or move to an Enterprise agreement.",
+  "sources": [
+    "https://docs.x.com/changelog",
+    "https://opentweet.io/how-to/fix-x-api-like-follow-endpoint-removed"
+  ],
+  "status": "verified"
+}

package/advisories/x-self-serve-like-writes-removed.json

@@ -0,0 +1,27 @@
+{
+  "id": "x-self-serve-like-writes-removed",
+  "provider": "x",
+  "title": "Liking Posts removed from X API self-serve tiers",
+  "summary": "X's 2026-04-16 changelog says Following, Likes and Quote-Posts via the API have been removed from all self-serve tiers (Free, Basic, Pro, pay-per-use), leaving them to Enterprise. POST /2/users/{id}/likes calls with self-serve credentials are rejected; X does not document the status code. Quote-Posts (POST /2/tweets with quote_tweet_id) are also removed but cannot be matched by path.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/2/users/{id}/likes"
+  },
+  "changeClass": "scope-change",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-04-16",
+    "url": "https://docs.x.com/changelog"
+  },
+  "effectiveDate": "2026-04-16",
+  "severity": "critical",
+  "migrationNote": "Remove or feature-flag like actions for self-serve apps and surface a clear error to users, or move to an Enterprise agreement. Also drop quote_tweet_id from POST /2/tweets on self-serve keys.",
+  "sources": [
+    "https://docs.x.com/changelog",
+    "https://opentweet.io/how-to/fix-x-api-like-follow-endpoint-removed"
+  ],
+  "status": "verified"
+}

package/advisories/xero-accounting-transactions-scope-split.json

@@ -0,0 +1,27 @@
+{
+  "id": "xero-accounting-transactions-scope-split",
+  "provider": "xero",
+  "title": "Broad accounting.transactions scope replaced by granular scopes",
+  "summary": "Xero split accounting.transactions into granular scopes (invoices, payments, bank transactions, manual journals, classic expenses, each with a .read variant). Apps created after 2026-03-02 must request granular scopes; existing apps keep the broad scopes until September 2027, and each connected user must re-authorize to receive the new ones.",
+  "endpoint": {
+    "method": "*",
+    "path": "/api.xro/2.0/**"
+  },
+  "changeClass": "scope-change",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": null,
+    "url": "https://devblog.xero.com/upcoming-changes-to-xero-accounting-api-scopes-705c5a9621a0"
+  },
+  "effectiveDate": "2027-09-13",
+  "severity": "medium",
+  "migrationNote": "Request the granular scopes in the authorization URL and have each connection re-authorize before the cutoff.",
+  "sources": [
+    "https://devblog.xero.com/upcoming-changes-to-xero-accounting-api-scopes-705c5a9621a0",
+    "https://www.apideck.com/blog/xero-scopes"
+  ],
+  "status": "verified"
+}

package/advisories/xero-allocations-contact-mismatch-rejected.json

@@ -0,0 +1,27 @@
+{
+  "id": "xero-allocations-contact-mismatch-rejected",
+  "provider": "xero",
+  "title": "Allocations between documents of different contacts are rejected",
+  "summary": "Xero now requires a credit note, prepayment or overpayment to belong to the same contact as the invoice or bill it is allocated to. Allocation requests with a contact mismatch return a validation error. The notice is dated 2026-10-08 and gives no separate enforcement date.",
+  "endpoint": {
+    "method": "PUT",
+    "path": "/api.xro/2.0/*/{id}/Allocations"
+  },
+  "changeClass": "status-code",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-10-08",
+    "url": "https://developer.xero.com/changelog"
+  },
+  "effectiveDate": "2026-10-08",
+  "severity": "medium",
+  "migrationNote": "Before calling PUT /CreditNotes/{CreditNoteID}/Allocations, /Prepayments/{PrepaymentID}/Allocations or /Overpayments/{OverpaymentID}/Allocations, check that Contact.ContactID is the same on the source document and on the target invoice or bill. On a validation error, show the user the mismatch instead of retrying, because the unchanged request keeps failing.",
+  "sources": [
+    "https://developer.xero.com/changelog",
+    "https://raw.githubusercontent.com/XeroAPI/Xero-OpenAPI/master/xero_accounting.yaml"
+  ],
+  "status": "unverified"
+}

package/advisories/xero-au-payroll-isqualifyingearnings-required.json

@@ -0,0 +1,28 @@
+{
+  "id": "xero-au-payroll-isqualifyingearnings-required",
+  "provider": "xero",
+  "title": "AU Payroll pay item and earnings rate writes require IsQualifyingEarnings",
+  "summary": "Since 2026-09-10, AU Payroll create and update requests for Earnings Rates and Pay Items must include IsQualifyingEarnings. Requests without it return a 400 validation error, and when it is true the matching super flag must agree. The same rule applies to the v2 endpoint POST /payroll.xro/2.0/earningsRates.",
+  "endpoint": {
+    "method": "POST",
+    "path": "/payroll.xro/1.0/PayItems"
+  },
+  "changeClass": "required-field",
+  "trigger": {
+    "any": true
+  },
+  "firstObserved": null,
+  "publishedNotice": {
+    "date": "2026-09-10",
+    "url": "https://developer.xero.com/changelog"
+  },
+  "effectiveDate": "2026-09-10",
+  "severity": "critical",
+  "migrationNote": "Add IsQualifyingEarnings to every earnings rate sent to POST /payroll.xro/1.0/PayItems, and isQualifyingEarnings to POST /payroll.xro/2.0/earningsRates. Keep it consistent with the super flags: when it is true, Pay Items need IsExemptFromSuper false and Earnings Rates need IsSubjectToSuper true. For rates you read and write back, keep the value Xero returned.",
+  "sources": [
+    "https://developer.xero.com/changelog",
+    "https://developer.xero.com/documentation/api/payrollau/payitems",
+    "https://developer.xero.com/documentation/api/payrollau/earningsrates"
+  ],
+  "status": "verified"
+}