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

# API Overview

> Integrate LexQ policy execution into your application via REST API.

## Base URLs

LexQ exposes two separate APIs with different base URLs:

| API                | Base URL                               | Purpose                                         |
| ------------------ | -------------------------------------- | ----------------------------------------------- |
| **Management API** | `https://api.lexq.io/api/v1/partners`  | Policy lifecycle (create, test, deploy)         |
| **Execution API**  | `https://api.lexq.io/api/v1/execution` | Runtime policy evaluation (your app calls this) |

<Warning>
  Do not mix the two base URLs. Management endpoints return 404 on the Execution base URL and vice versa.
</Warning>

## Authentication

LexQ uses **API Key** authentication. Include your key in every request:

```bash theme={null}
x-api-key: YOUR_API_KEY
```

API keys are created and managed in the Console under **Management → API Keys**.

<Warning>
  API keys grant full access to your organization's policy engine. Never expose them in client-side code or public repositories.
</Warning>

## Request Format

All request and response bodies use JSON. Set the `Content-Type` header:

```
Content-Type: application/json
```

## Response Format

Every response follows a consistent envelope:

<CodeGroup>
  ```json Success theme={null}
  {
    "result": "SUCCESS",
    "data": { ... },
    "message": null
  }
  ```

  ```json Error theme={null}
  {
    "result": "ERROR",
    "data": null,
    "code": "P-001",
    "message": "Policy group not found."
  }
  ```
</CodeGroup>

<Warning>
  The top-level field is `result` (value: `"SUCCESS"` or `"ERROR"`), **not** `success: true/false`. Always check `result === "SUCCESS"` in your integration code.
</Warning>

## Error Codes

Error codes follow a prefix convention:

| Prefix    | Domain                                               |
| --------- | ---------------------------------------------------- |
| `C-xxx`   | Common (input validation, not found, rate limit)     |
| `A-xxx`   | Auth (credentials, API key, sessions)                |
| `P-xxx`   | Policy Engine (groups, versions, rules, deployments) |
| `I-xxx`   | Idempotency                                          |
| `S-xxx`   | System / Crypto                                      |
| `B-xxx`   | Billing (subscription, payment, quota)               |
| `M-xxx`   | Member & Account                                     |
| `AN-xxx`  | Analytics & Simulation                               |
| `ACT-xxx` | Action validation (discount, point, notification)    |
| `FD-xxx`  | Fact Definition                                      |
| `INT-xxx` | Integration                                          |
| `FL-xxx`  | Failure Log                                          |
| `WH-xxx`  | Webhook Subscription                                 |

See the [full error reference](/api/errors) for details.

## Rate Limits

Rate limits apply **per organization** (across all API keys for the same tenant), based on your plan's **Max TPS** setting:

| Plan       | Max TPS |
| ---------- | ------- |
| Free       | 10      |
| Growth     | 100     |
| Pro        | 500     |
| Enterprise | Custom  |

Throttling uses a strict per-second window: the counter resets every epoch second. Requests exceeding the TPS limit in that second receive HTTP `429 Too Many Requests` with code `C-007`.

For execution endpoints, [batch and composite calls](/api/execution#batch-execution) count as a single request against TPS, regardless of how many fact sets they contain. This makes batching the most direct way to handle burst traffic without upgrading.

<Tip>
  Issuing additional API keys does not raise your effective TPS — keys share the same per-tenant bucket. Upgrade your plan to raise the limit, or batch your calls to fit more work into each request.
</Tip>

## Idempotency

For execution endpoints, you can include an `Idempotency-Key` header to prevent duplicate processing:

```bash theme={null}
Idempotency-Key: unique-request-id-123
```

Duplicate requests with the same key return the original response without re-executing the policy.

## Pagination

List endpoints return paginated results:

```json theme={null}
{
  "result": "SUCCESS",
  "data": {
    "content": [ ... ],
    "totalElements": 42,
    "totalPages": 3,
    "pageNo": 0,
    "pageSize": 20
  }
}
```

Use `pageNo` (0-indexed) and `pageSize` query parameters to navigate pages.

## Next Steps

<CardGroup cols={2}>
  <Card title="Authentication" icon="key" href="/api/authentication">
    API key management and security best practices.
  </Card>

  <Card title="Policy Execution" icon="bolt" href="/api/execution">
    Execute policies against live traffic.
  </Card>
</CardGroup>