# Trigger an on demand uptime & broken links check after a deploy

You can use our [API](/docs/api/introduction) to trigger an _on demand_ run of both the uptime check and the broken links checker. If you add this to, say, your deploy script, you can have near-instant validation that your deploy succeeded and didn't break any links & pages.

## Find your check IDs

Our API allows you to trigger an on demand run [for every check we do](/docs/api/checks). But, it's an API - so it requires a set of IDs. First, let's find the different checks your site has. In order to use this API command, you need 2 things:

1. An API key, which you can [generate in your user settings](/user/api-tokens).
2. The site ID, which you can find in the "Settings" menu for [every site](/monitors), all the way at the bottom (in this example, we'll take site ID 7024)

Let's find the different checks that are enabled.

```bash
$ curl  https://ohdear.app/api/sites/7024 \
    -H 'Authorization: Bearer [your-api-token-here] ' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' | jq

{
  "id": 7024,
  "url": "https://ohdear.app",
  [...]
  "checks": [
    {
      "id": 32077,
      "type": "uptime",
    },
    {
      "id": 32078,
      "type": "broken_links",
    },
    {
      "id": 32079,
      "type": "mixed_content",
    },
    {
      "id": 32080,
      "type": "certificate_health",
    },
    {
      "id": 32081,
      "type": "certificate_transparency",
    }
  ],
}

```

Some output was truncated, but you get the idea. There's a bunch of checks, each with their own ID.

Take the check you'd like to run on demand (`32077` for the uptime check, `32078` for the broken links check etc.).

## Trigger an on demand run with curl

Most deploy scripts allow you to execute some raw commands. In this example, we'll use `curl` together with your [your API key](/docs/api/introduction) to instruct Oh Dear! to perform a full site check, searching for broken links.

```bash
$ curl -X POST https://ohdear.app/api/checks/32077/request-run \
    -H 'Authorization: Bearer [your-api-token-here]' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' | jq
{
  "id": 32077,
  "type": "uptime",
  "label": "Uptime",
  "enabled": true,
  "latest_run_ended_at": "2019-07-10 12:35:40",
  "latest_run_result": "pending"
}
```

This uses the `/request-run` endpoint of [our API](/docs/api/checks), which you can trigger for every kind of check we have. In this case, we requested a run for the check with ID `32077`.


## Tying it all together

To combine it all in one easy flow, you can call the following `curl` commands to instruct Oh Dear! to do a full site check.

```bash
#!/bin/bash
API_TOKEN=[your-api-token-here]

UPTIME_ID=32077
BROKENLINKS_ID=32078

# Trigger an uptime check
curl -X POST "https://ohdear.app/api/checks/$UPTIME_ID/request-run" \
    -H "Authorization: Bearer $API_TOKEN" \
    -H "Accept: application/json" \
    -H "Content-Type: application/json"

# Trigger the broken links check
curl -X POST "https://ohdear.app/api/checks/$BROKENLINKS_ID/request-run" \
    -H "Authorization: Bearer $API_TOKEN" \
    -H "Accept: application/json" \
    -H "Content-Type: application/json"

```

Pretty neat, hu?