AWRA OpsHub Search
Security · SIEM

Your audit log, streamed to your SIEM within a minute, in order.

Point AWRA at an HTTPS endpoint and every audit event your organization records is sent there in sequence: as signed JSON, to a Splunk HTTP Event Collector, or to Datadog Logs. Each event carries its place in the hash chain, so your security team can see a missing or reordered entry from their own side.

Start free Open one event

JSON over HTTPS (HMAC-signed) · Splunk HEC · Datadog Logs · Every minute · Retries with backoff · Token stored encrypted

Every minutenew events go out in batches of up to 500, up to four batches a run, oldest first
Cursor on 2xxthe stream moves past a batch only when your endpoint answers with success
Hash chaineach event carries chain_sequence, previous_hash and row_hash
Public HTTPS onlyprivate addresses, plain HTTP and redirects are refused, at save and again at send
Why stream it

An audit log you can only read inside the system it audits is half a control.

Your security team already watches one place: the SIEM where your identity provider, firewall and cloud logs land. If the record of who approved a bill, changed a role or exported a report lives only in AWRA, it is out of their sight, outside their alert rules and outside their retention.

Streaming puts a second copy where they work, as it happens. And because the AWRA audit log is a hash chain, the copy carries its own proof of order: a sequence number on every event and the hash of the one before it. An event that never arrived shows up as a gap your SIEM can search for.

One event, opened

What lands in your SIEM when someone approves a supplier bill.

event 48211format: json · one of a batch
1{
2 "id": 48211,
3 "tenant_id": 1207,
4 "occurred_at": "2026-10-27T09:14:06+03:00",
5 "actor_id": 37,
6 "actor_type": "user",
7 "actor_name": "Amina Wanjiru",
8 "actor_email": "[email protected]",
9 "action": "approve",
10 "module": "Supplier Bills",
11 "route_name": "supplier_bills.approve",
12 "method": "POST",
13 "ip_address": "197.232.61.18",
14 "subject_type": "Supplier Bills",
15 "subject_id": "1042",
16 "description": "Approve Supplier Bills (ID 1042)",
17 "metadata": { "params": { "supplierBill": 1042 } },
18 "chain_sequence": 48211,
19 "previous_hash": "ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb",
20 "row_hash": "3e23e8160039594a33894f6564e1b1348bbd7a0088d42c4acb73eeaed59c009d"
21}

Who, from where

The person, their email, whether they were staff or a supplier on the vendor portal, and the IP address the request came from.

What, on which record

The action, the module, the route and method, and the record it touched — enough to build an alert on action = approve in one module, or on any export.

Where it sits in the chain

chain_sequence is its position in your organization’s log. previous_hash must equal the row_hash of the event before it. A skipped number or a hash that does not match is something your SIEM can find without asking us.

Stable id for de-duplication

id never changes. If a batch is resent after a timeout, the repeated events carry the same id and the same sequence, so they collapse cleanly.

chain_sequence48210

previous_hash18ac3e73…34f4f8e4

row_hashca978112…afee48bb

chain_sequence48211

previous_hashca978112…afee48bb

row_hash3e23e816…d59c009d

chain_sequence48212

previous_hash3e23e816…d59c009d

row_hash2e7d2c03…a25aefc6

Consecutive numbers and matching links are the check your side can run. The seal itself — recomputing a row_hash from an event’s content — uses a key that stays with AWRA, and runs from the audit log’s own verifier. How the chain works.

Pick a destination

Three formats, one per organization, chosen in Settings.

Settings → Audit Log Streaming takes a format, an HTTPS endpoint and a token. The same events go out in each; only the envelope and the header that authenticates them change.

POST https://siem.example.com/ingest/awra
Authorization: Bearer ••••••••
X-Awra-Signature: sha256=5d1f…e07a
Content-Type: application/json

{ "events": [ { "id": 48211, … }, { "id": 48212, … } ] }
BodyOne JSON object, an events array
Authenticates withYour secret as a Bearer token
SignatureHMAC-SHA256 of the body, keyed with the same secret
When your endpoint is down

Nothing is skipped. The stream waits, then picks up where it stopped.

A cursor that only moves on success

The stream remembers the last event your endpoint accepted. Each minute it sends what comes after, in order. A batch that fails — a timeout, a 4xx or a 5xx — leaves the cursor where it was, so the same events go again on the next attempt. If your side accepted a batch but the answer never reached us, you see those events twice with the same ids.

48205
48206
48207
48208
48209
48210
48211
48212
delivered waiting · counted on the settings page

Retries that back off, to an hour

After a failure the next attempt waits longer each time, and resets to every minute after the first success. The settings page shows the last error your endpoint gave and when the next try is due.

  • 1st failure1 min
  • 2nd2 min
  • 3rd4 min
  • 4th8 min
  • 5th16 min
  • 6th32 min
  • 7th onward60 min
Controls around the stream

A pipe out of your audit log is itself something to audit.

Token write-only

The HEC token, API key or shared secret is stored encrypted and never shown again. Leave it blank on an edit and the stored one is kept.

Public HTTPS, no redirects

An endpoint on a private, loopback or cloud-metadata address is refused when you save it, and checked again at every send against the address actually resolved. Redirects are not followed.

Two permissions

Viewing settings shows the stream’s status. Changing the destination or sending a test event needs the edit-settings permission.

The change is logged

Turning streaming on or off, or pointing it somewhere new, writes its own audit event naming the destination host and format — which then streams like any other.

Test before you trust it

Send one synthetic event from the settings page and see straight away whether your endpoint accepted it, or the status it answered with.

From now, or from the start

A new destination can begin with today’s events, or receive the whole existing log first. Turning streaming off and on again resumes from the cursor.

The straight answer

What AWRA OpsHub does today

  • Three destination formats — signed JSON over HTTPS, Splunk HTTP Event Collector and Datadog Logs — chosen per organization in Settings → Audit Log Streaming.
  • Every event in the audit log streamed in order, with who, what, which record, the IP address and the event’s hash-chain fields.
  • A run every minute, sending batches of up to 500 events and up to four batches per run, so a backlog drains on its own.
  • A cursor that moves only on a 2xx, so a failed batch is resent rather than lost, with a stable id on every event for de-duplication.
  • Backoff on failure from one minute to an hour, with the last error and the next attempt shown on the settings page.
  • An HMAC-SHA256 signature on every JSON batch, keyed with your shared secret, alongside the Bearer token.
  • The token stored encrypted and write-only, never displayed after it is saved.
  • Endpoint checks at save and at send — public HTTPS only, the resolved address pinned, redirects refused.
  • A test event from the settings page, and a count of events waiting to send.
  • Start from now or replay the whole log when a destination is first set up.
  • Stream status over the API — format, host, on or off, last delivery, last error and backlog — for a read-only view outside the web settings.

More we can add to your workspace

  • More than one destination per organization, for example a SIEM and a long-term archive receiving the same events.
  • Filters on what streams, by module or by action, so a destination receives only sign-ins or only approvals.
  • Syslog and CEF output, for collectors that take those rather than HTTPS.
  • Native envelopes for other platforms, such as Microsoft Sentinel or Elastic, beyond the generic JSON format they can already ingest.
  • An alert when a destination keeps failing, by email or in the notification bell, rather than on the settings page alone.
  • A per-batch delivery history listing each send, its size and the status your endpoint returned.

Where we point you to a specialist

  • We will not send the key that seals the chain. Your SIEM can check sequence and links between events; recomputing each seal stays with the verifier on the audit log, so a copy of the stream can never be used to forge a matching one.
  • We will not stream to plain HTTP or to a private address. The audit log carries names, emails and IP addresses, and the endpoint checks are what keep it from being sent somewhere it should not go.

A second destination and filters on what streams are the two items in that middle column asked about most by security teams. Tell us which platform you run and what you want it to receive, and we will come back with a written spec, a timeline and a price.

Around the stream

Where the audit log comes from, and what else watches it.

Audit trail integrityThe hash chain every streamed event carries, and the verifier that checks the seals. Security operationsSign-in controls, sessions and the security centre the audit log records. Compliance evidence packsThe audit trail and controls packaged for an auditor’s request. API and webhook automationBusiness events sent to your systems, alongside the audit stream. Device trustWhich devices may sign in, and the events that produces. AI and data controlsWhere your data may go for AI features, and the log of what was used.

Frequently asked questions

Which SIEMs and log platforms does audit log streaming support?
Three formats: Splunk HTTP Event Collector, Datadog Logs, and JSON over HTTPS. The JSON format posts a batch of events to any HTTPS endpoint that accepts a POST, signed with an HMAC-SHA256 of the body and authenticated with a Bearer token, so any platform or collector that takes JSON over HTTPS can receive it.
How quickly do events arrive?
The stream runs every minute. Each run sends new events in batches of up to 500, up to four batches, oldest first. In normal running an event reaches your endpoint within about a minute of being recorded; a large backlog drains over the following runs.
What happens when our endpoint is down?
The batch fails and the stream stays where it was. The next attempt waits one minute, then two, four, eight and so on up to an hour between tries, and drops back to every minute after the first success. Nothing is skipped: the cursor moves only when your endpoint answers with a 2xx. The settings page shows the last error and when the next try is due.
Can the same event arrive twice?
Yes, rarely. If your endpoint accepted a batch but the success response never reached us, the batch is sent again. Every event carries a stable id and chain_sequence, so de-duplicate on either.
What does the hash chain let our SIEM check?
Each event carries chain_sequence, its position in your organization’s audit log, previous_hash and row_hash. Consecutive sequence numbers, and each previous_hash matching the row_hash before it, show nothing was dropped or reordered between AWRA and your SIEM. Recomputing a row_hash from the event’s content uses a key that stays with AWRA; that check runs from the verifier on the audit log page.
How is our token stored?
Encrypted at rest, and write-only: it is never shown again after you save it, and leaving the field blank when you edit the stream keeps the stored one. For Splunk it is the HEC token, for Datadog the API key, and for JSON a shared secret used both as the Bearer token and to sign each batch.
Do we have to send the whole history?
No. When you first set up a destination you choose whether it starts from now or receives the existing audit log first. Turning streaming off and back on later resumes from where it stopped, so the events recorded in between are sent.
Who can turn streaming on?
Anyone whose role holds the edit-settings permission can set the destination, change the token and send a test event. Viewing settings is enough to see the status. Each change is itself written to the audit log, naming the destination host and the format.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center

Further reading

More on security & compliance

Guides

All security & compliance articles →

Definitions

  • Value Added Tax A consumption tax charged on sales and reclaimable on qualifying purchases.
  • Withholding Tax Tax deducted at source from a payment and remitted on the payee’s behalf.
  • eTIMS Kenya’s electronic tax invoice management system for real-time invoice transmission.
  • E-Invoicing Issuing invoices in a structured electronic format, often validated by the tax authority.
Operations glossary →