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

# HTTP Request & Standalone Components

> Configure REST endpoints, dynamic authentication, path parameters, and unified request headers.

The **HTTP Request** node is the foundational building block for invoking microservice APIs, external webhooks, and third-party SaaS endpoints on the Quixa canvas.

***

## 1. Node Types & Creation

Quixa provides two ways to work with HTTP requests:

* **Collection-Bound Endpoints**: Dragged directly from your imported OpenAPI/Swagger specifications in the left sidebar. Retains schema definitions and validation contracts.
* **Standalone HTTP Request (`[ ⚡ qComponent ]`)**: Placed from the component palette. Operates independently without requiring a parent OpenAPI specification.

Both node types support the **Swagger UI color standard**:

* `GET`: `#61affe` (Blue)
* `POST`: `#49cc90` (Green)
* `PUT`: `#fca130` (Orange)
* `DELETE`: `#f93e3e` (Red)
* `PATCH`: `#50e3c2` (Teal)

***

## 2. Unified Request Bar

Double-clicking any HTTP node opens the configuration dialog featuring a **Unified Top Request Bar** that remains persistent across all tab views:

1. **HTTP Method Selector**: Switch between GET, POST, PUT, DELETE, PATCH, OPTIONS, and HEAD.
2. **Endpoint URL Input**: Supports dynamic variables and path parameter syntax (e.g. `https://api.acme.com/v1/users/{userId}`).
3. **Save & Test Actions**: Save node settings or perform immediate test execution to verify credentials.

***

## 3. Path Parameters & Bidirectional Auto-Sync

When configuring URLs with path placeholders:

* Typing `{petId}` into the URL input automatically creates a corresponding row in the **Params** tab with `Location = path`.
* Renaming or removing the placeholder updates the URL and params table bidirectionally without manual coordination.
* The backend execution engine substitutes `{petId}` at runtime using mapped variables or predecessor bindings:

```text theme={null}
https://api.store.com/v2/orders/{{CreateOrder.response.body.orderId}}/status
```

***

## 4. Comprehensive Authorization Engine

Standalone HTTP nodes feature an inline **Authorization Form** supporting modern enterprise auth standards:

| Auth Scheme | Configuration Options | Runtime Support |
| :- | :- | :- |
| **No Auth** | Public endpoint access | Full |
| **Bearer Token** | JWT / Access Token string, dynamic `{{bindings}}` | Full |
| **API Key** | Key name, value, and placement (`Header`, `Query`, `Cookie`) | Full |
| **Basic Auth** | Username & Password (auto Base64-encoded) | Full |
| **OAuth 2.0** | Authorization Code, Client Credentials, Implicit, Password | Full |
| **OpenID Connect** | Issuer discovery, token verification | Full |
| **Cookie Auth** | Cookie name-value pairs injected into request headers | Full |
| **AWS Signature V4** | Access Key, Secret Key, Region, Service | Configurable |
| **NTLM & Digest** | Enterprise Windows challenge-response | Configurable |

***

## 5. Body Payloads & Dynamic Template Bindings

The **Body** tab supports:

* `JSON`: Syntax-highlighted Monaco editor with dynamic variable completion.
* `x-www-form-urlencoded`: Form key-value editor.
* `multipart/form-data`: File upload attachments and binary buffers.
* `Raw / Text`: Plain text or XML payloads.

Dynamic variable bindings are evaluated at runtime using mustache syntax:

```json theme={null}
{
  "orderId": "{{OrderStep.response.body.id}}",
  "customerEmail": "{{env.TEST_USER_EMAIL}}",
  "timestamp": "{{$isoTimestamp}}"
}
```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.