Real time

Answers inside the request. Reactions when it matters.

Ask about any user, account, device or order and get the answer back in the same call. Or let Aggrelis watch the events and tell your systems when something happens, or when something stops happening.

Request accessRead the docs
Three ways

Ask, get it with the event, or be told

Pick one per use case, or mix them. All three read the same running totals, so the numbers agree wherever they show up.

  1. 1
    Ask on demand

    Your service asks a question about a user, account or device inside its own request, and the answer comes straight back.

    Good for
    Sign-insCheckoutsPaymentsAPI calls
  2. 2
    Answer with the event

    Send the event as usual. A trigger asks the question for you, and the answer comes back in the response to that event.

    Good for
    Orders as they are placedSubmissionsReadings
  3. 3
    Push to your systems

    Results go to a stream you read at your own pace, or arrive as signed webhooks in the tools you already run.

    Good for
    AlertingReview queuesCase managementAnalytics

Need an outcome, not just the facts? Let Aggrelis decide

Questions

Everything you want to know, in one call

A question bundles the metrics you care about, values worked out from them, and your conditions, each true or false. Ask it about any user, account, device or order and get it all back at once.

  • Metrics, derived values and conditions in one answer, written once and shared by every team
  • Pass what the request knows: the card, the device, the API key, the store, and values such as the amount being paid
  • Give each question a time budget, and choose: answer with what is ready, or refuse
  • Ask as things stood at an earlier time, to look back at a past decision
  • Ask and count the event in the same call
What you can measure
Illustrative
usage_checkA question about an account
Metrics
  • callsThisMinuteAPI calls, rolling 1 minute
  • callsThisMonthAPI calls, this calendar monthaccount's time zone
  • keyCallsThisMinuteCalls by the request's API key, rolling 1 minutewith the request
Derived
  • quotaUsedPctcallsThisMonth ÷ the plan's monthly quota
Conditions
  • near_monthly_quotaquota used ≥ 90%
  • key_rate_limitedkey calls this minute > 600
Time budget
DefaultYour own, 1 ms to 1 s
If something is missing
Answer with what is readyRefuse
The answer

Missing values are never zero

Every answer says what it knows, what it could not compute, and why. A condition that depends on a missing value is left undecided, not quietly false, so no guess reaches your decision.

  • Values: every metric and derived value that could be computed
  • Reasons: the conditions that hold, in the order you wrote them
  • Skipped: what could not be computed for this request, each with a reason
  • The versions that answered, to log with your decision
For developers
POST /v1/entities/{type}/{id}/profiles/{name}:evaluate
curl -s -X POST \
  "$P/entities/account/acme/profiles/usage_check:evaluate" \
  -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' \
  -d '{"context":{"api_key":"key_42"}}'
From the engine's API, where a question is called a profile and a condition a reason.
Triggers

Reacts without being asked

A trigger asks a question for you whenever a certain event arrives, and sends the answer where you want it. It also notices when nothing arrives at all.

  • Fire on a type of event, or only when a condition holds: orders above 1,000, readings out of range
  • Check before the event counts, to see the history alone, or after, to include it
  • Absence triggers fire when the next event does not come, from 1 minute to 30 days: a device went quiet, a cart was never checked out
  • Send the result back in the response to the event, to the result stream, or both
  • Never in the way: a trigger that fails is skipped, and never rejects the event or fails the request
Webhooks and the result stream

Results delivered to the tools you run

Push results into the tools you run, signed to the Standard Webhooks spec. Or read them from your workspace's result stream, at your own pace.

  • Signed deliveries that any Standard Webhooks library can verify
  • Retried when your side fails, from 30 seconds doubling up to 6 hours, and delivered at least once
  • Rotate the signing secret with an overlap of up to 7 days, or revoke a leaked one at once
  • Every attempt logged; send a test ping, or retry any delivery once you have fixed your side
  • Or read the result stream by cursor, with long-polling and a filter per question
Receiving webhooks, in the docs
Explain

Ask why, of any answer

Explain answers the same question and shows how it got there: what each value was read from, which versions answered and where the time went. Analysts can trust a number, and support can answer “why did this happen?”.

  • What each value read, and over which window
  • The versions of the question and of each running total
  • The time each phase of the answer took
  • During a rollout, what the next version would answer
  • The same “Why?” in the workspace, next to any answer
See the workspace
Illustrative
Why this answer?
usage_check@v3config 12
ValueRead fromVersion
callsThisMinute412calls per account, rolling 1 minutev2
callsThisMonth1,180,340calls per account, calendar monthv2
keyCallsThisMinute37calls per API key key_42, rolling 1 minutev1
near_monthly_quotaholds: quotaUsedPct 94 ≥ 90
Where the time went
Reading totalsDerivedConditions
Rollout in progressThe pending version of calls per account answers the same values.
What you can count on

The promises behind every answer

What holds for every question you ask and every result Aggrelis sends.

  • Each event counts once

    Resend an event, say after a timeout, and it is recognised as a duplicate instead of counted twice.

  • Exact

    Amounts and decimals are kept exactly, never as floating point. Money stays right to the cent.

  • Never guesses

    Missing values are listed with a reason, and conditions that depend on them stay undecided.

  • Explainable

    Every answer names its versions, and explain shows what it read.

  • Bounded

    Every question has a time budget. What is not ready in time is reported, not waited for.

  • Never in the way

    A trigger that fails is skipped. It never rejects your event or fails your request.

  • Signed

    Webhooks follow Standard Webhooks; verify them with any of its libraries.

  • Delivered at least once

    Failed deliveries are retried and logged, and you can retry any of them yourself.

Get started

Put live answers inside your product

Request access to a workspace, or read the docs to see the API first.

Request accessRead the docs