> ## 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.

# Get credit usage (Firecrawl)

B3OS counts one Firecrawl credit per `vision.page`. `plan_credits` is your organization's monthly page allowance (`GET /v1/limits` lists it as `vision.pages.monthly`) and `remaining_credits` the allowance minus the pages billed this period; the period is the billing period of `GET /v1/limits` (the UTC calendar month). Both are `null` when the organization has no page allowance. The free beta reports the allowance but does not stop scraping when it reaches 0. Field names are snake_case, as in Firecrawl v1.

` GET /compat/firecrawl/v1/team/credit-usage `

Get credit usage (Firecrawl)

B3OS counts one Firecrawl credit per `vision.page`. `plan_credits` is your organization's monthly page allowance (`GET /v1/limits` lists it as `vision.pages.monthly`) and `remaining_credits` the allowance minus the pages billed this period; the period is the billing period of `GET /v1/limits` (the UTC calendar month). Both are `null` when the organization has no page allowance. The free beta reports the allowance but does not stop scraping when it reaches 0. Field names are snake_case, as in Firecrawl v1.

## 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.


## Responses

### ` 200 ` — The credit usage.

Content type: ` application/json `

- ` value `: type ` object `

  - Required fields: ` success `, ` data `

  - ` success `: type ` boolean `

    - enum: ` [true] `

  - ` data `: type ` object `

    - Required fields: ` remaining_credits `, ` plan_credits `, ` billing_period_start `, ` billing_period_end `

    - ` remaining_credits `: type ` number `; nullable

    - ` plan_credits `: type ` number `; nullable

    - ` billing_period_start `: type ` string `; nullable; format ` date-time `

    - ` billing_period_end `: type ` string `; nullable; format ` date-time `

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,
  "data": {
    "remaining_credits": 81796,
    "plan_credits": 100000,
    "billing_period_start": "2026-10-01T00:00:00.000Z",
    "billing_period_end": "2026-11-01T00:00:00.000Z"
  }
}
```

### ` 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"
}
```

### ` 429 ` — A rate or concurrency limit applies (`rate_limited`, `concurrency_limited`).

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 `

Response header ` Retry-After ` — Seconds to wait before retrying or polling again.

- ` value `: type ` integer `

  - minimum: ` 0 `

Example:

```json
{
  "success": false,
  "error": "Rate limit exceeded",
  "code": "rate_limited"
}
```

### ` 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 GET 'https://beta-api.b3os.org/compat/firecrawl/v1/team/credit-usage' \
  -H 'Authorization: Bearer YOUR_API_TOKEN'
```

### JavaScript

```javascript
const response = await fetch('https://beta-api.b3os.org/compat/firecrawl/v1/team/credit-usage', {
  method: 'GET',
  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.get('https://beta-api.b3os.org/compat/firecrawl/v1/team/credit-usage', headers=headers)
print(response.json())
```