Plexara
Webhooks
Sources
Any system that sends webhooks
Most of the software a business runs can call out when something happens. The usual receiving end is a listener somebody wrote, hosted, and has to keep alive. On Plexara, an admin on your team creates a webhook source in the portal and gives its address to the sending system. That is the whole integration.
Each source is its own address with its own proof of who the sender is, so one system’s events never mix with another’s, and turning a source off silences only that sender. A Media & Broadcasting client replaced a pipeline listener for its CRM with a webhook source this way.
Sender
What arrives
A CRM
A contact is created, merged, or changes owner, and the change is a row to act on.
A point of sale
Every sale and every return, from every store, as it is rung up.
An email platform
Sends, opens, bounces, and unsubscribes, each tied to the address it concerns.
An events or ticketing tool
Registrations, check-ins, and cancellations as they come in.
Another Plexara deployment
One deployment’s automation delivers into another’s webhook source, signed, and arrives as a table.
Verification
Every sender is verified
An address that accepts data is an address someone can send bad data to. Each source decides who may post to it, and everything it refuses is accounted for.
01
Every source checks its own sender
A source accepts the kind of proof its sending system can produce: a signature over each request, a shared token, or a username and password. The secret is held encrypted by the platform and never shown again after it is saved.
02
A sender that fails the check is turned away
Nothing from a request that fails verification is stored. The refusal is recorded with its reason, so a forged request or a misconfigured sender shows up on the Webhooks page instead of in your data.
03
A replayed request is refused
Senders that stamp each request with the time it was sent are held to it. A captured request sent again later fails even with a valid signature.
04
Secrets rotate without dropping an event
An admin sets a new secret and a period during which the old one is still accepted. The sender moves to the new secret inside that period, and no request in between is refused.
From event to outcome
Stored before it is acknowledged, a table from then on
The receiving side does not wait for anything to read it. Events are verified, kept, and queryable whether one automation reads them every minute, a report reads yesterday’s once a night, or an analyst asks a question next month.
- 1
The sender posts the event
A sale is rung up, a contact changes, an email bounces. The sending system posts it to the source’s address, one event at a time or in batches.
- 2
Plexara verifies the sender
The request is checked against the source’s proof before anything else happens. A request that fails is refused and recorded.
- 3
The event is stored, then acknowledged
The sender is told the event was received only after it is stored. An event that was acknowledged is never lost, and a sender that hears nothing sends again. Duplicates from a sender’s retries are removed from what the source keeps.
- 4
It is a row in the source’s table
Each source is one table, and each event is one row with the time it arrived, its type, what it is about, and the full payload. It is queryable as soon as the event is acknowledged, and it joins the warehouse like any other table.
- 5
An automation turns it into an outcome
An automation reads what is new and acts on it: a warehouse row, a CRM update, a dashboard that stays current, or an alert through Notifications.
On the ACME demo
A point-of-sale feed, end to end
The ACME demo deployment has a webhook source named pos-sales. Every five minutes an automation delivers a batch of simulated sales from the real ACME stores and product catalog to it, the way a point-of-sale system would. Each sale lands as one row in webhook_pos_sales, and a second automation keeps a live sales dashboard current from that table.
A sale happens, the event arrives, the table has the row, and the dashboard has the number. The figures below were read from the demo deployment.
288 deliveries
In the last 24 hours, one every five minutes, every one accepted
9,073 sales
Arrived in those 24 hours, 346 of them returns
303 stores
Every ACME store is in the feed, joined to the warehouse store list by store id
59,077 events
In the table since the source was created on October 1
One sale, one row
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
trino_query
sql SELECT received_at, landed_at, event_type, key, payload
FROM webhook_pos_sales
WHERE event_type = 'sale.completed'
ORDER BY received_at DESC
LIMIT 1
-> received_at 2026-10-07 20:35:07.310 UTC
landed_at 2026-10-07 20:35:08.315 UTC
event_type sale.completed
key 31
payload {"store_name": "ACME Store #31", "store_city": "Manchester",
"store_state": "CA", "payment_method": "Cash",
"items": [ 4 lines ], "subtotal": 554.16, "tax": 45.72,
"total_amount": 599.88}Lesson 607, Events in, builds this feed step by step: creating the source, how a sender proves itself, the table, and an automation that reads only what is new so it neither misses nor double-counts a sale. Lesson 608, Results out, sends what such an automation finds back out, signed, to people and to other systems.
Outcomes
What automations do with events
The table is where an event starts. Your agent writes an automation that reads it, you approve what the automation does in plain language, and Plexara runs it with no agent in the loop.
Warehouse rows
Events are shaped and loaded into warehouse tables on a schedule, so reporting reads them like any other fact table.
CRM and system updates
A change in one system is written to another: a bounced address marked in the CRM, a cancellation closing a record.
Dashboards that stay current
A dashboard’s numbers are refreshed from the source’s table on a schedule, with no live database connection behind the page.
Alerts
An automation that sees something worth a person’s attention posts it to a Mattermost channel, an email list, or another system.
Admin > Webhooks
Every source on one screen
Your admins watch every source from the Webhooks page in the portal’s Admin section: request volume over the last hour or the last day, each source’s health and when it last received an event, and every rejected request with its reason. A request body is never kept on a rejection.
Receiving
Events arrived in the last 24 hours and everything received is being kept.
Silent
Nothing arrived in the last 24 hours. A sender that stops raises no error anywhere, so this is how a stopped sender shows.
Failing
Events arrived, but some have not yet been written into the files the source keeps. The newest error is shown beside the source, and the platform keeps retrying.
Disabled
An admin turned the source off, and it accepts nothing until it is turned back on.
Common questions
Webhooks FAQ
Any system that can send a webhook: a CRM, a point of sale, an email platform, an events or ticketing tool, an internal service, or another Plexara deployment. An admin on your team creates a source for it in the portal under Admin > Webhooks and gives the sending system the address the source shows.
Each source checks the proof its sender can produce: a signature over every request, a shared token, or a username and password. A request that fails the check is refused, nothing from it is stored, and the refusal appears on the Webhooks page with its reason. Secrets are rotated with an overlap, so the sender moves to the new one without a refused request.
As soon as it is acknowledged. The sender is told an event was received only after it is stored, and from then it is a row in the source’s table, queryable with SQL and joinable to the warehouse like any other table.
Learn more: Lesson 607: Events inAn automation your agent writes and you approve. It reads what is new in the source’s table on a schedule and loads the warehouse, updates another system, refreshes a dashboard, or posts an alert, with no agent in the loop.
Learn more: Automations
What reads the events
Automations
Your agent writes the scheduled automation that reads the events, you approve what it does in plain language, and Plexara runs it with no agent in the loop.