The Snyk REST API is the modern, date-versioned interface for programmatic access to Snyk, and the thing that surprises most first-time integrators is that every request must carry a ?version= query parameter or it fails with a 400. It replaces the older v1 API, follows the JSON:API standard, and is where Snyk now focuses new development. If you are building automation against Snyk today, this is the surface you want.
This guide covers what makes the REST API different, how authentication works, and how to make a first successful call, based on Snyk's published documentation.
REST API versus the v1 API
Snyk historically shipped a v1 API at https://api.snyk.io/v1/. It still exists and much automation still relies on it, but Snyk has stated the v1 API will eventually be deprecated and that new development targets the REST API. The two are structurally different animals.
The v1 API is a conventional endpoint layout. The REST API, in contrast, is built on the JSON:API specification, defined in OpenAPI, and — most importantly — each endpoint is independently versioned by date. That last point is the one to internalize.
Date-based versioning
Instead of a single /v2/ in the path, the Snyk REST API versions every endpoint by a date string passed as a query parameter:
https://api.snyk.io/rest/orgs/{org_id}/projects?version=2024-10-15
Omit the version parameter and the request returns a 400. This design lets Snyk evolve individual endpoints without breaking existing integrations: you pin the exact behavior you built against, and you opt into newer behavior deliberately by bumping the date. Snyk recommends using a recent stable date such as 2024-10-15 unless you have a specific reason to pin an earlier one. Versions also carry stability tiers, so check the docs for whether an endpoint you depend on is generally available or still experimental.
Authentication
Authentication uses a token in the Authorization header. For the REST API the format is:
Authorization: token <YOUR_API_TOKEN>
You can use a personal API token from your Snyk account settings, but for anything running unattended — CI/CD scanning, scheduled jobs, integrations — Snyk recommends a service account token scoped at the Group or Org level rather than a personal token tied to an individual. Service accounts survive employee turnover and can be scoped down, which matters for audit.
A note that catches people: the v1 API expects the same token <TOKEN> scheme, so if you are porting v1 automation the header format carries over cleanly even though the URLs and response shapes do not.
Your first call
Here is a minimal request to list the organizations your token can see:
curl --request GET \
--url 'https://api.snyk.io/rest/orgs?version=2024-10-15' \
--header 'Authorization: token YOUR_API_TOKEN' \
--header 'Content-Type: application/vnd.api+json'
The response follows JSON:API conventions: a top-level data array, each item with id, type, and attributes. Grab an org ID from that, and you can then list its projects:
curl --request GET \
--url 'https://api.snyk.io/rest/orgs/{ORG_ID}/projects?version=2024-10-15' \
--header 'Authorization: token YOUR_API_TOKEN'
Pagination and rate limits
REST API list endpoints paginate using cursor links. Rather than incrementing a page number, you follow the links.next URL returned in each response until it is absent. Build your loop around that link, not around a computed offset, because the cursor encodes state you should not reconstruct yourself.
Respect rate limits. When you get a 429, back off using the retry hint rather than hammering the endpoint. For bulk work, request a sensible page size and follow the cursor rather than firing many parallel requests.
When you would reach for the API at all
The API earns its keep when the UI cannot scale to your need: pulling issue data across dozens of organizations into a central dashboard, wiring Snyk findings into a ticketing system, or enforcing a policy gate in a pipeline. If your goal is simply catching vulnerable dependencies in every build, most scanners — Snyk included, and alternatives such as Safeguard — expose that through a CLI and native CI integrations without you writing API glue at all. Reach for the raw API when you are aggregating or automating beyond what those integrations give you.
If you are still deciding between tools before you commit to an integration, our Snyk comparison breaks down the tradeoffs, and the SCA product overview covers what dependency scanning looks like end to end.
FAQ
Why does my Snyk REST API request return a 400?
The most common cause is a missing version query parameter. Every Snyk REST API endpoint requires ?version=YYYY-MM-DD. Add a recent date such as ?version=2024-10-15 and the request should succeed, assuming your token and org ID are valid.
Should I use the REST API or the v1 API?
Use the REST API for new work. Snyk has stated the v1 API will eventually be deprecated and focuses new development on the REST API. The v1 API still functions, so existing integrations do not need an emergency rewrite, but do not build new automation on it.
What token should I use for CI/CD automation?
A service account token scoped at the Group or Org level, not a personal API token. Service accounts are not tied to an individual user, survive staff changes, and can be scoped down, which is what you want for anything running unattended in a pipeline.
How does pagination work in the Snyk REST API?
It uses cursor-based pagination. Each list response includes a links.next URL; follow it to get the next page and stop when it is absent. Do not build pagination around incrementing a page number or offset.