One endpoint for every outcome we have not packaged.
Most businesses have at least one conversion no packaged integration knows about: a quote accepted in an internal CRM, a contract signed, a booking taken by phone and typed in by hand. POST it to /v1/events and it behaves exactly like an order from Stripe.
In short: The custom event API accepts any server-side outcome — a lead, a booking, an order, a subscription change, a refund — as a named event with a value, a pseudonymous customer key and an idempotency key.
What it is
The custom event API is Reveliqo's server-side endpoint for business events: an authenticated POST carrying an event name, the site, a pseudonymous customer key, a timestamp, a value, a currency and free-form properties. The commerce integrations land on the same endpoint.
What this lets you ask
- “Which channel produces leads that become signed contracts?”
- “What did that phone booking cost us to acquire?”
- “Which content precedes our highest-value custom conversions?”
What Reveliqo receives
- POST /v1/events with event, site_id, customer_id, occurred_at, value, currency and properties
- The recommended names — lead.created, trial.started, account.created, order.completed, subscription.started, subscription.upgraded, subscription.cancelled, refund.created, appointment.booked
- occurred_at in UTC, so an event queued for six hours still lands in the period it happened in rather than the period it was delivered
- Properties as typed key–value pairs, which become filterable dimensions instead of text buried in a payload
How it is connected
- Create a server-side API key in the workspace — it is never exposed to a browser
- Send the pseudonymous customer key from the visit, so the outcome joins the acquisition path instead of standing alone
- Set an Idempotency-Key header on every event that carries value or counts as a conversion
- Register the event name once, and decide there whether its value is treated as revenue
How you verify it
- The endpoint returns the stored event, stating whether this delivery created it or matched an existing idempotency key
- The event appears in Live within seconds, with the visit it joined to
- Sending the same payload and key again returns the first result and leaves every total unchanged
Limits worth knowing
- Without an idempotency key a retry is a second sale. Queues redeliver, a webhook retries after a timeout that had already succeeded, a replayed batch sends the same orders twice — each adds revenue that never existed, and nobody notices until finance disagrees with the dashboard. The key makes the duplicate a no-op.
- An event without a customer key is still stored with its full value and timestamp; it simply has no visit in front of it, so any report cut by channel or content leaves it out rather than placing it.
- Reveliqo stores what you send. It can check that a payload is well formed and not a duplicate; it cannot check that the number is right, so an amount in cents rather than units is reported faithfully and wrongly.
Other integrations
Connect the rest of the stack
Connect a site today. Read tomorrow's brief instead of building it.
Connect a site and the first brief arrives with the day's changes already explained — traffic separated from bots, conversions attached to revenue, and the evidence behind every sentence one click away.
Real people separated from bots Every answer shows its evidence Reveliqo runs on Reveliqo