Updating API Integrations
If you configure Socket through the REST API rather than the dashboard, these pages map the legacy Security Policy and Alert Triage endpoints onto their replacements, with the request and response shapes for each:
- Security Policy API — the per-alert-type action map becomes a policy with a baseline plus explicit rules.
- Alert Triage API — pattern rules become policy rules; specific suppressions become alert resolutions.
Once your organization has migrated, the legacy endpoints stop accepting writes, so update your automation before the cutover. The migration window is 30 days from when migration is enabled for your organization — your dashboard shows the exact date. See Migrating to Policies for the migration itself.
All requests use https://api.socket.dev/v0 with an organization API token, passed as a bearer token or as the user field in basic auth:
curl -u "$SOCKET_API_TOKEN:" https://api.socket.dev/v0/orgs/$ORG/alert-policiesEndpoint Mapping
| Legacy | Replacement |
|---|---|
GET /orgs/{org_slug}/settings/security-policy | GET /orgs/{org_slug}/alert-policies and GET /orgs/{org_slug}/alert-policies/{policy_id}/rules |
POST /orgs/{org_slug}/settings/security-policy | POST /orgs/{org_slug}/alert-policies, PUT /orgs/{org_slug}/alert-policies/{policy_id}, and the rule endpoints below |
GET /orgs/{org_slug}/triage/alerts | GET /orgs/{org_slug}/alert-policies/{policy_id}/rules and GET /orgs/{org_slug}/alerts/resolutions |
POST /orgs/{org_slug}/triage/alerts | POST /orgs/{org_slug}/alert-policies/{policy_id}/rules and POST /orgs/{org_slug}/alerts/resolutions |
DELETE /orgs/{org_slug}/triage/alerts/{uuid} | DELETE /orgs/{org_slug}/alert-policies/{policy_id}/rules/{rule_id} and DELETE /orgs/{org_slug}/alerts/resolutions/{uuid} |
Each legacy triage endpoint maps onto two replacements because the legacy triage table did two different jobs. Entries that changed the action for a class of packages become policy rules; entries that suppressed a specific finding become alert resolutions.
Policies also gained endpoints with no legacy equivalent, because policies did not exist as objects before: GET, PUT, and DELETE on /orgs/{org_slug}/alert-policies/{policy_id}, and GET, PUT, and DELETE on a single rule.
Token Scopes
| Endpoint group | Scopes |
|---|---|
| Alert policies and rules | alert-policy:list, alert-policy:read, alert-policy:create, alert-policy:update, alert-policy:delete |
| Alert resolutions | alert-resolution:list, alert-resolution:read, alert-resolution:create, alert-resolution:delete |
| Legacy security policy | security-policy:read, security-policy:update |
| Legacy alert triage | triage:alerts-list, triage:alerts-update |
Every alert-policy endpoint requires a token with organization-wide repository access; tokens restricted to specific repositories receive 403. Alert resolutions are readable and writable by repository-restricted tokens within their granted repositories — see Resolve Alerts.
Full Reference
Complete request and response schemas for every endpoint are in the API reference:
- Policies — list, create, get, update, delete
- Policy rules — list, create, get, update, delete
- Alert resolutions — list, create, get, delete
Related Pages
Updated 1 day ago