---
description: Index the Report URI audit trail directly into Elasticsearch using HTTP Basic authentication in the webhook URL.
---

# Elasticsearch

Elasticsearch accepts HTTP Basic authentication, and credentials supplied in a URL are converted into a Basic `Authorization` header automatically. That makes Elasticsearch one of the few log platforms reachable **directly**, with no relay in between.

!!! warning "The credentials are stored, and they are visible"

    We record the target of every webhook delivery attempt in your account's audit trail, which means a URL containing a username and password is written there in full - and the audit trail is itself streamed to whatever endpoint you configure. Anyone with access to your Report URI audit trail can read these credentials.

    Use a dedicated user with the `create` privilege on a single index and nothing else, as described below. Never use a superuser or an account that can read your other data.

## Creating a limited user

Writing documents needs one of the `create_doc`, `create`, `index` or `write` index privileges. **`create` on one index is enough**, and is the least you can grant.

Create a role with that privilege scoped to the index you want the events in, and a user assigned only that role. If the credentials leak - and the caveat above means you should assume they might - the blast radius is the ability to add documents to one index.

## Building the URL

Elasticsearch indexes a document with `POST /<index>/_doc/`. Put the credentials in the userinfo portion:

    https://ruri-writer:PASSWORD@your-deployment.es.eu-west-1.aws.found.io:9243/report-uri-audit/_doc/

Our POST body becomes the document. The audit trail payload is flat, with a `timestamp` field already in ISO 8601, so it maps onto an index template without transformation.

## Sending the audit trail to it

Paste that URL into the Audit Trail webhook field - **Account Settings** for a personal account, or the **Teams** page for a team. See [Audit Trail](/security-operations/audit-trail/) for the payload reference.

## Things to watch for

- **Your cluster has to be reachable from the internet.** A deployment behind a VPN or restricted to an IP allow-list will never receive an event, and the failure looks like silence. If you allow-list, you will need to permit our egress addresses.
- **A password with `@`, `/` or `:` in it must be percent-encoded**, or the URL parses wrongly and the request goes somewhere unintended.
- Create the index, or an index template that matches its name, before you start. Dynamic mapping will otherwise infer field types from whichever event happens to arrive first.
- Rotating the password means updating the webhook URL. There is nothing that will tell you it has expired except alerts quietly stopping.
- Elastic Cloud deployments use port 9243. Include it.

## If you would rather not put credentials in a URL

The alternative is the same one Splunk needs: a small relay that receives our POST, adds an `Authorization` header, and forwards it. That keeps the credential out of the URL entirely, at the cost of hosting something. See [Splunk](/security-operations/splunk/) for the pattern - it applies unchanged to Elasticsearch with an API key.

## Official documentation

[Elastic - Index API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-index_.html)

## Start Monitoring with Report URI

**Already using us?** Create the limited user, build the URL, and paste it into the Audit Trail webhook field.

**New to Report URI?** The Audit Trail webhook is available on Business and Enterprise plans.

[Start your free trial](https://report-uri.com/register/?plan=starter2025)