Ingest clients

An ingest client represents one sender or one controlled group of senders. It answers four questions:

1. Which data models may this sender write?
2. Which transport does it use?
3. How does it prove its identity?
4. Which networks may it send from?

Create a client#

Open Access → Ingest Clients → New ingest client.

Enter a name and description, choose the allowed models, configure protocol-specific settings, then review the effective policy before saving.

Use a name tied to the real workload, such as production-web-app or branch-router-syslog, rather than a generic name such as client-1.

Allowed models#

The allowed-model list is an authorization boundary. A valid credential cannot write to a model outside this set.

When a Syslog client uses routing rules, every destination model referenced by a rule must come from the client's allowed set.

Enabled state#

Disabling a client blocks runtime use without deleting its configuration. This is useful during incident response or planned migration.

Detail and edit pages#

The detail page shows:

• effective endpoint or listener information;
• allowed models;
• authentication configuration without exposing stored secrets;
• CIDR policy;
• recent usage and source information;
• discovery state for supported Syslog clients.

Editing a client keeps its generated Syslog endpoint identity stable. Ordinary edits do not create a new internal endpoint host or IPv6 identity.

Delete versus disable#

Prefer disable when you may need to inspect or restore configuration. Delete only after confirming that no application or device still uses the client.