--- title: "Axiom Integration" description: "Axiom is an event and log analytics platform. Agents ingest events, run APL queries, manage datasets, monitors, notifiers, and views, and drop annotations on deploys so incidents line up with changes." url: https://flowrunner.ai/integrations/axiom date_modified: 2026-09-04T14:59:52-07:00 --- # Axiom [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Axiom is an event and log analytics platform. Agents ingest events, run APL queries, manage datasets, monitors, notifiers, and views, and drop annotations on deploys so incidents line up with changes. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 70 actions · API key · available [Axiom website](https://axiom.co/) · [Platform Documentation](https://axiom.co/docs) · Capability data verified 2026-08-25 1. A production deploy finishes in the pipeline 2. Create Annotation marks the moment on the affected dataset's charts, so a later shape change has a cause attached to it 3. Run Query asks an APL question about error rate and latency in the window since the marker 4. The same query is run against the equivalent window before the deploy, and the two results are compared 5. The comparison posts to the engineering channel with the annotation and the query behind it 6. Update Annotation adds an end time once the rollout completes, turning the marker into a band covering the whole change 7. When the numbers point at a virtual field misreporting rather than a real regression, a person approves any edit to that field's expression before it is made ## What This Integration Enables Axiom is built for teams that treat their events as a dataset they can question rather than a stream they grep. Run Query takes an APL string and returns a table, so a workflow asks a real analytical question of production data instead of pulling rows out and filtering them itself. Ingest Events puts a flow's own facts into that same store, which means the decisions an agent makes and the outcomes it produces become queryable next to the systems they touched. The connector goes further than most observability integrations, and that is what makes it interesting for orchestration rather than for dashboards. It covers the parts of Axiom that decide what the record says and who can read it: datasets and their retention, monitors and the notifiers they alert through, views that expose a filtered slice of a dataset as its own access boundary, virtual fields that compute columns at query time, and the tokens, roles, and groups behind all of it. FlowRunner [connectors](https://flowrunner.ai/concepts/connectors) are built and verified against each vendor's official API, so an agent can maintain that surface directly. It can also damage it directly, which is why the operations that change what history says wait for a person. ### Without FlowRunner **Graphs without causes**: A chart changes shape and the team reconstructs what shipped that afternoon from memory and merge history **Monitors that alert nobody**: A monitor exists, runs on schedule, records its state, and reaches no channel because its notifier was changed or removed underneath it **Retention decided blind**: Log volume gets trimmed to control cost with no view of what the trim removes until somebody needs it ### With FlowRunner **Every deploy on the timeline**: An annotation lands at the moment of each release and becomes a band across the rollout, so causes sit next to effects **Alerting paths audited**: The link from monitor to notifier to channel is checked as a routine, and a monitor with no way to reach anyone is reported as a fault **Deletions with evidence attached**: A query shows exactly what a retention change or a trim would remove, in counts and dates, before anyone approves it ## Use Case Scenarios ### Deploys that explain their own graphs A deploy completes in [GitLab](https://flowrunner.ai/integrations/gitlab) or ships through [Netlify](https://flowrunner.ai/integrations/netlify). The agent calls Create Annotation on the service's dataset with the commit range and the release name, then waits out the bake period and calls Run Query for error rate, p95 latency, and throughput across the window. It runs the same query against the previous day's equivalent window and posts the pair to [Slack](https://flowrunner.ai/integrations/slack). Once the rollout finishes, Update Annotation adds the end time so the marker becomes a band. Six weeks later, when somebody asks what changed on that Tuesday, the answer is on the chart. ### An alerting path that gets audited instead of assumed Once a week the agent calls List Monitors and List Notifiers and reconciles them. A monitor created without notifier ids runs, records its state, and alerts nobody, so it is reported as a fault rather than counted as coverage. A notifier that several monitors share is checked against the channel it claims to reach, since changing one notifier silently redirects every monitor using it. Anything that has lost its only channel is escalated through [PagerDuty](https://flowrunner.ai/integrations/pagerduty), and the resulting picture of what is actually watched is written up next to the dashboards in [Grafana](https://flowrunner.ai/integrations/grafana). ### Access reviews that read the real permissions For a quarterly review the agent calls List API Tokens and reads each token's capabilities rather than its name, List Users with their roles, and List Groups with the roles attached to them. Tokens that grant more than the job they were created for, users whose role reaches datasets they no longer work on, and roles with no members are collected into a single report. The agent proposes narrower access using Create View over a filtered slice rather than broader roles, and stops there. Role and group updates replace the whole list they are sent, so a partial write silently revokes what it left out, which makes those the changes a person makes with the evidence in front of them. ## Human-in-Loop Highlight A virtual field on Axiom is a computed column evaluated at query time, which is what makes it the fix for a field you cannot re ingest: a unit conversion, a parsed status code, a derived flag applied to data that already landed. It is also the one operation on this connector that edits the past. Change a virtual field's expression and every historical query result changes with it, because nothing was stored, everything is computed on read. The incident review from March, the monitor history someone cited, the number in last quarter's report: all of them now return something else, and nothing anywhere records that they moved. An agent doing log hygiene will find good reasons to touch these. So it does not. It builds the case instead, running the old expression and the proposed one over the same window through Run Query, showing which rows change and by how much, listing every monitor and saved query that references the field, and asking the service owner: "This expression is misparsing a status code. Correcting it changes what 90 days of queries return, including the two monitors listed below. Correct it, or add a new virtual field and leave the old one in place?" The second option usually wins, and it only exists because a person was asked. Automation that auditors approve is automation that cannot quietly rewrite the record it is being audited against. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 70 actions ### Ingest 1 - **Ingest Events** Sends events into a dataset. It is a bulk endpoint that takes an array, so a flow batches its events rather than posting one per call. ### Query 1 - **Run Query** Runs an APL query and returns a table. The operation this API exists for, because it lets a flow ask a real question of its event data instead of fetching rows and filtering them itself. ### Datasets 14 - **List Datasets** Returns the organization's datasets with their retention and kind. - **Get Dataset** Returns one dataset, addressed by its id. - **Create Dataset** Creates a dataset. Its kind cannot be changed afterwards and decides how Axiom interprets what arrives, so it is a decision made once. - **Update Dataset** Changes a dataset's description or retention. Lowering retention deletes data older than the new period and that deletion is not recoverable. - **Delete Dataset** Removes a dataset and everything in it. Irreversible, and anything ingesting into it starts failing. - **Trim Dataset** Deletes everything in a dataset older than a duration. The one off version of changing retention, and equally irreversible. - **Vacuum Dataset** Reclaims storage a dataset is no longer using. A maintenance operation rather than a routine one; it does not change what queries return. - **List Dataset Fields** Returns a dataset's columns with their types and units. Field names come from what was ingested, so this is how a flow learns what an APL query can reference. - **Get Dataset Field** Returns one field's type, unit, and description. - **Update Dataset Field** Sets a field's description, unit, or hidden flag. The unit is what makes a chart read in milliseconds rather than in bare numbers. - **List Map Fields** Returns the fields Axiom stores as maps rather than flattening into columns. - **Create Map Field** Marks a field to be stored as a map. The fix for a dataset that has grown thousands of columns from an unmapped high cardinality object. - **Update Map Fields** Sets a dataset's whole map field list. It replaces rather than appends, so a field left out stops being a map for future data. - **Delete Map Field** Stops a field being stored as a map. ### Monitors 6 - **List Monitors** Returns the organization's monitors and whether each is disabled. - **Get Monitor** Returns one monitor with its query and thresholds. - **Get Monitor History** Returns a monitor's past checks and the alerts they raised. Where a noisy or a silent monitor explains itself, because it shows what the query actually returned each run. - **Create Monitor** Creates a monitor that runs an APL query on a schedule and alerts through its notifiers. Without notifier ids it runs, records its state, and alerts nobody. - **Update Monitor** Changes a monitor. It replaces the record rather than patching it, so unsent fields are lost unless the monitor is read first. - **Delete Monitor** Removes a monitor. Setting a disabled window through an update is the reversible way to silence one for planned work. ### Notifiers 5 - **List Notifiers** Returns the organization's notifiers, which are the channels monitors alert through. - **Get Notifier** Returns one notifier's configuration. - **Create Notifier** Creates an alerting channel for monitors to use. Its properties carry exactly one channel, keyed by its name. - **Update Notifier** Changes a notifier's name or channel configuration. Every monitor using it is affected, so pointing one at a different channel silently redirects all of them. - **Delete Notifier** Removes a notifier. Monitors referencing it lose that channel, and one whose only notifier this was becomes silent without reporting anything. ### Views 5 - **List Views** Returns the organization's views, which are saved APL queries that behave like datasets. - **Get View** Returns one view. - **Create View** Saves an APL query as a view, which can then be queried and granted access to like a dataset. The access control tool on this API, because a view over a filtered slice is narrower than a role. - **Update View** Changes a view's query or description. Widening the query widens access for everyone whose permissions run through it. - **Delete View** Removes a view. Anything whose access ran through it loses that access, and queries naming it start failing. ### Virtual fields 5 - **List Virtual Fields** Returns the organization's virtual fields, which are computed columns evaluated at query time. - **Get Virtual Field** Returns one virtual field. - **Create Virtual Field** Adds a computed column to a dataset, evaluated at query time. The way to fix a field that cannot be re ingested. - **Update Virtual Field** Changes a virtual field's expression or metadata. Because the column is computed on read, changing the expression changes what every past query returns, which is why this page's human gate sits here. - **Delete Virtual Field** Removes a virtual field. Queries, monitors, and dashboards referencing it start failing. ### Saved queries 5 - **List Saved Queries** Returns the organization's saved APL queries. - **Get Saved Query** Returns one saved query. - **Create Saved Query** Saves an APL query under a name, so a query several flows depend on lives in Axiom rather than duplicated across them. - **Update Saved Query** Changes a saved query. Every flow and dashboard running it follows the change. - **Delete Saved Query** Removes a saved query. ### Annotations 5 - **List Annotations** Returns the annotations that appear as markers on charts. - **Get Annotation** Returns one annotation. - **Create Annotation** Marks a moment on a dataset's charts. The highest value thing a deployment flow can do here, because it turns a graph that changed shape into a graph that changed shape when this shipped. - **Update Annotation** Changes an annotation. Adding an end time is how a deploy marker becomes a band covering the whole rollout. - **Delete Annotation** Removes an annotation from the charts. ### Tokens 5 - **List API Tokens** Returns the organization's tokens and what each may do. The audit view, because it shows capabilities rather than intentions. - **Get API Token** Returns one token's metadata and capabilities. The secret is never returned. - **Create API Token** Creates a token and returns its secret in that response and nowhere else afterwards. A token created without capabilities authenticates successfully and is refused by everything. - **Regenerate API Token** Issues a new secret for an existing token and returns it once. The old secret stops working immediately, so everything holding it breaks until it is updated. - **Delete API Token** Revokes a token. Anything using it starts being refused immediately. ### Users 6 - **Get Current User** Returns the user or token the connection authenticates as. The cheapest connection check, and the fastest way to see which kind of token is in use. - **List Users** Returns the organization's users and their roles. - **Get User** Returns one user. - **Create User** Adds a user to the organization. The built in roles are coarse, so a view or a custom role is how access gets narrowed. - **Update User Role** Moves a user to a different role, which changes what they can read and delete across every dataset immediately. - **Remove User From Org** Takes a user out of the organization. Their personal access tokens stop working, so anything running under one of them breaks. ### Access 10 - **List Roles** Returns the organization's roles and their capabilities. - **Get Role** Returns one role with its capabilities and members. - **Create Role** Creates a custom role. A role that names no capabilities grants nothing. - **Update Role** Changes a role. Sending members replaces the whole list and sending capabilities replaces that whole map, so a partial send silently revokes what it left out. - **Delete Role** Removes a role. Its members lose whatever it granted. - **List Groups** Returns the organization's user groups. - **Get Group** Returns one group with its members and roles. - **Create Group** Creates a user group and attaches roles to it, which makes onboarding one call instead of several. - **Update Group** Changes a group's members or roles. Both lists are replaced, so a partial send removes people or revokes roles. - **Delete Group** Removes a group. Its members lose the roles it granted. ### Organization 2 - **List Orgs** Returns the organizations the token can reach, with their plans and limits. Where the ingest and query limits that govern everything else are named. - **Get Org** Returns one organization with its plan and license. ## Frequently Asked Questions ### What can FlowRunner do with Axiom? FlowRunner agents can run Ingest Events, Run Query, and List Datasets in Axiom, plus 67 more actions. ### Does connecting Axiom to FlowRunner require OAuth? No. Axiom connects to FlowRunner with an API key, no OAuth flow required. ### Can Axiom trigger a FlowRunner workflow automatically? Axiom doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Axiom?** This integration exposes Axiom to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/axiom. Site index: https://flowrunner.ai/llms.txt