# HTTP Sink Configuration Guide

The Generic HTTP Receiver is a Sink provider for sending events to any HTTP endpoint. Use it to integrate with log aggregators, SIEM platforms, custom webhooks, data lakes, or any system that accepts event data over HTTP.

## Before You Begin

To configure this integration you need:

- An HTTP or HTTPS endpoint that accepts event data
- Any credentials required by the endpoint (API key, OAuth client credentials, or username and password)
- If using payload signing, an HMAC-SHA256 shared secret agreed upon with the receiving endpoint


## Authorization

The HTTP Sink supports three authorization methods. Choose the method that matches your receiving endpoint's requirements. If the endpoint does not require authorization (for example, an internal service on a private network), you can skip this section entirely.

Token Authorization
Token authorization covers API keys, bearer tokens, and custom token schemes. By default, the token is sent in the `Authorization` header as a Bearer token. You can customize both the header name and the value format.

**Credential**: Provide the token value as a Token Secret.

**Header Name (Optional)**: The HTTP header name used to send the token. Defaults to `Authorization`.

**Header Value Template (Optional)**: A template for building the header value. Use `{{token}}` as a placeholder for the secret token value — it is substituted at runtime. Defaults to `Bearer {{token}}`.

Common configurations:

| Use Case | Header Name | Template | Resulting Header |
|  --- | --- | --- | --- |
| Bearer token (default) | `Authorization` | `Bearer {{token}}` | `Authorization: Bearer eyJhbG...` |
| API key in custom header | `X-API-Key` | `{{token}}` | `X-API-Key: abc123` |
| Custom token scheme | `Authorization` | `ApiKey {{token}}` | `Authorization: ApiKey abc123` |


The template must contain the `{{token}}` placeholder. Do not put secrets directly in the template — use the placeholder and supply the secret as the Token credential.

OAuth 2.0 Client Credentials
OAuth 2.0 client credentials flow (RFC 6749) for service-to-service authentication. The connector automatically fetches and refreshes access tokens from the OAuth token endpoint.

**Client ID**: The OAuth client identifier issued by the authorization server.

**Client Secret**: The OAuth client secret issued by the authorization server.

**Token URL**: The authorization server's token endpoint (for example, `https://auth.example.com/oauth2/token`). This field is required.

**Scopes (Optional)**: OAuth 2.0 scopes to request when fetching the access token. Provide as a list of strings (for example, `events.write`, `https://api.example.com/.default`).

**Endpoint Parameters (Optional)**: Additional parameters to include in the token request. Some OAuth providers require extra parameters such as `resource` or `audience`.

**Auth Style (Optional)**: How client credentials are sent to the token endpoint. Defaults to `in_header`.

- `in_header` — Sends credentials via HTTP Basic authentication. This is the recommended and most secure method, used by most modern OAuth 2.0 providers.
- `in_params` — Sends credentials URL-encoded in the request body. Required by some legacy OAuth servers. Consult your OAuth provider's documentation if `in_header` does not work.


Basic Authorization
Standard HTTP Basic authentication (RFC 7617). Credentials are sent in the `Authorization` header as Base64-encoded `username:password`.

**Username**: The username for the receiving endpoint.

**Password**: The password for the receiving endpoint.

No Authorization
If the receiving endpoint does not require authorization, leave the Authorization field empty. This is appropriate for endpoints on private networks or endpoints that authenticate by other means (for example, IP allowlisting or mutual TLS).

## Payload Signing

Payload signing is independent of authorization and can be combined with any authorization method (or no authorization) for defense-in-depth security. When enabled, the connector computes an HMAC-SHA256 signature over the request body and includes it in the `X-Synqly-Signature` header.

**Signing Secret**: A shared secret key used to compute the HMAC-SHA256 signature. Both the sender (Synqly) and the receiving endpoint must know this secret.

The signature header has the format:


```
X-Synqly-Signature: sha256={hex_signature}
```

The receiving endpoint can verify payload integrity by computing the same HMAC-SHA256 over the raw request body using the shared secret and comparing it to the signature in the header.

Payload signing lets the receiving endpoint confirm that the request body has not been tampered with and that it originated from a sender that knows the shared secret. This is especially useful for webhook-style integrations where the endpoint is publicly accessible.

## Configure the Integration

Create your integration by supplying the following values.

| Integration Parameter | Required | Description |
|  --- | --- | --- |
| **URL** | Yes | The receiving endpoint where events will be sent. Must use `http://` or `https://` scheme. The full URL is used as-is, including any path, query parameters, or non-standard ports (for example, `https://logs.example.com/api/v1/events`). |
| **Authorization** | No | Authorization configuration for the receiving endpoint. Choose one of the methods described in the [Authorization](#authorization) section above. Leave empty if the endpoint does not require authorization. |
| **Payload Signing** | No | HMAC-SHA256 signing secret for payload integrity verification. See the [Payload Signing](#payload-signing) section above. Can be combined with any authorization method. |
| **Static Headers** | No | Additional HTTP headers to include on every request. Use for non-sensitive metadata such as source system identifiers, API versioning, or custom routing headers (for example, `X-Source: synqly`, `X-API-Version: 2`). |
| **Request Body Format** | No | Format for serializing events in the request body. `jsonl` (default) sends each event as a separate JSON object on its own line (newline-delimited JSON). `json_array` wraps all events in a standard JSON array. Choose based on what the receiving endpoint expects. |
| **HTTP Method** | No | HTTP method for sending events. Defaults to `POST`. Supported values: `POST`, `PUT`, `PATCH`, `GET`. |
| **Skip TLS Verification** | No | Disables TLS certificate verification. Defaults to `false`. |
| **Accepted Response Codes** | No | HTTP status codes that indicate successful delivery. Defaults to `[200, 201, 202, 204]`. Configure if the receiving endpoint uses non-standard success codes (for example, `207 Multi-Status`). |
| **Request Timeout** | No | Maximum time in seconds to wait for the receiving endpoint to respond. Defaults to 0 (no explicit timeout — the request is still bounded by the service-level deadline of approximately 295 seconds). Must be a positive value no greater than 295 seconds; values outside that range are rejected. The timeout covers the full round-trip including dial, TLS handshake, and reading the response headers. |


**Skip TLS Verification** disables security checks and makes connections vulnerable to man-in-the-middle attacks. Only enable this for development or testing environments. Never use it in production with sensitive data.

**Static Headers** are for non-sensitive metadata only. Do not use them to pass secrets — use the Authorization configuration for credentials.