# Get scan results
Source: https://docs.techslayers.ca/darkrecon/api/get-scan-results

openapi/darkrecon.json GET /scan/{scan_id}
Retrieve the stored DarkRecon result payload by scan UUID.

# Get scan results

Returns the full stored result payload for a previous scan.

## What comes back

* Top-level metadata such as `scan_id`, `status`, `total_breaches`, and `created_at`.
* The original `keywords` array or the scanned `domain`.
* Optional `discovered_emails` for domain-driven scans.
* Optional `error_detail` when the stored scan ended in an error state.
* A `results` object keyed by breach database name.

## Result parsing notes

* Each breach source object contains `InfoLeak`, `NumOfResults`, and `Data`.
* `Data` is an array of raw records from that source. Field names vary across breach databases.
* Password-like values are masked in returned records.
* `total_breaches` counts breach sources, not the total number of records across all `Data` arrays.

## Error behavior

* `404`: the supplied `scan_id` does not exist.
* `403`: the API key could not be validated.
* `422`: request validation failed, such as a missing `X-API-Key` header or malformed path input.


# Start scan
Source: https://docs.techslayers.ca/darkrecon/api/start-scan

openapi/darkrecon.json POST /scan
Scan keywords or a domain for breach data and create a stored DarkRecon result.

# Start scan

Creates a stored scan and returns the `scan_id` you will use for follow-up retrieval.

<Warning>
  The live API uses `keywords`. If you still send `queries`, your request will not match the current contract.
</Warning>

## Choose one input mode

* `keywords`: send one or more search terms such as emails, phone numbers, usernames, IPs, passwords, car plates, social IDs, or composite strings.
* `domain`: send a single domain to enumerate breached emails and scan the discovered addresses automatically.

Do not send both in the same request.

## Keyword guidance

* Each keyword is queried independently against the breach dataset.
* Composite queries are supported when you want to correlate multiple terms inside a single search string.
* Domain scans can return `discovered_emails` immediately in the `POST /scan` response.

## Response semantics

* `scan_id` is the durable identifier for the stored scan.
* `status` can be `success`, `no_results`, or `no_queries`.
* `total_breaches` is the number of matched breach sources.
* Full raw breach records are not returned by `POST /scan`; retrieve them with `GET /scan/{scan_id}`.

## Error behavior

* `422`: request validation failed, including a missing `X-API-Key` header or malformed request structure.
* `403`: the API key could not be validated.
* `502`: the upstream breach-data provider returned an error.


# Authentication
Source: https://docs.techslayers.ca/darkrecon/authentication

Authenticate to DarkRecon with an API key header.

# Authentication

All DarkRecon endpoints require an API key header.

## Header

* `X-API-Key: <your_api_key>`

<Note>
  Keep the API key server-side. DarkRecon is designed for backend or trusted service-to-service usage, not direct browser exposure.
</Note>

## Example

```bash theme={null}
curl -X GET "https://darkrecon.1337807.xyz/scan/YOUR_SCAN_ID" \
  -H "X-API-Key: $DARKRECON_API_KEY"
```

## Observed error behavior

* Missing `X-API-Key` currently returns `422` with a validation payload from the API framework.
* Invalid or revoked API keys return `403` with a standard error body.

Missing header example:

```json theme={null}
{
  "detail": [
    {
      "type": "missing",
      "loc": ["header", "x-api-key"],
      "msg": "Field required",
      "input": null
    }
  ]
}
```

Invalid key example:

```json theme={null}
{
  "detail": "Could not validate API key"
}
```

See `/platform/authentication` for broader TechSlayers platform guidance.


# Overview
Source: https://docs.techslayers.ca/darkrecon/overview

DarkRecon API for scanning keywords or domains for breach intelligence and retrieving stored results by scan ID.

# DarkRecon

DarkRecon is a stored-scan API for breach intelligence lookups. Send either a `keywords` array or a `domain`, receive a `scan_id`, and use that identifier to fetch the full stored result later.

<Warning>
  Older examples used `queries` in the request body. The current API expects `keywords`.
</Warning>

<Cards>
  <Card title="Quickstart" icon="rocket" href="/darkrecon/quickstart">
    Run a keyword or domain scan and fetch stored results.
  </Card>

  <Card title="Authentication" icon="key-round" href="/darkrecon/authentication">
    Use `X-API-Key` on every request.
  </Card>

  <Card title="API Reference" icon="braces" href="/darkrecon/api/start-scan">
    Endpoint-by-endpoint reference with interactive requests.
  </Card>
</Cards>

## Base URL

`https://darkrecon.1337807.xyz`

## What you can scan

* Email addresses
* Phone numbers
* Usernames and handles
* IP addresses
* Password strings or masked fragments
* Car plates / vehicle identifiers
* Social account IDs
* Composite search phrases
* Domains, which trigger email enumeration and follow-on scanning

## Authentication

DarkRecon uses an API key sent in the request header:

* `X-API-Key: <your_api_key>`

See `/darkrecon/authentication`.

## Request model

1. Submit `POST /scan` with either `keywords` or `domain`.
2. Read the synchronous response for `scan_id`, `status`, `total_breaches`, and optional `discovered_emails`.
3. Fetch the stored record with `GET /scan/{scan_id}`.
4. Parse the `results` object, which is keyed by breach database name rather than normalized into a fixed schema.

## Response model

* `total_breaches` counts matched breach sources, not the total number of raw rows inside `Data`.
* `results` is a dictionary keyed by breach database name.
* Each breach entry contains `InfoLeak`, `NumOfResults`, and `Data`.
* `Data` records are source-specific. Field names vary between breaches.
* Password-like fields are masked in API output.

## Related pages

* `/darkrecon/quickstart`
* `/darkrecon/api/start-scan`
* `/darkrecon/api/get-scan-results`


# Quickstart
Source: https://docs.techslayers.ca/darkrecon/quickstart

Start a DarkRecon scan with keywords or a domain and retrieve the stored results.

# Quickstart

This guide walks through the current DarkRecon flow: submit either `keywords` or `domain`, store the returned `scan_id`, and retrieve the raw stored result.

<Warning>
  Use `keywords` in the request body. Older docs used `queries`, which no longer matches the live API.
</Warning>

## 1) Set your API key

```bash theme={null}
export DARKRECON_BASE_URL="https://darkrecon.1337807.xyz"
export DARKRECON_API_KEY="YOUR_API_KEY"
```

## 2) Start a keyword scan

```bash theme={null}
curl -X POST "$DARKRECON_BASE_URL/scan" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $DARKRECON_API_KEY" \
  -d '{
    "keywords": ["john@example.com", "ShadowPlayer228"]
  }'
```

Example response:

```json theme={null}
{
  "scan_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "success",
  "total_breaches": 3
}
```

## 3) Start a domain scan

```bash theme={null}
curl -X POST "$DARKRECON_BASE_URL/scan" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $DARKRECON_API_KEY" \
  -d '{
    "domain": "example.com"
  }'
```

Domain scans can include `discovered_emails` in the initial response when the service enumerates breached addresses before running the follow-on scan.

## 4) Retrieve full scan results

```bash theme={null}
curl -X GET "$DARKRECON_BASE_URL/scan/YOUR_SCAN_ID" \
  -H "X-API-Key: $DARKRECON_API_KEY"
```

Example stored result:

```json theme={null}
{
  "scan_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "keywords": ["john@example.com"],
  "domain": null,
  "total_breaches": 3,
  "status": "success",
  "created_at": "2026-03-30T10:30:00+00:00",
  "results": {
    "AlpineReplay": {
      "InfoLeak": "Description of the breach...",
      "NumOfResults": 1,
      "Data": [
        {
          "Email": "john@example.com",
          "Password(bcrypt)": "$2****************************xC",
          "FirstName": "John",
          "LastName": "Doe"
        }
      ]
    }
  }
}
```

## 5) Parse the result safely

* `total_breaches` is the number of matched breach sources, not the total number of rows in all `Data` arrays.
* `results` is keyed by breach database name.
* Every source exposes `InfoLeak`, `NumOfResults`, and `Data`.
* Records inside `Data` are source-specific and can have different field names across breaches.
* Password-like values are masked in the API output.

## Next steps

* `/darkrecon/api/start-scan`
* `/darkrecon/api/get-scan-results`
* `/darkrecon/schemas/scan-request`
* `/darkrecon/schemas/scan-result`
* `/darkrecon/schemas/http-validation-error`


# Error
Source: https://docs.techslayers.ca/darkrecon/schemas/error

Standard DarkRecon error payload.

# Error

Returned on application-level failures such as invalid API keys, upstream provider errors, or missing scan IDs.

## Shape

```json theme={null}
{
  "detail": "Could not validate API key"
}
```

## Important distinction

Most application errors use the simple string-based `detail` shape above. Validation failures, including a missing `X-API-Key` header, use `HTTPValidationError` instead.


# HTTPValidationError
Source: https://docs.techslayers.ca/darkrecon/schemas/http-validation-error

Validation error envelope returned when DarkRecon rejects missing or malformed request input.

# HTTPValidationError

Returned when request validation fails before the application-level handler runs.

## Common cases

* Missing `X-API-Key`
* Invalid `scan_id` path input
* Malformed JSON or unexpected request structure

The `detail` array contains one or more `ValidationError` objects.


# ScanRequest
Source: https://docs.techslayers.ca/darkrecon/schemas/scan-request

Request body for starting a DarkRecon scan.

# ScanRequest

Input payload for `POST /scan`.

## Rules

* Send exactly one of `keywords` or `domain`.
* `keywords` replaces the older `queries` field from previous docs.
* `keywords` can include emails, phone numbers, usernames, IPs, passwords, car plates, social IDs, or composite search strings.

Keyword example:

```json theme={null}
{
  "keywords": ["user@example.com", "ShadowPlayer228"]
}
```

Domain example:

```json theme={null}
{
  "domain": "example.com"
}
```


# ScanResponse
Source: https://docs.techslayers.ca/darkrecon/schemas/scan-response

Initial response returned when a DarkRecon scan is created.

# ScanResponse

Contains the immediate acknowledgement returned by `POST /scan`.

## Key fields

* `scan_id`: store this UUID and use it with `GET /scan/{scan_id}`.
* `status`: `success`, `no_results`, or `no_queries`.
* `total_breaches`: number of matched breach sources, not raw rows.
* `discovered_emails`: optional, only for domain-driven scans that enumerate breached addresses.
* `message`: optional context when the request resolves without usable search terms.

This response does not contain the raw breach records. Use the stored `scan_id` to fetch the full result payload.


# ScanResult
Source: https://docs.techslayers.ca/darkrecon/schemas/scan-result

Stored full result payload returned by `GET /scan/{scan_id}`.

# ScanResult

Contains the stored record returned by `GET /scan/{scan_id}`.

## Top-level shape

* `keywords` or `domain` describes what was scanned.
* `status`, `total_breaches`, and `created_at` describe the stored scan record.
* `discovered_emails` appears on domain scans when emails were enumerated.
* `error_detail` is present if the scan ended in an error state.

## `results` object

* `results` is keyed by breach database name.
* Each entry contains:
  * `InfoLeak`: breach/source description.
  * `NumOfResults`: number of records found in that breach.
  * `Data`: array of raw breach records from that source.
* Fields inside `Data` vary by breach source. Do not assume a fixed normalized schema.
* Password-like values are masked in API output.


# ValidationError
Source: https://docs.techslayers.ca/darkrecon/schemas/validation-error

Individual validation issue object nested inside HTTPValidationError.detail.

# ValidationError

Each entry in `HTTPValidationError.detail` describes one validation failure.

## Key fields

* `loc`: where the validation issue happened, such as `["header", "x-api-key"]`
* `msg`: human-readable explanation
* `type`: machine-readable validation category
* `input`: offending value when the framework includes it


# Scan file
Source: https://docs.techslayers.ca/filescanner/api/scan-file

openapi/filescanner.json POST /api/scan
Scan a file for malware and return detection results.

# Scan file

Uploads a file to be scanned. The request is `multipart/form-data`.

## Form fields

* `file` (required): the file to scan
* `apikey` (optional): alternative to the `X-API-Key` header
* `devicename` (optional): alternative to the `X-Device-Name` header


# Authentication
Source: https://docs.techslayers.ca/filescanner/authentication

Optional API key and device headers for FileScanner.

# Authentication

FileScanner supports optional authentication headers.

## Headers

* `X-API-Key: <api_key>` (optional)
* `X-Device-Name: <device_name>` (optional)

Some clients may also pass these as multipart fields (`apikey`, `devicename`) instead of headers.

## Example

```bash theme={null}
curl -X POST "https://6465762e76312e7363616e.slayers.tech/api/scan" \
  -H "X-API-Key: $FILESCANNER_API_KEY" \
  -H "X-Device-Name: $FILESCANNER_DEVICE_NAME" \
  -F "file=@/path/to/file"
```


# Overview
Source: https://docs.techslayers.ca/filescanner/overview

FileScanner malware scanning API for files.

# FileScanner

FileScanner provides an API endpoint to scan a file for malware and return detection results, file hashes, and extracted
metadata.

<Cards>
  <Card title="Quickstart" icon="rocket" href="/filescanner/quickstart">
    Upload a file and interpret scan results.
  </Card>

  <Card title="Authentication" icon="key-round" href="/filescanner/authentication">
    Optional API key and device headers.
  </Card>

  <Card title="API Reference" icon="braces" href="/filescanner/api/scan-file">
    Full request/response schema for file scanning.
  </Card>
</Cards>

## Base URL

`https://6465762e76312e7363616e.slayers.tech`

## Endpoint

* Scan file: `POST /api/scan`


# Quickstart
Source: https://docs.techslayers.ca/filescanner/quickstart

Scan a file and read detections, metadata, and hashes.

# Quickstart

This guide shows how to upload a file to FileScanner and interpret the response.

## 1) Prepare your request

The API expects `multipart/form-data` with a `file` field.

If your deployment requires authentication, include:

* `X-API-Key: <api_key>`
* `X-Device-Name: <device_name>`

## 2) Upload and scan

```bash theme={null}
curl -X POST "https://6465762e76312e7363616e.slayers.tech/api/scan" \
  -H "X-API-Key: $FILESCANNER_API_KEY" \
  -H "X-Device-Name: $FILESCANNER_DEVICE_NAME" \
  -F "file=@/path/to/file"
```

## 3) Interpret the response

The response includes:

* `has_detections` and `num_detections`
* `detections`: list of `(engine, detection)` tuples
* `file_hash`: `md5_hash` and `sha256_hash`
* `metadata`: extracted details about the file

## Next steps

* `/filescanner/api/scan-file`
* `/filescanner/authentication`


# TechSlayers Docs
Source: https://docs.techslayers.ca/index

API references and integration guides for TechSlayers products.

# TechSlayers Docs

Central documentation for TechSlayers products: quickstarts, authentication patterns, and API references.

<Cards>
  <Card title="DarkRecon" icon="radar" href="/darkrecon/overview">
    Breach scanning workflows: scan emails/phones/domains and retrieve findings by scan UUID.
  </Card>

  <Card title="FileScanner" icon="file-search" href="/filescanner/overview">
    Malware scanning API for files with detection results, metadata, and hashes.
  </Card>

  <Card title="RTSWPScan" icon="scan-search" href="/rtswpscan/overview">
    WordPress scanning service: start a scan, then pull reports by ID.
  </Card>

  <Card title="RTS Builder" icon="blocks" href="/rts-builder/overview">
    Workflow-driven scan automation with external kit discovery, run status, and parsed results.
  </Card>

  <Card title="Senthrex" icon="siren" href="/senthrex/overview">
    Simulation scanning API: start scans, track status, and retrieve reports, logs, and JSON findings.
  </Card>

  <Card title="Legba" icon="shield" href="/legba/overview">
    Developer portal and API reference for browser isolation instances, images, keys, and logs.
  </Card>
</Cards>

## Authentication at a glance

| Product     | Base URL                                      | Auth                                          |
| ----------- | --------------------------------------------- | --------------------------------------------- |
| DarkRecon   | `https://darkrecon.1337807.xyz`               | API key header `X-API-Key`                    |
| FileScanner | `https://6465762e76312e7363616e.slayers.tech` | Optional headers `X-API-Key`, `X-Device-Name` |
| RTSWPScan   | `https://rtswpscan.slayers.tech`              | API key header `API-Key`                      |
| RTS Builder | `https://rts-builder.slayers.tech`            | API key header `X-API-Key`                    |
| Senthrex    | `https://rts-senthrex.slayers.tech`           | Bearer token header `Authorization: Bearer …` |
| Legba       | Provided in the Legba portal                  | Bearer token header `Authorization: Bearer …` |

## Platform docs

<Cards>
  <Card title="Authentication" icon="key-round" href="/platform/authentication">
    Where to put your keys/tokens and how auth differs across products.
  </Card>

  <Card title="Errors" icon="triangle-alert" href="/platform/errors">
    How to debug 4xx/5xx, interpret common responses, and implement retries safely.
  </Card>

  <Card title="Rate limits" icon="gauge" href="/platform/rate-limits">
    Backoff strategies and client patterns that keep your integrations reliable.
  </Card>
</Cards>

## Need help?

* Support: `support@techslayers.ca`
* Security: `security@techslayers.ca`


# API keys
Source: https://docs.techslayers.ca/legba/api-keys

Retrieve API key information and rotate keys.

# API keys

Legba supports retrieving key metadata and rotating keys.

<Warning>
  Rotating a key will invalidate the old key. Update any integrations immediately after rotation.
</Warning>

## Get API key information

```bash theme={null}
curl -X GET "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/key" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN"
```

## Rotate API key

```bash theme={null}
curl -X POST "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/key/rotate" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN"
```


# Authentication
Source: https://docs.techslayers.ca/legba/authentication

Authenticate to Legba with a bearer token and org-scoped routes.

# Authentication

Legba uses bearer token authentication.

## Header

* `Authorization: Bearer <token>`

## Org scoping

Most endpoints are scoped under your organization:

`/orgs/{org_uuid}/api/...`

## Example

```bash theme={null}
curl -X GET "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/instances" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN" \
  -H "Content-Type: application/json"
```


# Cookbook
Source: https://docs.techslayers.ca/legba/cookbook

Practical patterns for using Legba instances in real systems.

# Cookbook

## Use case 1: Automated testing environments

Create an isolated instance per test run, execute tests against the `access_url`, then destroy the instance.

```js theme={null}
const baseUrl = `${process.env.LEGBA_BASE_URL}/orgs/${process.env.LEGBA_ORG_UUID}/api`
const token = process.env.LEGBA_API_TOKEN

async function createInstance() {
  const response = await fetch(`${baseUrl}/instances`, {
    method: "POST",
    headers: { Authorization: `Bearer ${token}`, "Content-Type": "application/json" },
    body: JSON.stringify({ image: "ubuntu-22.04", size: "small" }),
  })
  return response.json()
}

async function destroyInstance(instanceUuid) {
  await fetch(`${baseUrl}/instances/${instanceUuid}`, {
    method: "DELETE",
    headers: { Authorization: `Bearer ${token}` },
  })
}
```

## Use case 2: On-demand secure browsing sessions

Map an app user/session to an `instance_uuid`, return `access_url` to the client, then clean up when the session ends.

## Use case 3: Instance pool management

Pre-warm a pool of instances for lower latency, track which are in use, and replenish when the pool drops below a
threshold.

## Best practices

* Always clean up instances (timeouts + periodic sweeps).
* Store API keys securely (server-side only, rotate regularly).
* Implement retries with backoff for transient errors.
* Monitor usage and audit logs (`/legba/logs`).


# Errors
Source: https://docs.techslayers.ca/legba/errors

Error formats and common HTTP status codes in the Legba API.

# Errors

The upstream docs describe a consistent error envelope:

```json theme={null}
{
  "error": {
    "code": "ERROR_CODE",
    "message": "Human-readable error description",
    "details": {}
  }
}
```

## Common HTTP status codes

| Status | Meaning               |
| ------ | --------------------- |
| `400`  | Bad request           |
| `401`  | Unauthorized          |
| `403`  | Forbidden             |
| `404`  | Not found             |
| `429`  | Too many requests     |
| `500`  | Internal server error |


# Images
Source: https://docs.techslayers.ca/legba/images

List available OS + browser images you can use for instances.

# Images

Images define the base OS and browser configuration used when creating an instance.

## List available images

```bash theme={null}
curl -X GET "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/images" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN" \
  -H "Content-Type: application/json"
```


# Instances
Source: https://docs.techslayers.ca/legba/instances

List, create, and destroy isolated browser instances.

# Instances

Instances are isolated environments created from images. Responses typically include:

* `instance_uuid`
* `status`
* `image`
* `size`
* `created_at`
* `access_url`

## List instances

```bash theme={null}
curl -X GET "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/instances" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN" \
  -H "Content-Type: application/json"
```

## Create instance

```bash theme={null}
curl -X POST "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/instances" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "image": "ubuntu-20.04",
    "size": "small"
  }'
```

## Destroy instance

```bash theme={null}
curl -X DELETE "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/instances/$INSTANCE_UUID" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN"
```

## Operational tips

* Always destroy instances you no longer need to avoid unnecessary resource usage.
* Store a mapping between your app sessions and `instance_uuid` for cleanup.


# Audit logs
Source: https://docs.techslayers.ca/legba/logs

Retrieve audit logs for API activity and operational visibility.

# Audit logs

Audit logs help you understand who/what performed actions (e.g., instance creation/destruction), when it happened, and
which resources were affected.

## Get audit logs

```bash theme={null}
curl -X GET "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/logs" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN"
```

## Typical log fields

* `timestamp`
* `action` (e.g., `instance.created`, `instance.destroyed`)
* `actor` (e.g., API key identity)
* `resource` (instance id)
* `details` (image, size)


# Overview
Source: https://docs.techslayers.ca/legba/overview

Legba developer docs for managing browser isolation images, instances, keys, and audit logs.

# Legba

Legba’s developer API is used to manage isolated browser instances (create, list, destroy), retrieve available images,
rotate API keys, and review audit logs.

<Note>
  This section is based on the official Legba developer portal at `https://www.legba.app/developers/api`. If anything
  differs from your environment, defer to the upstream docs.
</Note>

<Cards>
  <Card title="Quickstart" icon="rocket" href="/legba/quickstart">
    Create and destroy your first instance.
  </Card>

  <Card title="Authentication" icon="key-round" href="/legba/authentication">
    Bearer token auth and org scoping.
  </Card>

  <Card title="Instances" icon="monitor" href="/legba/instances">
    Create/list/destroy isolated instances.
  </Card>
</Cards>

## Key concepts

* **Organization UUID (`org_uuid`)**: scopes requests to your org.
* **Images**: templates (OS + browser) used to create instances.
* **Instances**: running isolated environments; responses include an `access_url` for end-user access.
* **Audit logs**: activity stream for API actions.


# Quickstart
Source: https://docs.techslayers.ca/legba/quickstart

Create an instance, list it, and destroy it using the Legba API.

# Quickstart

This guide mirrors the Legba developer portal flow: list images → create instance → list instances → destroy instance.

## Prerequisites

* A Legba account
* An API token
* Your `org_uuid`

<Note>
  The upstream docs use `https://api.example.com` as a placeholder. Replace it with your real Legba API base URL.
</Note>

## Environment variables (recommended)

```bash theme={null}
export LEGBA_BASE_URL="https://api.example.com"
export LEGBA_ORG_UUID="YOUR_ORG_UUID"
export LEGBA_API_TOKEN="YOUR_API_TOKEN"
```

## Step 1: List available images

```bash theme={null}
curl -X GET "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/images" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN" \
  -H "Content-Type: application/json"
```

## Step 2: Create an instance

```bash theme={null}
curl -X POST "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/instances" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "image": "ubuntu-20.04",
    "size": "small"
  }'
```

Save the returned `instance_uuid` and `access_url`.

## Step 3: List instances

```bash theme={null}
curl -X GET "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/instances" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN" \
  -H "Content-Type: application/json"
```

## Step 4: Destroy an instance

```bash theme={null}
curl -X DELETE "$LEGBA_BASE_URL/orgs/$LEGBA_ORG_UUID/api/instances/$INSTANCE_UUID" \
  -H "Authorization: Bearer $LEGBA_API_TOKEN"
```

## Next steps

* `/legba/instances`
* `/legba/images`
* `/legba/api-keys`
* `/legba/logs`


# Authentication
Source: https://docs.techslayers.ca/platform/authentication

How to authenticate across TechSlayers product APIs.

# Authentication

TechSlayers products use either API keys (sent as headers) or bearer tokens (sent via the `Authorization` header).

<Note>
  Never embed secrets in client-side code. Store them in your server environment (or a secret manager) and rotate them
  regularly.
</Note>

## Product auth matrix

| Product     | Type               | How to send                                                 |
| ----------- | ------------------ | ----------------------------------------------------------- |
| DarkRecon   | API key            | `X-API-Key: <key>`                                          |
| FileScanner | API key (optional) | `X-API-Key: <key>` and optionally `X-Device-Name: <device>` |
| RTSWPScan   | API key            | `API-Key: <key>`                                            |
| RTS Builder | API key            | `X-API-Key: <key>`                                          |
| Senthrex    | Bearer token       | `Authorization: Bearer <token>`                             |
| Legba       | Bearer token       | `Authorization: Bearer <token>`                             |

## Recommended client pattern

1. Keep the secret server-side only.
2. Add a thin wrapper per product that:
   * injects auth headers
   * sets a sensible timeout
   * logs request IDs (if present)
   * retries only when safe (see `/platform/rate-limits`)

## Examples

### DarkRecon (`X-API-Key`)

```bash theme={null}
curl -X GET "https://darkrecon.1337807.xyz/scan/YOUR_SCAN_ID" \
  -H "X-API-Key: $DARKRECON_API_KEY"
```

### Senthrex (`Authorization: Bearer`)

```bash theme={null}
curl -X GET "https://rts-senthrex.slayers.tech/scans" \
  -H "Authorization: Bearer $SENTHREX_TOKEN"
```


# Errors
Source: https://docs.techslayers.ca/platform/errors

Debugging and handling errors consistently across TechSlayers APIs.

# Errors

TechSlayers APIs return standard HTTP status codes. Your integration should treat status codes (and not just response
bodies) as the source of truth for success/failure.

## Common status codes

| Status | Meaning             | What to do                                                                           |
| ------ | ------------------- | ------------------------------------------------------------------------------------ |
| `400`  | Bad request         | Validate inputs; log the response for field-level hints.                             |
| `401`  | Unauthorized        | Check key/token formatting and that you’re using the right header name.              |
| `403`  | Forbidden           | Key is valid but lacks permission, or is invalid/disabled in some services.          |
| `404`  | Not found / pending | Some “report not ready yet” flows may use `404` as a pending signal (see RTSWPScan). |
| `422`  | Validation error    | Input shape is wrong (commonly used by FastAPI-based services).                      |
| `500`  | Server error        | Retry with backoff; escalate to support if persistent.                               |

## Practical debugging checklist

1. Confirm you are calling the correct base URL for the product.
2. Confirm auth:
   * correct header name (`X-API-Key` vs `API-Key` vs `Authorization: Bearer …`)
   * secret is not empty / not expired
3. Log:
   * request URL + method
   * response status code
   * response body (redact secrets)
4. Add timeouts and handle retries safely (see `/platform/rate-limits`).

<Note>
  If you need help debugging an unexpected response, email `support@techslayers.ca` with the request/response details
  (redacting any secrets).
</Note>


# Rate limits
Source: https://docs.techslayers.ca/platform/rate-limits

Safe retry patterns and backoff strategies for reliable integrations.

# Rate limits

Rate limits can vary by product and deployment. Build clients that are resilient even when limits are not explicitly
documented.

## Best practices

* Prefer exponential backoff with jitter for retries.
* Retry only when safe:
  * ✅ `GET` requests are usually safe
  * ⚠️ `POST` may not be safe unless the endpoint is idempotent (or you use a request ID)
* Treat `429` and `503` as retryable by default, using backoff.
* Put a cap on retries and fail fast for clearly invalid requests (`400`, `401`).

## Example backoff schedule

Try `1s → 2s → 4s → 8s` (plus small random jitter), then stop and surface an error.


# Get run results
Source: https://docs.techslayers.ca/rts-builder/api/get-results

openapi/rts-builder.json GET /api/v1/external/results/{runId}
Retrieve aggregate findings and per-step parsed results for a completed run.

# Get run results

## Top-level fields

* `aggregate`: Summary counters across the run
* `run_id`: Run UUID
* `status`: Terminal or in-progress run state
* `steps`: Per-tool parsed result payloads

## Aggregate fields

* `findings_by_severity`
* `risk_score`
* `total_findings`
* `unique_hosts`
* `unique_subdomains`

## Per-step fields

* `exit_code`
* `id`
* `status`
* `tool`
* `parsed_results`

`parsed_results` is tool-specific. In the `crt` runs tested for these docs, it contained:

* `tool`
* `type`
* `summary`
* `findings`

## Parser caveat

The current `crt` adapter did not fully clean its CLI output before building findings. Decorative table rows and one database recovery error line were surfaced as `finding.host` values during live testing. If you consume results programmatically, sanitize entries instead of assuming every `host` value is a valid hostname.

## Related schemas

* [RunResultsResponse](/rts-builder/schemas/run-results-response)
* [ErrorResponse](/rts-builder/schemas/error-response)


# Get run status
Source: https://docs.techslayers.ca/rts-builder/api/get-status

openapi/rts-builder.json GET /api/v1/external/status/{runId}
Fetch status, timestamps, and step state for a run ID.

# Get run status

## Status transitions

Observed values:

* `pending`
* `running`
* `completed`

Internal run pages also account for `failed` and `cancelled`, and callers should handle those states as well.

## Related schemas

* [RunStatusResponse](/rts-builder/schemas/run-status-response)
* [ErrorResponse](/rts-builder/schemas/error-response)


# List available kits
Source: https://docs.techslayers.ca/rts-builder/api/list-kits

openapi/rts-builder.json GET /api/v1/external/kits
Return the externally accessible kits for the calling API key.

# List available kits

## Notes

* The response always includes `kits` and `total`.
* A `200` with an empty `kits` array means the key authenticated successfully but has no externally visible kits.
* In live testing, this also occurred for a newly created team API key after a kit had been marked `exposed`, which suggests an additional access grant or backend entitlement step beyond simply toggling exposure.

## Method behavior

Observed method handling:

* `GET /api/v1/external/kits` returns `200`
* `HEAD /api/v1/external/kits` returns `404`
* `OPTIONS /api/v1/external/kits` returns `404`

## Related schemas

* [ListKitsResponse](/rts-builder/schemas/list-kits-response)
* [ErrorResponse](/rts-builder/schemas/error-response)


# Start run
Source: https://docs.techslayers.ca/rts-builder/api/start-run

openapi/rts-builder.json POST /api/v1/external/{kitSlug}
Start a new external RTS Builder run for an exposed kit slug.

# Start run

## Request body

The public contract expects an `inputs` object. The exact input names depend on the exposed kit's runtime variables.

## Success shape

<Warning>
  The external success payload could not be verified directly because the live environment rejected `POST /api/v1/external/{kit_slug}` for both:

  * the original user-provided key
  * a newly created team API key in the same tenant as an exposed kit
</Warning>

The schema rendered above is therefore based on the internally verified builder run-start payload and is labeled as inferred in the OpenAPI document.

## Related schemas

* [StartRunRequest](/rts-builder/schemas/start-run-request)
* [StartRunResponse (Inferred)](/rts-builder/schemas/start-run-response-inferred)
* [ErrorResponse](/rts-builder/schemas/error-response)


# Authentication
Source: https://docs.techslayers.ca/rts-builder/authentication

Authenticate RTS Builder external API calls with the X-API-Key header.

# Authentication

RTS Builder external endpoints authenticate with an API key in the `X-API-Key` header.

```bash theme={null}
curl "$RTS_BUILDER_BASE_URL/api/v1/external/kits" \
  -H "X-API-Key: your-api-key"
```

<Note>
  RTS Builder keys are tenant-scoped. A valid key from another team cannot read your run state or results.
</Note>

## Missing key

Observed response:

```http theme={null}
HTTP/2 401
```

```json theme={null}
{
  "error": "missing X-API-Key header"
}
```

## Invalid key

Observed response:

```http theme={null}
HTTP/2 401
```

```json theme={null}
{
  "error": "invalid API key"
}
```

## Tenant scoping

Run visibility is tenant-scoped. In live testing, a different team's API key received `404` with `{"error":"run not found"}` for both:

* `GET /api/v1/external/status/{run_id}`
* `GET /api/v1/external/results/{run_id}`

That means external run IDs are not globally readable just because the caller has a valid API key.


# Overview
Source: https://docs.techslayers.ca/rts-builder/overview

External API for running exposed RTS Builder kits and retrieving run state and results.

# RTS Builder

RTS Builder is a workflow-driven scanning platform. The external API is intentionally narrow:

1. List the kits your API key can see
2. Start a run for a specific exposed kit
3. Poll run status
4. Fetch structured results

<Cards>
  <Card title="Quickstart" icon="rocket" href="/rts-builder/quickstart">
    Follow the list, start, status, results workflow end to end.
  </Card>

  <Card title="Authentication" icon="key-round" href="/rts-builder/authentication">
    Send your API key in the `X-API-Key` header.
  </Card>

  <Card title="API Reference" icon="braces" href="/rts-builder/api/list-kits">
    Review the external endpoints with Mintlify's interactive request and schema rendering.
  </Card>
</Cards>

## Base URL

`https://rts-builder.slayers.tech`

## External workflow

1. Build or import a kit in RTS Builder
2. Expose the kit from the Kits page
3. Create an API key in Settings
4. Call `GET /api/v1/external/kits`
5. Start a run with `POST /api/v1/external/{kit_slug}`
6. Poll `GET /api/v1/external/status/{run_id}`
7. Read `GET /api/v1/external/results/{run_id}`

## Verification coverage

| Endpoint family                        | Live verified | Notes                                                   |
| -------------------------------------- | ------------- | ------------------------------------------------------- |
| `GET /api/v1/external/kits`            | Yes           | Only empty-list responses were observed.                |
| `POST /api/v1/external/{kitSlug}`      | Partial       | Error paths verified; success payload remains inferred. |
| `GET /api/v1/external/status/{runId}`  | Yes           | Verified across four completed runs.                    |
| `GET /api/v1/external/results/{runId}` | Yes           | Verified across four completed runs.                    |

<Warning>
  Live testing on March 28, 2026 Pacific / March 29, 2026 UTC confirmed that `status` and `results` work, but `kits` and `start` remained gated by an additional backend access check even for a same-tenant exposed kit.
</Warning>

## Live-tested behavior

The notes below were verified on March 28, 2026 Pacific / March 29, 2026 UTC.

* Missing `X-API-Key` returns `401` with `{"error":"missing X-API-Key header"}`.
* Invalid API keys return `401` with `{"error":"invalid API key"}`.
* `status` and `results` are tenant-scoped. A different team's API key receives `404` with `{"error":"run not found"}` for the same run ID.
* `status` and `results` worked successfully for completed runs.
* `list` and `start` showed an important access-control caveat in live testing:
  Even after exposing a kit and creating a fresh API key in the same team, `GET /api/v1/external/kits` still returned an empty array and `POST /api/v1/external/{kit_slug}` returned `{"error":"API key does not have access to this kit"}`.

## Result parsing caveat

Some tool adapters currently pass decorative CLI output through the structured findings parser. During live testing with a `crt`-based kit, box-drawing table rows were returned as findings alongside real hosts. Consumers should normalize results instead of assuming every `finding.host` value is a clean hostname.


# Quickstart
Source: https://docs.techslayers.ca/rts-builder/quickstart

Typical RTS Builder external API flow, plus the live-tested caveats you should account for today.

# Quickstart

## Authenticate

Every request uses the `X-API-Key` header:

```bash theme={null}
export RTS_BUILDER_API_KEY="your-api-key"
export RTS_BUILDER_BASE_URL="https://rts-builder.slayers.tech"
```

<Note>
  Keep the API key server-side. The key determines tenant scope for kit visibility and run access.
</Note>

## List accessible kits

```bash theme={null}
curl "$RTS_BUILDER_BASE_URL/api/v1/external/kits" \
  -H "X-API-Key: $RTS_BUILDER_API_KEY"
```

Example empty response:

```json theme={null}
{
  "kits": [],
  "total": 0
}
```

## Start a run

```bash theme={null}
curl -X POST \
  "$RTS_BUILDER_BASE_URL/api/v1/external/<kit-slug>" \
  -H "X-API-Key: $RTS_BUILDER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"inputs":{"target":"example.com"}}'
```

<Warning>
  External start success could not be completed with any tested key. Treat the example request as the intended contract and the success schema in the API reference as inferred until the access-control gap is fixed.
</Warning>

## Poll status

```bash theme={null}
curl "$RTS_BUILDER_BASE_URL/api/v1/external/status/<run_id>" \
  -H "X-API-Key: $RTS_BUILDER_API_KEY"
```

Example completed status:

```json theme={null}
{
  "error": "",
  "finished_at": "2026-03-29T02:33:41.139079Z",
  "run_id": "9bdeb4af-cab4-4de3-9f0f-758771d10991",
  "started_at": "2026-03-29T02:32:54.167691Z",
  "status": "completed",
  "steps": [
    {
      "id": "993af399-0e1a-456e-ba12-d465e7f9a5e6",
      "node_id": "tool-1",
      "tool": "crt",
      "status": "completed",
      "exit_code": 0
    }
  ]
}
```

## Fetch results

```bash theme={null}
curl "$RTS_BUILDER_BASE_URL/api/v1/external/results/<run_id>" \
  -H "X-API-Key: $RTS_BUILDER_API_KEY"
```

Top-level result shape:

```json theme={null}
{
  "aggregate": {
    "findings_by_severity": {
      "critical": 0,
      "high": 0,
      "info": 6,
      "low": 0,
      "medium": 0
    },
    "risk_score": 0,
    "total_findings": 6,
    "unique_hosts": 6,
    "unique_subdomains": 6
  },
  "run_id": "9bdeb4af-cab4-4de3-9f0f-758771d10991",
  "status": "completed",
  "steps": [
    {
      "exit_code": 0,
      "id": "993af399-0e1a-456e-ba12-d465e7f9a5e6",
      "status": "completed",
      "tool": "crt",
      "parsed_results": {
        "tool": "crt",
        "type": "ct_enumeration",
        "summary": {
          "total_subdomains": 6
        },
        "findings": []
      }
    }
  ]
}
```

## Live validation snapshot

These runs were started internally in RTS Builder and then retrieved through the external `status` and `results` endpoints on March 28, 2026 Pacific / March 29, 2026 UTC:

| Target                  | Final status | `total_findings` | `unique_subdomains` |
| ----------------------- | ------------ | ---------------: | ------------------: |
| `techslayers.ca`        | `completed`  |                6 |                   6 |
| `techslayers.com`       | `completed`  |               25 |                  25 |
| `beta.redteamsuite.com` | `completed`  |                3 |                   3 |
| `ameyalambat.com`       | `completed`  |                1 |                   1 |

## Important caveat

In live testing, the intended public flow was only partially available:

* External `status` and `results` worked for runs owned by the same tenant.
* External `list` and `start` did not automatically work with a newly created team API key, even after the kit was marked `exposed`.

Observed responses:

```json theme={null}
{
  "kits": [],
  "total": 0
}
```

```json theme={null}
{
  "error": "API key does not have access to this kit"
}
```

Treat this as a current access-control dependency: a valid key must be explicitly allowed to see the exposed kit, or the backend currently needs an additional grant step that is not exposed in the UI.


# ErrorResponse
Source: https://docs.techslayers.ca/rts-builder/schemas/error-response

Standard RTS Builder external API error envelope.

# ErrorResponse

Simple error body used across auth, lookup, and access-control failures.


# ListKitsResponse
Source: https://docs.techslayers.ca/rts-builder/schemas/list-kits-response

Response body for GET /api/v1/external/kits.

# ListKitsResponse

Observed authenticated shape for the kits listing endpoint.


# RunResultsResponse
Source: https://docs.techslayers.ca/rts-builder/schemas/run-results-response

Response body for GET /api/v1/external/results/{runId}.

# RunResultsResponse

Aggregate counters and tool-specific parsed result payloads.


# RunStatusResponse
Source: https://docs.techslayers.ca/rts-builder/schemas/run-status-response

Response body for GET /api/v1/external/status/{runId}.

# RunStatusResponse

Top-level run state plus per-step execution status.


# StartRunRequest
Source: https://docs.techslayers.ca/rts-builder/schemas/start-run-request

Request body for POST /api/v1/external/{kitSlug}.

# StartRunRequest

Input payload for starting a run. Variable names depend on the exposed kit.


# StartRunResponse (Inferred)
Source: https://docs.techslayers.ca/rts-builder/schemas/start-run-response-inferred

Inferred success payload for POST /api/v1/external/{kitSlug}.

# StartRunResponse (Inferred)

This schema is inferred from the internally verified builder run endpoint because the external start endpoint rejected same-tenant test keys during live testing.


# Get report
Source: https://docs.techslayers.ca/rtswpscan/api/get-report

openapi/rtswpscan.json GET /report/{report_id}
Retrieve a scan report by ID.

# Get report

Retrieves the report for a previously initiated scan.

## Pending reports

If the report is not ready, the API may return `404` with a `pending` status. Retry with backoff.


# Start scan (GET)
Source: https://docs.techslayers.ca/rtswpscan/api/start-scan-get

openapi/rtswpscan.json GET /scan
Initiate a scan using query parameters.

# Start scan (GET)

Initiates a scan using query parameters. Requires `url` and accepts an optional `mode`.


# Start scan (POST)
Source: https://docs.techslayers.ca/rtswpscan/api/start-scan-post

openapi/rtswpscan.json POST /scan
Initiate a scan using multipart form data.

# Start scan (POST)

Initiates a scan. Requires `url` and accepts an optional `mode`.

## Fields

* `url` (required): target URL to scan
* `mode` (optional): `normal` or `aggressive` (defaults to `normal` if omitted)


# Authentication
Source: https://docs.techslayers.ca/rtswpscan/authentication

Authenticate to RTSWPScan with an API key header.

# Authentication

All RTSWPScan endpoints require an API key header.

## Header

* `API-Key: <your_api_key>`

## Example

```bash theme={null}
curl -X GET "https://rtswpscan.slayers.tech/report/YOUR_REPORT_ID" \
  -H "API-Key: $RTSWPSCAN_API_KEY"
```


# Overview
Source: https://docs.techslayers.ca/rtswpscan/overview

RTSWPScan API for initiating WordPress scans and retrieving reports.

# RTSWPScan

RTSWPScan exposes a simple scan workflow: start a scan against a target URL, then retrieve the report by ID.

<Cards>
  <Card title="Quickstart" icon="rocket" href="/rtswpscan/quickstart">
    Start a scan and poll for the report.
  </Card>

  <Card title="Authentication" icon="key-round" href="/rtswpscan/authentication">
    Use the `API-Key` header.
  </Card>

  <Card title="API Reference" icon="braces" href="/rtswpscan/api/start-scan-post">
    Reference for starting scans and fetching reports.
  </Card>
</Cards>

## Base URL

`https://rtswpscan.slayers.tech`

## Typical workflow

1. Start a scan (`POST /scan` or `GET /scan`)
2. Use the returned `scan_id` as `report_id`
3. Fetch the report (`GET /report/{report_id}`), retrying until ready


# Quickstart
Source: https://docs.techslayers.ca/rtswpscan/quickstart

Start a scan and retrieve the resulting report.

# Quickstart

This guide shows the standard RTSWPScan lifecycle: initiate a scan, then fetch the report.

## 1) Set your API key

```bash theme={null}
export RTSWPSCAN_API_KEY="YOUR_API_KEY"
```

## 2) Start a scan (recommended: POST)

```bash theme={null}
curl -X POST "https://rtswpscan.slayers.tech/scan" \
  -H "API-Key: $RTSWPSCAN_API_KEY" \
  -F "url=https://example.com" \
  -F "mode=normal"
```

The response includes a `scan_id` you’ll use to retrieve the report.

## 3) Fetch the report

```bash theme={null}
curl -X GET "https://rtswpscan.slayers.tech/report/YOUR_SCAN_ID" \
  -H "API-Key: $RTSWPSCAN_API_KEY"
```

### Pending reports

If the report is not ready, the API may respond with `404` and a JSON body like:

```json theme={null}
{ "status": "pending" }
```

In that case, wait and retry with backoff.

## Next steps

* `/rtswpscan/api/start-scan-post`
* `/rtswpscan/api/get-report`


# Download report
Source: https://docs.techslayers.ca/senthrex/api/download-report

openapi/senthrex.json GET /report/{scan_uuid}
Download the report artifact for a scan UUID.

# Download report

Retrieves the generated report artifact for a scan UUID.


# Get scan logs
Source: https://docs.techslayers.ca/senthrex/api/get-logs

openapi/senthrex.json GET /logs/{scan_uuid}
Retrieve logs for a scan UUID.

# Get scan logs

Returns detailed log data including the log file path, full log content, and size metadata.


# Get scan results
Source: https://docs.techslayers.ca/senthrex/api/get-results

openapi/senthrex.json GET /results/{scan_uuid}
Retrieve structured JSON results for a scan UUID.

# Get scan results

Returns consolidated JSON findings for a scan, with optional filtering by scanner/tool type.

## Query parameters

* `tool` (optional): filter returned findings by scanner category


# Get raw scan JSON
Source: https://docs.techslayers.ca/senthrex/api/get-scan-json

openapi/senthrex.json GET /json/{scan_uuid}
Retrieve the raw consolidated JSON artifact for a scan UUID.

# Get raw scan JSON

Returns the raw stored JSON artifact for the scan (`mega.json`) exactly as generated by the backend.


# Get stats
Source: https://docs.techslayers.ca/senthrex/api/get-stats

openapi/senthrex.json GET /stats
Retrieve aggregate statistics.

# Get stats

Returns aggregated service metrics, including status breakdowns and disk usage totals.


# Get scan status
Source: https://docs.techslayers.ca/senthrex/api/get-status

openapi/senthrex.json GET /status/{scan_uuid}
Retrieve progress and current status for a scan UUID.

# Get scan status

Returns status fields like `status`, `progress_percentage`, `current_step`, and timestamps when available.


# List scans
Source: https://docs.techslayers.ca/senthrex/api/list-scans

openapi/senthrex.json GET /scans
List scans and summary counts.

# List scans

Returns an array of scans along with `total_scans` and `active_scans`.

## Query parameters

* `limit` (optional): max scans to return (default: `50`)
* `status_filter` (optional): filter scans by status


# Start scan (GET)
Source: https://docs.techslayers.ca/senthrex/api/start-scan-get

openapi/senthrex.json GET /scan
Start a scan by sending the domain (and optional mode) as query parameters.

# Start scan (GET)

Starts a new scan for the provided `domain` query parameter.

## Query parameters

* `domain` (required): the domain to scan
* `mode` (optional): `full` (default) or `discovery`


# Start scan (POST)
Source: https://docs.techslayers.ca/senthrex/api/start-scan-post

openapi/senthrex.json POST /scan
Start a scan by sending the domain (and optional mode) in a form-encoded body.

# Start scan (POST)

Starts a new scan for the provided `domain`.

## Body

`application/x-www-form-urlencoded`:

* `domain` (required): the domain to scan
* `mode` (optional): `full` (default) or `discovery`


# Stop scan
Source: https://docs.techslayers.ca/senthrex/api/stop-scan

openapi/senthrex.json POST /scan/{scan_uuid}/stop
Stop a running or pending scan by UUID.

# Stop scan

Stops a scan in progress and returns a message confirming the stop action.


# Authentication
Source: https://docs.techslayers.ca/senthrex/authentication

Authenticate to Senthrex with a bearer token.

# Authentication

Senthrex uses bearer-token authentication for scan operations.

## Header

* `Authorization: Bearer <token>`

## Example

```bash theme={null}
curl -X GET "https://rts-senthrex.slayers.tech/scans" \
  -H "Authorization: Bearer $SENTHREX_TOKEN"
```

The root endpoint (`GET /`) is a health/info endpoint and does not require authentication.


# Overview
Source: https://docs.techslayers.ca/senthrex/overview

Senthrex Simulation API for starting security scans, tracking progress, and retrieving results.

# Senthrex

Senthrex provides an authenticated security scan workflow:

1. Start a scan for a domain.
2. Track progress and status.
3. Retrieve reports, logs, and structured JSON results.
4. Stop scans when required.

<Cards>
  <Card title="Quickstart" icon="rocket" href="/senthrex/quickstart">
    Start a scan and check status end-to-end.
  </Card>

  <Card title="Authentication" icon="key-round" href="/senthrex/authentication">
    Bearer token authentication.
  </Card>

  <Card title="API Reference" icon="braces" href="/senthrex/api/start-scan-post">
    Endpoint reference with interactive requests.
  </Card>
</Cards>

## Base URL

`https://rts-senthrex.slayers.tech`

## Core resources

* Scan lifecycle:
  * Start scan: `POST /scan` (or `GET /scan`) with optional `mode` (`full` or `discovery`)
  * Status: `GET /status/{scan_uuid}`
  * Results JSON: `GET /results/{scan_uuid}`
  * Raw JSON artifact: `GET /json/{scan_uuid}`
  * Report: `GET /report/{scan_uuid}`
  * Logs: `GET /logs/{scan_uuid}`
  * Stop scan: `POST /scan/{scan_uuid}/stop`
* Fleet management:
  * List scans: `GET /scans`
  * Stats: `GET /stats`


# Quickstart
Source: https://docs.techslayers.ca/senthrex/quickstart

Start a Senthrex scan, monitor progress, and retrieve reports and JSON results.

# Quickstart

This guide shows the standard Senthrex workflow using the bearer token and the scan UUID returned from `/scan`.

## 1) Set your bearer token

```bash theme={null}
export SENTHREX_TOKEN="YOUR_BEARER_TOKEN"
```

## 2) Start a scan (recommended: POST)

```bash theme={null}
curl -X POST "https://rts-senthrex.slayers.tech/scan" \
  -H "Authorization: Bearer $SENTHREX_TOKEN" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "domain=example.com" \
  --data-urlencode "mode=full"
```

`mode` is optional and defaults to `full`. Use `discovery` for a lighter scan profile.

The response includes a `uuid` (scan UUID). Use it as `scan_uuid` in all follow-up requests.

## 3) Check scan status

```bash theme={null}
curl -X GET "https://rts-senthrex.slayers.tech/status/YOUR_SCAN_UUID" \
  -H "Authorization: Bearer $SENTHREX_TOKEN"
```

## 4) Retrieve outputs

### Structured results

```bash theme={null}
curl -X GET "https://rts-senthrex.slayers.tech/results/YOUR_SCAN_UUID" \
  -H "Authorization: Bearer $SENTHREX_TOKEN"
```

### Logs

```bash theme={null}
curl -X GET "https://rts-senthrex.slayers.tech/logs/YOUR_SCAN_UUID" \
  -H "Authorization: Bearer $SENTHREX_TOKEN"
```

### Report archive

```bash theme={null}
curl -X GET "https://rts-senthrex.slayers.tech/report/YOUR_SCAN_UUID" \
  -H "Authorization: Bearer $SENTHREX_TOKEN"
```

### Raw JSON artifact

```bash theme={null}
curl -X GET "https://rts-senthrex.slayers.tech/json/YOUR_SCAN_UUID" \
  -H "Authorization: Bearer $SENTHREX_TOKEN"
```

## 5) Stop a running scan (optional)

```bash theme={null}
curl -X POST "https://rts-senthrex.slayers.tech/scan/YOUR_SCAN_UUID/stop" \
  -H "Authorization: Bearer $SENTHREX_TOKEN"
```

## Next steps

* `/senthrex/api/start-scan-post`
* `/senthrex/api/get-status`
* `/senthrex/api/get-results`
* `/senthrex/api/get-scan-json`
* `/senthrex/api/list-scans`