I created a Cursor automation that uses a Webhook about two weeks ago that seemed to work fine.
In the last few days it seemed to fail, even after regenerating a new token.
I even tried creating a complete new automation and encountered the same issue.
This is the error I encountered:
"code": "unauthenticated",
"message": "[unauthenticated] Error",
"details": [
{
"type": "aiserver.v1.ErrorDetails",
"debug": {
"error": "ERROR_NOT_LOGGED_IN",
"details": {
"title": "Authentication error",
"detail": "If you are logged in, try logging out and back in.",
"isRetryable": false
},
"isExpected": true
},
"value": "**base64 value**"
}
]
}
Steps to Reproduce
Create an automation with a webhook.
Copy its URL and authorization header into Postman.
Send a request.
Webhook trigger endpoint returns 401 for all external HTTP requests. It stopped working today.
Steps to Reproduce
1.Create an automation with a Webhook trigger (e.g., “Cursor Agent: Runbook”)
2.Save the automation — Cursor generates a webhook URL and auth header
3.Copy the webhook URL and auth header from the UI (“Copy auth header” button)
Send a POST request using curl:
curl -s -X POST “https://api2.cursor.sh/automations/webhook/”
-H “Authorization: Bearer crsr_”
-H “Content-Type: application/json”
-d ‘{“event”:“jira.label_added”,“issueKey”:“JIRA-9999”,“summary”:“Test”}’
Expected Behavior
The webhook triggers an automation run and returns a 2xx response.
Operating System
MacOS
Version Information
This is cloud agent
Additional Information
Actual behavior: The endpoint returns 401 Unauthenticated
Merged the threads for hygiene purposes and have one thread for easier communication.
Thank you for the detailed reports. We’ve identified this as a service-side issue affecting webhook triggers (and other automation endpoints) broadly. This is not specific to any individual account or token.
@premik91, your finding that the token works against api.cursor.com/v0/me confirms the token is valid: the issue is in the automations webhook auth path itself.
Our team is investigating, and I’ll update this thread when the issue is resolved.
Following up here. We’ve confirmed that the webhook authentication issue that was causing widespread 401 errors has largely stabilized.
That said, we are still seeing intermittent occurrences of this issue. Our engineering team is actively investigating the underlying root cause to ensure a permanent fix.
@Artur_Magalhaes, the MCP tool issue you mentioned may have been related to this same backend auth problem. If you’re still seeing MCP tools unavailable, could you confirm whether it’s specific to cloud agents/automations or also affecting other surfaces?
@pjv, noted on the status page feedback. I’ll pass that along.
If anyone is still experiencing consistent 401 errors on webhook triggers as of today, please let me know and I can investigate further.
Thanks for the automation ID. Regarding the automations getting stuck on environment creation, we identified and fixed an issue that was causing automation environments to fail during setup, specifically for automations with MCP servers configured. A fix has been deployed.
However, if your automation had a run that got stuck during this window, it may still be blocking new runs from starting. Could you try the following:
Go to your automation’s runs page and check if there’s a run stuck in a “Running” state
If so, stop that stuck run
Then try triggering a new run
If that doesn’t work, deleting the automation and recreating it with the same configuration should clear the stuck state and allow runs to start fresh.
On the Slack workaround – noted. Calling the Slack API directly via CURL/python is a solid approach in the meantime!
Let me know how it goes or if you face any issues.
Title: Webhook trigger endpoint returns 401 (regression, April 2026)
Category: Bug Reports
Tags: automations, cloud-agents
Body:
My GitHub Actions workflow that triggers a Cursor automation webhook started returning 401 as of April 4. It was working correctly two days prior with no changes on my end.
What I’ve tried:
Regenerated the API key (new crsr_ token)
Authorization: Bearer
Authorization: Basic <base64(token:)>
curl -u :
Tested from both GitHub Actions and local machine
All return the identical response:
{
“code”: “unauthenticated”,
“error”: “ERROR_NOT_LOGGED_IN”,
“detail”: “If you are logged in, try logging out and back in.”
}
Endpoint: POST https://api2.cursor.sh/automations/webhook/
This appears to be the same server-side regression reported in Webhook trigger endpoint returns 401, which was fixed and has now regressed again.
Thank you for the detailed report. This is a confirmed regression of the same server-side issue that affected webhook triggers in late March. The error is not related to your API key or anything on your end.
Our engineering team is aware that this has recurred and is actively working on a permanent fix for the underlying cause. There is no workaround at this time since the issue is entirely server-side.
I’ve also noted the reports from @ItayA and @redefinered-cc — this is the same issue.
I’ll update here once the fix is deployed. Apologies again for the disruption.
Same issue here. I trigger automations programmatically from a self-hosted agent running on a VPS. Started getting the same ERROR_NOT_LOGGED_IN / 500 responses on April 3-4.
Confirmed:
API key authenticates fine (GET /v0/agents returns 200)
POST to both api2.cursor.sh/automations/webhook/ and api.cursor.com/v0/agents return 500
Manual trigger from the dashboard UI still works
Regenerating API keys doesn’t help
Plan upgrade doesn’t help
Appreciate the quick acknowledgement. Following for the fix.
@Feier noted – you’re experiencing the same server-side regression. The additional detail about api.cursor.com/v0/agents also returning 500 is helpful context for the team. Will update here once the fix is deployed.
I set up a Cursor Automation with a webhook trigger. The webhook URL works (returns a response), but the auth header generated via “Generate auth header” always returns 401 unauthenticated, even when tested directly with curl from my terminal seconds after generating it.
