--- title: "legacy-endpoint-migration" url: https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/legacy-endpoint-migration/ --- # undefined # [Legacy Endpoint Migration](https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/legacy-endpoint-migration.md#legacy-endpoint-migration) In the early beta of the Crons product, Check-In endpoints existed under the `sentry.io/api/0/` API namespace. This namespace is not designed for ingestion-level traffic, so we have since moved Check-In APIs to use [Relay](https://docs.sentry.io/product/relay.md) for ingestion of Check-In events. If you're using legacy endpoints for Crons, migrate to the new endpoints to avoid issues. The Legacy endpoints **are deprecated** and will be removed in the future, however a date has not yet been set for their removal. We will communicate a date when one is set. ## [Am I Using Legacy Endpoints?](https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/legacy-endpoint-migration.md#am-i-using-legacy-endpoints) The SDKs do not utilize our legacy endpoints. ##### Sentry CLI Versions of the `sentry-cli` **before v2.19.0** are using the legacy API endpoints. [Please upgrade](https://docs.sentry.io/cli/installation.md#updating-and-uninstalling) to the latest version. If your CLI is configured with an auth token, it will use the legacy API endpoints. Please update your CLI configuration to utilize your project's DSN instead. Refer to the [configuration guide](https://docs.sentry.io/cli/crons.md#configuration) for more information. When using the HTTP endpoints, you can differentiate them like so: ```bash # ❌ Legacy endpoints https://sentry.io/api/0/organizations/___ORG_SLUG___/monitors// # ✅ Relay Check-In ingestion endpoint https://___ORG_INGEST_DOMAIN___/api/___PROJECT_ID___/cron//___PUBLIC_KEY___/ ``` ### [What Changed?](https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/legacy-endpoint-migration.md#what-changed) There are a few backward incompatible changes to be aware of. * There is now only a single Check-In endpoint. The "Check-In details" endpoint has been removed. * The API endpoint supports both `POST` with a JSON body, as well as now supporting `GET`. You can use query parameters to specify `status`, `environment`, etc. The API endpoint will always respond with a `202` with no body (unless there is an error). * Because there is no "details" endpoint, the `PUT` method for a Check-In has also been removed. You will always use `POST` or `GET` for Check-Ins. * For [overlapping jobs](https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/getting-started/http.md#overlapping-jobs-optional), it is still possible to specify a `check_in_id` via the query parameters or JSON body. However, the API no longer responds with an auto-generated Check-In ID. If you need a stable Check-In ID, you must generate it client-side yourself. * The `monitor_config` structure has changed slightly. `schedule` is now an object of varying shape, depending on the schedule type. ```json {"type": "crontab", "value": "0 * * * *"} {"type": "interval", "value": "2", "unit": "hour"} ``` ## [Migration examples](https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/legacy-endpoint-migration.md#migration-examples) See the code samples below to help you migrate from the legacy endpoints to the current ones. ### [Simple HTTP Check-Ins](https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/legacy-endpoint-migration.md#simple-http-check-ins) ```sh # ❌ Legacy simple `in_progress` -> `ok` check-in curl -X POST \ 'https://sentry.io/api/0/organizations/___ORG_SLUG___/monitors//checkins/' \ --header 'Authorization: DSN ___PUBLIC_DSN___' \ --header 'Content-Type: application/json' \ --data-raw '{"status": "in_progress"}' curl -X POST \ 'https://sentry.io/api/0/organizations/___ORG_SLUG___/monitors//checkins/' \ --header 'Authorization: DSN ___PUBLIC_DSN___' \ --header 'Content-Type: application/json' \ --data-raw '{"status": "ok"}' # ✅ New style `in_progress` -> `ok` check-in SENTRY_INGEST="https://___ORG_INGEST_DOMAIN___" SENTRY_CRONS="${SENTRY_INGEST}/api/___PROJECT_ID___/cron//___PUBLIC_KEY___/" curl "${SENTRY_CRONS}?status=in_progress" curl "${SENTRY_CRONS}?status=ok" ``` ### [Monitor Upsert Check-In](https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/legacy-endpoint-migration.md#monitor-upsert-check-in) ```sh # ❌ Legacy upsert monitor with a check-in curl -X POST \ 'https://sentry.io/api/0/organizations/___ORG_SLUG___/monitors//checkins/' \ --header 'Authorization: DSN ___PUBLIC_DSN___' \ --header 'Content-Type: application/json' \ --data-raw '{"monitor_config": {"schedule": "0 * * * *", "schedule_type": "crontab"}, "status": "in_progress"}' # ✅ New style upsert monitor with a check-in SENTRY_INGEST="https://___ORG_INGEST_DOMAIN___" SENTRY_CRONS="${SENTRY_INGEST}/api/___PROJECT_ID___/cron//___PUBLIC_KEY___/" curl -X POST "${SENTRY_CRONS}?status=in_progress" \ --header 'Content-Type: application/json' \ --data-raw '{"monitor_config": {"schedule": {"type": "crontab", "value": "0 * * * *"}}, "status": "in_progress"}' # 👉 Note that schedule is now an object ---^ ``` ### [Overlapping Job Check-Ins (specifying `check_in_id`)](https://docs.sentry.io/product/new-monitors-and-alerts/monitors/crons/legacy-endpoint-migration.md#overlapping-job-check-ins-specifying-check_in_id) ```sh # ❌ Legacy Check-In with ID curl -X POST \ 'https://sentry.io/api/0/organizations/___ORG_SLUG___/monitors//checkins/' \ --header 'Authorization: DSN ___PUBLIC_DSN___' \ --header 'Content-Type: application/json' \ --data-raw '{"status": "in_progress"}' # Response { "id": "2bc1a871-a1b7-4577-82fc-fa6d2468aabc" } # ✅ New style upsert monitor with a check-in CHECK_IN_ID="$(uuidgen)" # 👉 Note that you now need to generate the Check-In UUID SENTRY_INGEST="https://___ORG_INGEST_DOMAIN___" SENTRY_CRONS="${SENTRY_INGEST}/api/___PROJECT_ID___/cron//___PUBLIC_KEY___/" curl "${SENTRY_CRONS}?check_in_id=${CHECK_IN_ID}&status=in_progress" # 👉 Note that no Check-In ID is returned ```