> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beta.b3os.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Cancel a batch scrape (Firecrawl)

Cancels the batch. Answers `409` when it already finished, which the SDKs treat as nothing to cancel.

` DELETE /compat/firecrawl/v1/batch/scrape/{id} `

Cancel a batch scrape (Firecrawl)

Cancels the batch. Answers `409` when it already finished, which the SDKs treat as nothing to cancel.

## Servers

- ` https://beta-api.b3os.org ` — API (API keys and CLI tokens)

- ` https://beta.b3os.org ` — Dashboard (session cookie and CSRF header; same paths)

## Authentication

The operation accepts these alternatives. Schemes within one alternative are required together.

### Alternative 1

- ` apiKey `: ` http `

  - HTTP scheme: ` bearer ` (b3os_sk_ API key or b3os_pat_ token)

  - `Authorization: Bearer <credential>`. Two credential kinds are accepted:

- **API keys** `b3os_sk_<32 base32>_<crc32>`, created in the dashboard or with `POST /v1/keys`. A key belongs to
  one project, has scopes, an optional spend cap and expiry, and is shown only once.
- **CLI tokens** `b3os_pat_<32 base32>_<crc32>`, issued by the device login (`b3os login`). They act for one
  user in the organization and project chosen at approval.

Keys are stored as SHA-256 hashes. The edge exchanges them for a 60-second node token before forwarding
a request to a node, so nodes never see your key.


## Parameters

### ` id ` (path, required)

The job ID B3OS returned (a `crawl_`, `batch_` or `job_` ID; Firecrawl clients treat it as opaque).

- ` value `: type ` string `

  - maxLength: ` 64 `

## Responses

### ` 200 ` — Canceled.

Content type: ` application/json `

- ` value `: type ` object `

  - Required fields: ` status `

  - ` success `: type ` boolean `

    - enum: ` [true] `

  - ` status `: type ` string `

    - enum: ` ["cancelled"] `

Response header ` x-request-id ` — The request ID (`req_…`). It is the `instance` of any problem and the key for `GET /v1/requests/{request_id}`.

- ` value `: type ` string `

  - pattern: ` "^req_[0-9a-hjkmnp-tv-z]{26}$" `

Response header ` Server-Timing ` — Phase durations in milliseconds (W3C Server Timing); the handler's phases break the request down. For a
response whose body size is known, `total` runs from reading the request head to writing the response head.
Streaming responses (event streams, WebSockets, chunked bodies) carry no `total` here: they report their
final phases in the terminal event (`job.succeeded`, `job.failed`, `job.canceled`) or the final job. The
time from the first request byte to the last response byte is recorded in the node's metrics and request
log (`GET /v1/requests/{request_id}`). The edge prepends `edge_auth` and `edge_upstream`.


- ` value `: type ` string `

Example:

```json
{
  "success": true,
  "status": "cancelled"
}
```

### ` 401 ` — Missing or invalid B3OS key (`unauthorized`). Firecrawl `fc-` keys are not accepted.

Content type: ` application/json `

- ` value `: type ` object ` — Firecrawl's error body. `code` and the status come from the B3OS code's `firecrawl` field in errors.yaml (the Firecrawl code where one exists, such as `SCRAPE_TIMEOUT`, otherwise the B3OS code); `x-request-id` carries the request ID.

  - Required fields: ` success `, ` error `

  - ` success `: type ` boolean `

    - enum: ` [false] `

  - ` error `: type ` string ` — `<prefix>: <detail>`, where the prefix is the B3OS code's `firecrawl.error` in errors.yaml and the detail is the B3OS problem's `detail`; the prefix alone when the problem has no detail. 

  - ` code `: type ` string `

  - ` details `: type ` unknown ` — Validation issues. A `400` `invalid_request` carries the B3OS problem's `errors[]` array here; unknown body fields are reported as Firecrawl reports them, as Zod-style `unrecognized_keys` issues (`{code, keys, path, message}`). 

Response header ` x-request-id ` — The request ID (`req_…`). It is the `instance` of any problem and the key for `GET /v1/requests/{request_id}`.

- ` value `: type ` string `

  - pattern: ` "^req_[0-9a-hjkmnp-tv-z]{26}$" `

Response header ` Server-Timing ` — Phase durations in milliseconds (W3C Server Timing); the handler's phases break the request down. For a
response whose body size is known, `total` runs from reading the request head to writing the response head.
Streaming responses (event streams, WebSockets, chunked bodies) carry no `total` here: they report their
final phases in the terminal event (`job.succeeded`, `job.failed`, `job.canceled`) or the final job. The
time from the first request byte to the last response byte is recorded in the node's metrics and request
log (`GET /v1/requests/{request_id}`). The edge prepends `edge_auth` and `edge_upstream`.


- ` value `: type ` string `

Example:

```json
{
  "success": false,
  "error": "Unauthorized: Invalid token",
  "code": "unauthorized"
}
```

### ` 404 ` — No such job in this project (`crawl_not_found`, `batch_not_found`, `job_not_found`).

Content type: ` application/json `

- ` value `: type ` object ` — Firecrawl's error body. `code` and the status come from the B3OS code's `firecrawl` field in errors.yaml (the Firecrawl code where one exists, such as `SCRAPE_TIMEOUT`, otherwise the B3OS code); `x-request-id` carries the request ID.

  - Required fields: ` success `, ` error `

  - ` success `: type ` boolean `

    - enum: ` [false] `

  - ` error `: type ` string ` — `<prefix>: <detail>`, where the prefix is the B3OS code's `firecrawl.error` in errors.yaml and the detail is the B3OS problem's `detail`; the prefix alone when the problem has no detail. 

  - ` code `: type ` string `

  - ` details `: type ` unknown ` — Validation issues. A `400` `invalid_request` carries the B3OS problem's `errors[]` array here; unknown body fields are reported as Firecrawl reports them, as Zod-style `unrecognized_keys` issues (`{code, keys, path, message}`). 

Response header ` x-request-id ` — The request ID (`req_…`). It is the `instance` of any problem and the key for `GET /v1/requests/{request_id}`.

- ` value `: type ` string `

  - pattern: ` "^req_[0-9a-hjkmnp-tv-z]{26}$" `

Response header ` Server-Timing ` — Phase durations in milliseconds (W3C Server Timing); the handler's phases break the request down. For a
response whose body size is known, `total` runs from reading the request head to writing the response head.
Streaming responses (event streams, WebSockets, chunked bodies) carry no `total` here: they report their
final phases in the terminal event (`job.succeeded`, `job.failed`, `job.canceled`) or the final job. The
time from the first request byte to the last response byte is recorded in the node's metrics and request
log (`GET /v1/requests/{request_id}`). The edge prepends `edge_auth` and `edge_upstream`.


- ` value `: type ` string `

Example:

```json
{
  "success": false,
  "error": "Crawl job not found: No crawl crawl_01m5t4gh4qhgs70zwajezbe5p0 in this project",
  "code": "crawl_not_found"
}
```

### ` 409 ` — The job already finished (`job_already_finished`).

Content type: ` application/json `

- ` value `: type ` object ` — Firecrawl's error body. `code` and the status come from the B3OS code's `firecrawl` field in errors.yaml (the Firecrawl code where one exists, such as `SCRAPE_TIMEOUT`, otherwise the B3OS code); `x-request-id` carries the request ID.

  - Required fields: ` success `, ` error `

  - ` success `: type ` boolean `

    - enum: ` [false] `

  - ` error `: type ` string ` — `<prefix>: <detail>`, where the prefix is the B3OS code's `firecrawl.error` in errors.yaml and the detail is the B3OS problem's `detail`; the prefix alone when the problem has no detail. 

  - ` code `: type ` string `

  - ` details `: type ` unknown ` — Validation issues. A `400` `invalid_request` carries the B3OS problem's `errors[]` array here; unknown body fields are reported as Firecrawl reports them, as Zod-style `unrecognized_keys` issues (`{code, keys, path, message}`). 

Response header ` x-request-id ` — The request ID (`req_…`). It is the `instance` of any problem and the key for `GET /v1/requests/{request_id}`.

- ` value `: type ` string `

  - pattern: ` "^req_[0-9a-hjkmnp-tv-z]{26}$" `

Response header ` Server-Timing ` — Phase durations in milliseconds (W3C Server Timing); the handler's phases break the request down. For a
response whose body size is known, `total` runs from reading the request head to writing the response head.
Streaming responses (event streams, WebSockets, chunked bodies) carry no `total` here: they report their
final phases in the terminal event (`job.succeeded`, `job.failed`, `job.canceled`) or the final job. The
time from the first request byte to the last response byte is recorded in the node's metrics and request
log (`GET /v1/requests/{request_id}`). The edge prepends `edge_auth` and `edge_upstream`.


- ` value `: type ` string `

Example:

```json
{
  "success": false,
  "error": "Job already finished: crawl_01m5t4gh4qhgs70zwajezbe5p0 already succeeded",
  "code": "job_already_finished"
}
```

### ` 500 ` — Something failed inside B3OS (`internal`).

Content type: ` application/json `

- ` value `: type ` object ` — Firecrawl's error body. `code` and the status come from the B3OS code's `firecrawl` field in errors.yaml (the Firecrawl code where one exists, such as `SCRAPE_TIMEOUT`, otherwise the B3OS code); `x-request-id` carries the request ID.

  - Required fields: ` success `, ` error `

  - ` success `: type ` boolean `

    - enum: ` [false] `

  - ` error `: type ` string ` — `<prefix>: <detail>`, where the prefix is the B3OS code's `firecrawl.error` in errors.yaml and the detail is the B3OS problem's `detail`; the prefix alone when the problem has no detail. 

  - ` code `: type ` string `

  - ` details `: type ` unknown ` — Validation issues. A `400` `invalid_request` carries the B3OS problem's `errors[]` array here; unknown body fields are reported as Firecrawl reports them, as Zod-style `unrecognized_keys` issues (`{code, keys, path, message}`). 

Response header ` x-request-id ` — The request ID (`req_…`). It is the `instance` of any problem and the key for `GET /v1/requests/{request_id}`.

- ` value `: type ` string `

  - pattern: ` "^req_[0-9a-hjkmnp-tv-z]{26}$" `

Response header ` Server-Timing ` — Phase durations in milliseconds (W3C Server Timing); the handler's phases break the request down. For a
response whose body size is known, `total` runs from reading the request head to writing the response head.
Streaming responses (event streams, WebSockets, chunked bodies) carry no `total` here: they report their
final phases in the terminal event (`job.succeeded`, `job.failed`, `job.canceled`) or the final job. The
time from the first request byte to the last response byte is recorded in the node's metrics and request
log (`GET /v1/requests/{request_id}`). The edge prepends `edge_auth` and `edge_upstream`.


- ` value `: type ` string `

Example:

```json
{
  "success": false,
  "error": "Internal Server Error",
  "code": "internal"
}
```

## Request examples

### cURL

```curl
curl -X DELETE 'https://beta-api.b3os.org/compat/firecrawl/v1/batch/scrape/string' \
  -H 'Authorization: Bearer YOUR_API_TOKEN'
```

### JavaScript

```javascript
const response = await fetch('https://beta-api.b3os.org/compat/firecrawl/v1/batch/scrape/string', {
  method: 'DELETE',
  headers: {
      "Authorization": "Bearer YOUR_API_TOKEN"
  }
});

const data = await response.json();
console.log(data);
```

### Python

```python
import requests

headers = {
    'Authorization': 'Bearer YOUR_API_TOKEN'
}

response = requests.delete('https://beta-api.b3os.org/compat/firecrawl/v1/batch/scrape/string', headers=headers)
print(response.json())
```