AI news · 2 min read

Cursor Origin changes how integrations recognise automated reviews

Cursor’s October 9 Origin API change replaces a shared actor identity with service accounts. Update review matching and author filters in integrations.

Announcement date:

Affiliate disclosure: Some links may earn CreatorStack a commission at no extra cost to you.

At a glance

Cursor’s October 9 Origin API change identifies automated actions by their service accounts instead of the shared origin-cursor-managed-actor identity. Integration owners should match serviceAccount.id or type and use returned account IDs in author filters. Origin remains Early Beta.

An illustrated research desk with comparison charts, notes and a magnifying glass
CreatorStack illustration. Editorial illustration of this story’s topic, rather than a product screenshot or tested result.

If you maintain a dashboard that counts automated code reviews, an identity change can make work disappear from your report even when the review still exists. Cursor’s October 9, 2026 Origin API update changes how those actions are attributed. This matters to creators building integrations; it does not require every Cursor chat user to migrate. Dated breaking change.

Follow the account behind the action

Pull requests, reviews, comments and reactions now identify the relevant service account rather than the shared origin-cursor-managed-actor identity. The account has an sa_… ID and a type, such as bugbot or automations. Cursor’s own app uses an app_… ID. Account attribution.

The difference is useful when a report needs to separate kinds of automation. “Cursor” is a readable name; an account ID tells your parser which account acted. A type can group accounts for a report. Choosing between those two depends on whether you want one account’s history or a category of activity.

Cursor’s migration guidance is to stop matching the old shared identity, use serviceAccount.id or serviceAccount.type, and pass a returned sa_… or app_… ID when filtering pull requests by author. Webhooks and check runs already named these accounts. Origin remains Early Beta, so integrations need to follow its changelog. Migration and status.

Check the reader of the response, not just the response

Our proposed dashboard check is simple: compare one representative automated-review response with the parser and author filter that consume it. Does the parser still look for the retired identity? Does its account type reach the intended group? Does the filter use an ID returned by the API?

Use that response as a fixture before rolling out a parser change. This is an illustrative check, not a migration we executed or proof that your integration has failed. If you only use Cursor’s editor, no integration work follows from this story. For a different everyday workflow, see controlling a local Cursor agent from your phone.

Common questions

Questions people ask.

Is this a change to every Cursor chat?
The announcement concerns the Origin public API’s attribution of pull requests, reviews, comments and reactions. It is not a blanket change to ordinary chat.
Can I identify an automated account by the name Cursor?
The changelog recommends serviceAccount.id or serviceAccount.type. A display name is a readable label, not a unique account identifier.

Sources & freshness

This article was refreshed on 11 Oct 2026 using the sources below. A source check verifies published information, not output quality or checkout availability in every region.

What changed: New reporting on a breaking response-identity migration for automated reviews and author filters, with a proposed integration check.

Found a correction? Let us know.

Need help applying this? Explore a workflow audit or get future guides by email.