# Tailglow Documentation (LLM-Optimized) This document provides a structured reference for Tailglow's API and platform guides. Generated from the documentation source files. --- # API Reference ## Errors # Errors ## Variations We follow standard HTTP status codes for errors. Here are the variations you might encounter: ### `request_invalid` - **Status Code:** 400 - **Message:** "The request is invalid." - **How to Resolve:** Check the request payload for missing or incorrect fields. ### `request_no_update` - **Status Code:** 400 - **Message:** "There was nothing new to update." - **How to Resolve:** Make sure you're submitting new or modified data. ### `request_validation_failed` - **Status Code:** 400 - **Message:** "The request failed validation." - **How to Resolve:** Ensure all fields meet the required validation rules. ### `unsupported_file_type` - **Status Code:** 400 - **Message:** "Unsupported file type." - **How to Resolve:** Use one of the supported file formats. ### `auth_missing_credentials` - **Status Code:** 401 - **Message:** "You must provide credentials to access this resource." - **How to Resolve:** Include your API key in the `Authorization` header. ### `auth_invalid_credentials` - **Status Code:** 401 - **Message:** "Your credentials are invalid." - **How to Resolve:** Double-check your API key or token. ### `auth_account_disabled` - **Status Code:** 401 - **Message:** "Your account is disabled, please contact support." - **How to Resolve:** Reach out to support to restore access. ### `auth_missing_permissions` - **Status Code:** 401 - **Message:** "You do not have permission to access this resource." - **How to Resolve:** Ensure your account has the appropriate permissions. ### `auth_mfa_required` - **Status Code:** 401 - **Message:** "Multi-factor authentication is required." - **How to Resolve:** Complete MFA verification before accessing this resource. ### `resource_limit_reached` - **Status Code:** 403 - **Message:** "You have reached the limit for this resource." - **How to Resolve:** Upgrade your plan or wait until the limit resets. ### `forbidden` - **Status Code:** 403 - **Message:** "This action is forbidden." - **How to Resolve:** Ensure you have proper permissions for this action. ### `resource_not_found` - **Status Code:** 404 - **Message:** "The requested resource was not found." - **How to Resolve:** Verify the resource ID or endpoint. ### `request_timeout` - **Status Code:** 408 - **Message:** "The request timed out." - **How to Resolve:** Retry the request or check your connection. ### `rate_limit_exceeded` - **Status Code:** 429 - **Message:** "You have exceeded the rate limit." - **How to Resolve:** Reduce the frequency of your requests and try again later. ### `resource_locked` - **Status Code:** 409 - **Message:** "The resource is locked." - **How to Resolve:** Unlock the resource if possible or wait until it becomes available. ### `payload_too_large` - **Status Code:** 413 - **Message:** "The payload was too large for the server to safely handle." - **How to Resolve:** Reduce the size of the request payload. ### `ingest_spool_full` - **Status Code:** 503 - **Message:** "Server at capacity (REASON); retry shortly", where REASON names the limiting resource, e.g. a disk-capacity reason such as "N MiB free below the M MiB byte floor" or "inodes P% at/above the C% ceiling", "ingest queue full", or "storage write failed". - **Returned by:** the ingest endpoint when the server's durable spool cannot accept more records. The response includes a `Retry-After` header (in seconds). - **How to Resolve:** Retry the request after the `Retry-After` interval. If the error persists, you've outgrown the server's allocated capacity for this project. Provision a larger spool volume or distribute traffic across additional servers. ### `ingest_auth_unavailable` - **Status Code:** 503 - **Message:** "The ingest key could not be verified; retry shortly." - **Returned by:** the ingest endpoint when it cannot reach the service that verifies ingest keys. Your key has not been rejected, and nothing about the request needs to change. The response includes a `Retry-After` header (in seconds). - **How to Resolve:** Retry the request after the `Retry-After` interval. Tailglow SDKs do this automatically. A key that was verified recently keeps being accepted throughout the outage, so this only affects a key the server has not seen lately. ### `database_error` - **Status Code:** 500 - **Message:** "A database error occurred." - **How to Resolve:** Try again later or contact support if the issue persists. ### `invalid_server_state` - **Status Code:** 500 - **Message:** "The server is in an invalid state." - **How to Resolve:** Contact support if the issue persists. ### `plan_limit_reached` - **Status Code:** 403 - **Message:** "You have reached the limit for your current plan." - **How to Resolve:** Upgrade your plan to increase your limits. ### `server_error` - **Status Code:** 500 - **Message:** "An error occurred." - **How to Resolve:** Try again later or contact support if the issue persists. ### `not_implemented` - **Status Code:** 501 - **Message:** "This route has not been implemented." - **How to Resolve:** Contact support or refer to the documentation for available routes. ## Enums # Enums This page lists common enum values used across the API. ## Metric Group By The `group_by` field accepts any string field names from your view's output schema. There is no fixed set of allowed values. ## Chart Types - `line` - `area` - `bar` - `pie` - `scatter` - `radar` - `stat` - `gauge` - `calendar` - `uptime` ## Chart Color Modes How a chart picks colors. The chart type must allow the chosen mode (e.g., gauge supports `by_series` and `by_value`; calendar supports `by_series` and `by_intensity`). - `by_series`: Each series gets its own color. Colors are auto-assigned from a deterministic series-hash → palette projection (stable across drill-down). Per-series overrides via [Update Series](/api/metrics#update-series). - `by_intensity`: One base color (`ui_chart_color_base`); the renderer modulates lightness/opacity by value. Used by calendar / heatmap-style charts. - `by_value`: Ordered rules (`ui_chart_color_rules`) map each value to a color. First matching rule wins; no match falls back to system default. Used by gauges and uptime strips. ## Metric Chart Values Determines which aggregation is displayed by default on a chart. - `count`: Number of records. - `average`: Average of the record `value` field. - `sum`: Sum of the record `value` field. - `min`: Minimum of the record `value` field. - `max`: Maximum of the record `value` field. - `last`: Latest reading in each time bucket per group_by combination. Within the requested range, the last observed value carries forward across complete empty intervals. Use for entity/snapshot data (e.g., deals, users, inventory). - `cumulative_sum`: Cumulative sum of the record `value` field over the time range. - `cumulative_count`: Cumulative count of records over the time range. - `p50`: 50th percentile (median) of the record `value` field. - `p95`: 95th percentile of the record `value` field. - `p99`: 99th percentile of the record `value` field. - `count_unique`: Number of distinct values of the `unique_field`. Exact for small cardinalities (up to 8,192), approximate for larger sets. ## Empty Bucket Handling Controls how time intervals with no data render on a metric's chart. This is a display setting: changing it applies instantly to all historical data with no recalculation. - `zero`: Empty intervals render as a true 0. The right choice for additive aggregations (`count`, `sum`, `cumulative_*`, `count_unique`) where "nothing happened" means zero. Monitors evaluate an empty window as 0, so conditions like `count == 0` can trigger. - `gaps`: Empty intervals render as gaps (`null` values in `series.records`) and are excluded from trend line fitting. The right choice for observational aggregations (`average`, `min`, `max`, percentiles) where an empty interval has no defined value. Monitors skip evaluation when a series has no data in the window: nothing fires and open alerts stay open until data returns. The `last` chart value is the one exception on charts: it carries the latest measured value forward through empty intervals in both modes. New metrics default based on their `ui_chart_value`: additive aggregations get `zero`, observational aggregations get `gaps`. ## Chart Colors Possible values for the `color` property within `ui_chart_colors`. - `blue` - `red` - `amber` - `green` - `teal` - `purple` - `pink` ## Analytics Time Ranges Used for `time_range` (in aggregation requests) and `ui_chart_time_range` (in the metric object). - `last_hour` - `last_6_hours` - `today` - `last_24_hours` - `yesterday` - `this_week` - `last_7_days` - `last_week` - `this_month` - `last_30_days` - `last_month` - `this_quarter` - `last_90_days` - `last_quarter` - `this_year` - `last_365_days` - `last_year` - `all_time` - `custom` (Requires specific start/end dates) - `next_7_days` - `next_30_days` - `next_90_days` A `next_*` range reaches the same distance into the past as it does into the future, so a chart has history to fit a forecast from. ## Forecast Horizons Used for `ui_chart_forecast_horizon` (in the metric object). Relative values resolve when the chart is viewed. - `next_7_days` - `next_30_days` - `next_90_days` - `end_of_quarter` - `end_of_year` - `next_year` ## Forecast Models Used for `ui_chart_forecast_model` (in the metric object). `auto` follows whichever model fits the data best. - `auto` - `linear` - `exponential` - `logarithmic` - `logistic` - `sinusoidal` ## Metric Data Intervals Used for `interval` (in aggregation requests) and `ui_chart_interval` (in the metric object). - `minute` - `hour` - `day` - `month` ## View Transform Modes How a [View](/api/views#model) acquires a [TGL](/guides/tgl) transform for schema versions discovered after it was created. Both modes first try to reuse one of the view's existing scripts. Reuse requires a typed candidate signature and at least one of the script's read paths to be present. A present path whose value is null counts as evidence; an absent path does not. An unknown-only signature is not eligible for reuse. The modes differ only when no existing script can read the new shape: - `auto`: Tailglow generates a script for the new version. - `manual`: The version waits for you to supply a compatible script instead of generating one automatically. A supplied script can wait for input before validation. ## View Transform Conflict Resolutions Controls what happens when editing a collection-backed transform would make the new script incompatible with some schema versions that used the prior script. - `strand`: Default. Compatible versions adopt the edit; conflicting versions move to queued placeholders so they can receive their own script. - `keep`: Compatible versions adopt the edit; conflicting versions remain on the prior script. ## Schema Version States The lifecycle of a collection's [schema version](/guides/concepts#schema-versions), from first sight to trust. - `candidate`: The shape has been seen once. Its records are stored and served immediately by any view mapping that already fits them, but no mapping is written for it yet. - `settled`: The shape was seen again after the collection's recurrence gap, arrived in one batch with at least the bulk row count, or a person settled it. Only settled versions are offered to views for authoring, and a settled version never goes back. - `stale`: A candidate that was not seen again within the stale window. Its rows stay stored but unclassified. A stale shape that returns settles. ## Schema Settlements What settled a schema version. - `recurrence`: The shape was seen again after the collection's recurrence gap. - `bulk`: One batch carried at least the collection's bulk row count of the shape. - `person`: Someone settled the version from the collection page or through the API. ## Schema Rule Modes How a collection applies each of its three identity rules: nulls and absent values, optional keys, and the detector. See [Schema settings](/guides/sources#schema-settings). - `auto`: Tailglow decides. Null and absent values are accepted at any path a mapping reads, a record whose keys are a subset of a version's keys joins that version, and a safe opaque-path proposal from the detector is applied on its own. - `manual`: A person decides at each of those points. ## Metric Statuses The current status of the metric. - `initializing`: Metric is being created. - `waiting_for_transforms`: Metric is waiting for its source transforms to finish processing. - `backfilling`: Historical data is being backfilled (also covers re-backfill triggered by data-feed changes). - `active`: Metric is up-to-date and collecting new data. - `error`: An error occurred during processing. - `cancelled`: The metric, or the view it reads, was deleted while a backfill was still running, so the backfill was cancelled instead of being allowed to finish. Restoring the metric within its 24-hour window leaves it here; re-run the backfill to finish what it missed. ## View Statuses The current status of a [View](/api/views#model), derived from its transforms. - `empty`: The view has no transforms yet. - `building`: A transform is waiting for input or processing data, including indexing history. - `needs_transform`: A transform script needs to be written or corrected. This can occur in either transform mode. - `active`: At least one transform is finished and serving data. - `cancelled`: The view was deleted while it was still indexing, so the indexing was cancelled rather than allowed to finish. Deleted views remain readable until permanent removal 24 hours later, and they report this status for that window. - `error`: A transform failed to compile, or its indexing failed. ## Metric Values Indicates which aggregations were calculated in the [Metric Aggregation Model](/api/metrics#aggregation-model). - `count` - `sum` - `min` - `max` ## Filter Operators The canonical operator vocabulary used everywhere filters appear: list endpoint query parameters (`?=:`), metric `filters` (applied at rollup time), facet record queries against indexed views, and the UI filter components. URL syntax is flat: `?type_1=equals:Fire&limit=50`. Operator names are long-form snake*case except for the industry-standard `gt`/`gte`/`lt`/`lte`/`in`. Every negation has a `not*` prefix. String operators compare case-insensitively (`equals:Get`matches`GET`); numeric, date, and existence operators are unaffected. | Operator | Semantics | | ----------------- | --------------------------------------------- | | `equals` | Exact match | | `not_equals` | Inverse of `equals` | | `gt` / `gte` | Greater than (strict / inclusive) | | `lt` / `lte` | Less than (strict / inclusive) | | `between` | Inclusive range; value is `min,max` | | `contains` | Substring match (strings) | | `not_contains` | Inverse of `contains` | | `starts_with` | Prefix match (strings) | | `not_starts_with` | Inverse of `starts_with` | | `ends_with` | Suffix match (strings) | | `not_ends_with` | Inverse of `ends_with` | | `in` | Scalar field, value in a comma-separated list | | `not_in` | Inverse of `in` | | `has` | Array field contains the given scalar | | `not_has` | Inverse of `has` | | `has_any` | Array field intersects a comma-separated list | | `exists` | Field has a non-null value | | `not_exists` | Field is null or absent | ### Per-type allowlist (UI filter components) | Field type | Allowed operators | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `string` | `equals`, `not_equals`, `contains`, `not_contains`, `starts_with`, `not_starts_with`, `ends_with`, `not_ends_with`, `in`, `not_in` | | `number` | `equals`, `not_equals`, `gt`, `gte`, `lt`, `lte`, `between`, `in`, `not_in` | | `date` | `equals`, `not_equals`, `gt`, `gte`, `lt`, `lte`, `between` | | `array` | `has`, `not_has`, `has_any` | | `boolean` | `equals`, `not_equals` | ### Surface availability Not every operator is supported by every surface. The metric filter pipeline supports the full vocabulary; CRUD list endpoints reject existence operators in v1 (the per-field nullable-aware validators land separately); facet record queries are limited to the SQLite-indexed subset. | Operator | Metric filters | CRUD list | Facet records | | ----------------- | :------------: | :-------: | :-----------: | | `equals` | ✓ | ✓ | ✓ | | `not_equals` | ✓ | ✓ | | | `gt` | ✓ | ✓ | | | `gte` | ✓ | ✓ | ✓ | | `lt` | ✓ | ✓ | | | `lte` | ✓ | ✓ | ✓ | | `between` | ✓ | ✓ | | | `contains` | ✓ | ✓ | | | `not_contains` | ✓ | ✓ | | | `starts_with` | ✓ | ✓ | ✓ | | `not_starts_with` | ✓ | ✓ | | | `ends_with` | ✓ | ✓ | | | `not_ends_with` | ✓ | ✓ | | | `in` / `not_in` | ✓ | ✓ | | | `has` | ✓ | | | | `not_has` | ✓ | | | | `has_any` | ✓ | | | | `exists` | ✓ | | | | `not_exists` | ✓ | | | ### Reserved query parameter keys Several keys are reserved as query-string control parameters across every endpoint. View `output_schema` fields and facet `field_path` values cannot use any of these names: `limit`, `cursor`, `page`, `sort`, `order_by`, `after`, `before`, `start_at`, `end_at`, `timezone`, `interval`, `search` ## Monitor Condition Types | Value | Meaning | | --- | --- | | `threshold` | Compare the selected metric value with a threshold. | | `sustained` | Require that comparison to hold for a duration. | | `existence` | Fire when the selected value is greater than zero. | | `absence` | Fire when a complete evaluation window contains no observations, even on a chart that displays gaps. Requires Count and a finite window. | For absence, Total watches the whole filtered feed. Any series and Each series watch known individual series. A measured value of zero is still an observation. Unknown completeness postpones evaluation. ## Drain Statuses Lifecycle status of a Drain. - `draft`: Created but never verified. No outbound traffic. - `pending_verification`: A verification marker has been sent to the destination and we're waiting for the customer to paste it back via Confirm Verification. - `active`: Drain is verified, resumed, and forwarding records on the recurring schedule. - `paused`: You stopped the drain, or it was freshly verified (verification intentionally lands paused so you can sample before going live). Only you start it again. Resume via Resume Drain. - `disabled`: Tailglow stopped the drain after 72 hours of consecutive failures. Resume the same way after fixing the destination; resuming clears the failure counters. ## Drain Body Formats Wire format for the body of outbound drain POSTs. - `ndjson`: Newline-delimited JSON. Default. One record per line. Sent with `Content-Type: application/x-ndjson`. - `json`: A single JSON array of records. Required by Datadog Logs and similar receivers. Sent with `Content-Type: application/json`. ## Drain Compressions Wire compression for outbound drain POSTs. - `none`: Default. Body is sent uncompressed and works with any receiver. - `gzip`: Body is gzipped and `Content-Encoding: gzip` is added. Receivers MUST decompress `Content-Encoding` for this to work. ## Check Statuses Lifecycle status of a Check ([`status`](/api/checks#model)). - `active`: Running on its schedule. - `paused`: You stopped the check. Nothing is recorded for the minutes a pause covers, so the uptime record shows a gap rather than downtime. Start it again with Resume Check. - `disabled`: Tailglow stopped the check because the team is no longer in good standing. A failing endpoint never lands here, however long the failure lasts, because the outage is the thing the check exists to record. Resume the same way once the account is settled. ## Check Methods The HTTP method a check uses to request its endpoint ([`method`](/api/checks#model)). Both are observational, so a check can never change anything at the endpoint it watches. - `get`: Default. - `post`: For health endpoints that only answer to POST. Only a `post` check may send a `request_body`. ## Check Error Stages Which step of the most recent failed run went wrong ([`last_error_stage`](/api/checks#model)). A check never reads the response body, so there is no parse stage. - `request`: No usable response arrived. The address was refused by the outbound guard, the request timed out, TLS failed, the connection was reset, or the body ran past the size cap before it finished. - `response`: The endpoint answered, but not with a 2xx status. ## Appearance Palettes The color palette for a user's app appearance ([`appearance_palette`](/api/users#model)). Sets the light or dark scheme. - `light` - `dark` - `dim`: Default. A softer dark scheme. - `midnight` - `paper` ## Appearance Type Sets The font pairing for a user's app appearance ([`appearance_type_set`](/api/users#model)). - `system`: Default. The operating system's native font stack. - `grotesk` - `editorial` - `geometric` ## Appearance Accents The accent color for a user's app appearance ([`appearance_accent`](/api/users#model)). - `orange`: Default. - `azure` - `burgundy` - `ink` - `emerald` - `violet` ## Appearance Scales The UI scale (density) for a user's app appearance ([`appearance_scale`](/api/users#model)). Applies at tablet and desktop widths; mobile always renders at full size. - `comfortable`: 100% scale. - `cozy`: 90% scale. - `compact`: Default. 80% scale, fits more on screen. ## Ingest Pipeline Error Reasons The reasons behind the Errors series on a server's Ingest Pipeline chart. Every reason is a refusal issued before acceptance: the sender received an error response and nothing was recorded from that request. Accepted data is never dropped. It is queued on the server and retried until it lands. Reasons where retrying the same request delivers the data. Tailglow SDKs retry these automatically; if you send raw HTTP, retry on any 5xx response: - `connection_closed`: The sender closed the connection before the upload finished. - `server_error`: An unexpected error while handling the request. - `spool_full_disk_gate`: The server paused intake to protect its disk from filling. - `spool_full_storage_write`: A buffer write failed while accepting the request. - `spool_full_ingest_queue`: The intake queue was momentarily full. - `spool_full_wal_unavailable`: The write buffer was restarting. - `auth_unavailable`: The ingest key could not be verified because the verification service was unreachable. The key itself was not rejected. Reasons where the request itself must change. Retrying the same request is refused again: - `auth_missing_credentials`: No ingest key was provided. - `auth_invalid_credentials`: The ingest key is wrong or revoked. - `payload_too_large`: The payload exceeds the size limit. - `request_validation_failed`: The request body or parameters are invalid. - `frame_invalid`: A frame in the payload could not be parsed. - `empty_payload`: The request carried no data. - `source_deleted`: The target source no longer exists. ## Introduction # Introduction ## Base URL The Tailglow API is built on REST principles. We enforce HTTPS in every request to improve data security, integrity, and privacy. The API does not support HTTP. All requests contain the following base URL: ```md https://api.tailglow.io ``` ## Authentication To authenticate with the Tailglow API, send your API key in the `Authorization` header using the `Bearer` scheme. An API key looks like `tg_api_` followed by 70 characters. ```md Authorization: Bearer tg_api_1a2B3c4D5e6F7g8H9i0J... ``` `Authorization: Key ` is also accepted, as is sending the key on its own with no scheme. Keys issued before the `tg_api_` prefix begin with `sk_` and keep working indefinitely. ## Filtering Data When filtering data, you'll create a query string that will be appended to the URL of your `GET` request. The query string will begin with a `?` and contain key-value pairs separated by `&`. ``` Be careful when using "not" filters. They can result in a lot of data being returned. ``` Tailglow uses a single canonical operator vocabulary across every filter surface. URL syntax is flat: `?=:`. The full list, per-type allowlists, and per-surface availability matrix live in the [Filter Operators enum](/api/enums#filter-operators). ### Strings - **`equals`** - `?type=equals:expense` - **`not_equals`** - `?type=not_equals:expense` - **`starts_with`** - `?type=starts_with:expense` - **`not_starts_with`** - `?type=not_starts_with:expense` - **`ends_with`** - `?type=ends_with:expense` - **`not_ends_with`** - `?type=not_ends_with:expense` - **`contains`** - `?type=contains:expense` - **`not_contains`** - `?type=not_contains:expense` - **`in`** - `?type=in:expense,refund` - **`not_in`** - `?type=not_in:expense,refund` String operators compare case-insensitively, so `?type=equals:GET` and `?type=equals:get` include the same rows. ### Numbers - **`equals`** - `?value=equals:100` - **`not_equals`** - `?value=not_equals:100` - **`gt`** (Greater Than) - `?value=gt:100` - **`gte`** (Greater Than or Equal) - `?value=gte:100` - **`lt`** (Less Than) - `?value=lt:100` - **`lte`** (Less Than or Equal) - `?value=lte:100` - **`between`** - `?value=between:100,200` - **`in`** / **`not_in`** - `?value=in:100,200` ## Pagination Most `list` endpoints use cursor-based pagination. The first request omits the cursor; subsequent requests echo back the `next_cursor` (or `prev_cursor`) the previous response handed you. ### Request parameters - **`limit`** `number` Maximum number of items to return per page. Defaults to `25`, max `200`. - **`after`** `string` Opaque cursor from a previous response's `pagination.next_cursor`. Returns the rows after the pivot. - **`before`** `string` Opaque cursor from a previous response's `pagination.prev_cursor`. Returns the rows before the pivot. Mutually exclusive with `after`. - **`sort`** `"asc" \| "desc"` Sort direction. Cursors are minted under one direction; reusing them under a different sort returns a `400`. ### Response shape The `pagination` object on every list response carries: - **`limit`** `number`: echoed from the request. - **`count`** `number`: number of rows in this page (≤ `limit`). - **`offset`** `number`: 0-indexed position of the first row across the full result set. Use `offset + 1` for "Showing 21" labels. - **`sort`** `"asc" \| "desc"`: echoed sort direction. - **`next_cursor`** `string \| null`: cursor for the next page. `null` means there are no more rows. - **`prev_cursor`** `string \| null`: cursor for the previous page. `null` means you're on the first page. - **`total`** `number \| null`: exact row count for database-backed lists and records. `null` is returned only when the underlying feed cannot provide a total. For example, collection docs always return `null` because the underlying files aren't enumerated. Cursors are server-minted opaque tokens. Don't construct them yourself; round-trip the values the API gave you. ## Responses All of our responses will follow a standard structure, regardless if it's successful or not. Here is an example of the response object. ### Successful Response Example If you are listing data, the `data` key will be an array of objects and a pagination object will be present. If you are retrieving, creating, or writing a single object, the `data` key will be an object. If you are deleting an object, the `data` key will be `null`. ```json { "message": "Data retrieved successfully", "data": [], "status": 200, "error": null, "pagination": { "object": "pagination", "limit": 10, "count": 10, "offset": 0, "sort": "desc", "next_cursor": "eyJ2IjoxLCJyZXNvdXJjZSI6...", "prev_cursor": null, "total": 42 }, "endpoint": "/v1/projects" } ``` ### Error Response Example You'll typically see error when request validations fail. The `error` key will contain an object with a `code` key and a `properties` key that will contain an array of objects with an `id` and `message` key. The `id` corresponds to the field that failed validation and the `message` will contain the error message. ```json { "message": "The request is invalid", "data": null, "status": 400, "error": { "code": "request_invalid", "properties": [ { "id": "name", "message": "Name is required" } ] }, "pagination": null, "endpoint": "/v1/projects" } ``` ## Projects # Project Model ## Fields - **`object`** `"project"` - **`id`** `string` Project identifier prefixed with `prj_`. - **`team_id`** `string` - **`team_name`** `string` - **`trial_expires_at`** [`ISODateString | null`](/api/projects#iso-date-string) This team's trial lifecycle window; promotional units are shared across its projects. - **`name`** `string` - **`start_at`** [`ISODateString`](/api/projects#iso-date-string) Metrics collection begins at this time. - **`created_at`** [`ISODateString`](/api/projects#iso-date-string) - **`updated_at`** [`ISODateString`](/api/projects#iso-date-string) - **`deleted_at`** [`ISODateString | null`](/api/projects#iso-date-string) Scheduled deletion time; `null` when deletion is not scheduled. - **`last_activity_at`** [`ISODateString | null`](/api/projects#iso-date-string) Most recent authenticated ingest time; `null` if none has occurred. - **`late_data_window_minutes`** `number` How many minutes behind the completeness watermark an event with an overridden timestamp may arrive and still be included automatically. Later data is recorded and surfaced for manual re-backfill. 0 means the watermark is final as it advances. Data sent live is never affected. - **`server_endpoint`** `string | null` Project-specific ingest endpoint; `null` while unavailable. - **`queued_server_count`** `number | null` Server count a scale request asked for that is waiting to be applied, because a platform update is in progress or the project has not finished updating to the current platform version. `null` when nothing is queued. - **`storage_gb`** `number` Stored data for this project, in gigabytes of uncompressed data: raw ingested files and artifacts, plus view output and minute-level rollups. Recalculated hourly; `billing_updated_at` is the last refresh. - **`billing_period_server_months`** `number` Server-months this project's servers have accrued in the current calendar-month billing period, counted up to the last refresh. - **`billing_updated_at`** [`ISODateString | null`](/api/projects#iso-date-string) Last billing-cache refresh; `null` before the first calculation. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Late Data Model ## Fields - **`object`** `"late_data_file"` - **`id`** `string` Unique identifier, prefixed with `ldf_`. - **`view_id`** `string` - **`view_name`** `string` Display name of the view whose data carried the late events. - **`excluded_count`** `number` How many events were kept out of charts because their timestamps fell behind the project's late data window. The events themselves are stored; only their aggregation waits. - **`min_event_at`** [`ISODateString`](/api/projects#iso-date-string) The earliest event time among the excluded events. A re-backfill folds back to this instant. - **`max_event_at`** [`ISODateString`](/api/projects#iso-date-string) The latest event time among the excluded events. - **`exclusion_below`** [`ISODateString`](/api/projects#iso-date-string) The boundary the events fell behind. Events at or after it were included normally. - **`refold_queued_at`** [`ISODateString | null`](/api/projects#iso-date-string) When a re-backfill was requested for these events; null until requested. - **`refolded_at`** [`ISODateString | null`](/api/projects#iso-date-string) When the re-backfill finished folding the events into charts; null until complete. - **`created_at`** [`ISODateString`](/api/projects#iso-date-string) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Live Pipeline Model ## Fields - **`object`** `"project_pipeline_live"` - **`observed_at`** [`ISODateString`](/api/projects#iso-date-string) - **`pending_records`** `number | null` Valid spooled records awaiting write, including processing. Null when the queue is unknown. - **`processing_records`** `number | null` Pending records currently being processed. - **`pending_observed_at`** [`ISODateString | null`](/api/projects#iso-date-string) Oldest contributing queue observation, independent of the server heartbeat. - **`pending_is_estimated`** `boolean` The queue changed during inspection; available counts are estimates from durable records. - **`state`** `"fresh" | "stale" | "unavailable"` Queue freshness across all current project servers, including deployment surges. - **`contributing_servers`** `number` - **`fresh_servers`** `number` - **`window_start_at`** [`ISODateString`](/api/projects#iso-date-string) Inclusive start of the last completed minute. - **`window_end_at`** [`ISODateString`](/api/projects#iso-date-string) Exclusive end of the last completed minute. - **`throughput_records`** `number | null` Records processed in the completed minute. Null when any contributor lacks telemetry. - **`errors`** `number | null` Rejected requests and dropped frames in the completed minute, not a record count. - **`pipeline_error_counts`** `Partial | null` Map from each `PipelineErrorReason` key to its error count for the completed minute. Omitted keys had no errors; `null` means telemetry is incomplete. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### PipelineErrorReason `"auth_missing_credentials" | "auth_invalid_credentials" | "payload_too_large" | "request_validation_failed" | "server_error" | "spool_full_disk_gate" | "spool_full_storage_write" | "spool_full_ingest_queue" | "spool_full_wal_unavailable" | "frame_invalid" | "empty_payload" | "source_deleted" | "connection_closed" | "auth_unavailable"` # Usage Sample Model ## Fields - **`object`** `"usage_sample"` - **`sampled_at`** [`ISODateString`](/api/projects#iso-date-string) When the reading was taken. Readings are hourly, on the hour. With `interval=day` this is the timestamp of the day's last reading, not midnight. - **`collection_gb`** `number` Gigabytes of raw event data held in the project's collections, measured uncompressed, exactly as it is billed. - **`artifact_gb`** `number` Gigabytes of artifacts extracted from the project's events, measured uncompressed. - **`view_gb`** `number` Gigabytes of view records the project's views produced, measured uncompressed. - **`rollup_gb`** `number` Gigabytes of rollup data behind the project's charts, measured uncompressed. Counts the minute tier only, matching what invoices charge for. - **`total_gb`** `number` The four components added together: everything the project stored at this reading. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Attention Item Model ## Fields - **`object`** `"attention_item"` - **`type`** [`AttentionItemType`](/api/projects#attention-item-type) - **`tier`** [`AttentionTier`](/api/projects#attention-tier) - **`resource_id`** `string | null` The resource to open to act on the condition: the metric behind a firing monitor, the view behind a failing transform, otherwise the check, view, metric, drain, pull or server itself. Null when the item covers the project as a whole, which is the case for refused requests. - **`resource_name`** `string | null` The name shown for the condition, which can belong to a related resource: a firing monitor's item names the monitor while `resource_id` opens its metric. Null whenever `resource_id` is null. - **`count`** `number | null` How much of the condition there is, in the unit that fits it: requests refused (not records) over the last 24 hours, or the last hour for capacity, series a monitor is firing on, a view's failing transforms, events waiting on a shape change, consecutive failures of a check, pull, or drain, or a hot server's average load in percent. Null when the condition has no quantity. - **`since`** [`ISODateString | null`](/api/projects#iso-date-string) When the condition started, as accurately as Tailglow knows. Null when nothing on record marks a beginning: a check that has never once succeeded, or a server under sustained load, which is judged from an average rather than a start. - **`ended_at`** [`ISODateString | null`](/api/projects#iso-date-string) When the condition stopped, for a `resolved` item: to the minute within the last hour, to the end of the hour before that. Null while the condition is still true, including while a server that was refusing has not reported since. - **`detail`** `string | null` A short machine-readable qualifier that narrows the type: the refusal reason group, the firing monitor's id, or `cpu` or `mem` for the load that made a server hot. A stable identifier meant for branching in code, never a sentence to display. Null when the type needs no qualifier. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### AttentionItemType `"ingest_refusals" | "capacity_refusals" | "monitor_firing" | "check_down" | "transform_error" | "metric_error" | "join_error" | "shape_deferral" | "pull_suspended" | "drain_suspended" | "drain_unverified" | "servers_hot"` The condition an attention item reports. Every value is a state Tailglow entered on its own, so nothing a project deliberately turned off is ever reported here. ### AttentionTier `"losing_data" | "firing" | "stalled" | "suspended" | "resolved"` How urgent an attention item is, most urgent first. `losing_data` means requests are being refused right now in a way that loses data unless the sender acts, or were until a server that was refusing stopped reporting. `firing` means something the project asked to be told about is currently true, or a server has run under sustained heavy load. `stalled` means a pipeline stopped making progress and existing data is going stale. `suspended` means Tailglow switched something off and it stays off until it is fixed. `resolved` means refusals that lost data have stopped; the item stays for a while so the loss is still visible, and says when it ended. # List Projects ## Endpoint Retrieve a list of projects for the current team. ```http GET /v1/projects ``` **Scope:** `projects:read` ## Query Parameters - **`order_by`** `string` Field used to order the projects. Optional. Defaults to `"name"`. Allowed values: `"created_at"`, `"name"`. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Project[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - When neither `sort` nor `order_by` is provided, the route defaults `sort` to `"asc"`. - `after` and `before` are mutually exclusive. # Retrieve Project ## Endpoint Retrieve a single project. ```http GET /v1/projects/:project_id ``` **Scope:** `projects:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Response Project retrieved ```ts { message: string; data: Project; status: 200; error: null; pagination: null; endpoint: string; } ``` # Retrieve Project Pipeline ## Endpoint Retrieve ingest activity across all of a project's servers. ```http GET /v1/projects/:project_id/pipeline ``` **Scope:** `servers:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`start_at`** [`ISODateString`](/api/projects#iso-date-string) Start time (ISO format, default: 12 hours ago). Optional. - **`end_at`** [`ISODateString`](/api/projects#iso-date-string) End time (ISO format, default: now). Optional. - **`interval`** `string` Aggregation interval. Optional. Defaults to `"minute"`. Allowed values: `"minute"`, `"hour"`. ## Response Project pipeline retrieved ```ts { message: string; data: TimeseriesAggregation; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Includes temporary deployment servers and their archived history. Pending averages valid queued records; throughput counts drained records. Older pending history without record counts is unknown. # Retrieve Live Project Pipeline ## Endpoint Retrieve the current project queue and ingest totals for the last completed minute. ```http GET /v1/projects/:project_id/pipeline/live ``` **Scope:** `servers:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Response Live project pipeline retrieved ```ts { message: string; data: ProjectPipelineLive; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Includes temporary deployment servers. Queue freshness is independent of heartbeat freshness. Observations taken while queues change return estimated counts from durable records; unreadable observations or unknown write outcomes return null counts. - Throughput and error totals cover the last completed minute. Errors count requests or frames, and totals are null when telemetry is incomplete. # Create Project ## Endpoint Create a new project for the current team. ```http POST /v1/projects ``` **Scope:** `projects:write` ## Request Body - **`name`** `string` -- **Required** Display name for the project. Minimum length: `1`. Maximum length: `60`. - **`start_at`** [`ISODateString`](/api/projects#iso-date-string) Date and time when the project began collecting data. Optional. ## Response Your project has been created. ```ts { message: string; data: Project; status: 201; error: null; pagination: null; endpoint: string; } ``` # Update Project ## Endpoint Update an existing project. ```http POST /v1/projects/:project_id ``` **Scope:** `projects:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` Display name for the project. Optional. Minimum length: `1`. Maximum length: `60`. - **`start_at`** [`ISODateString`](/api/projects#iso-date-string) Date and time when the project began collecting data. Optional. - **`late_data_window_minutes`** `integer` How many minutes behind the completeness watermark an event with an overridden timestamp may arrive and still be included automatically. Later data is recorded and surfaced for manual re-backfill instead of being included. 0 means the watermark is final as it advances. Only events with overridden timestamps can be late; data sent live is never affected. Maximum 129600 (90 days). Optional. Minimum: `0`. Maximum: `129600`. - **`deleted_at`** `null` Set to null to cancel a scheduled project deletion. Optional. ## Response Your project has been updated. ```ts { message: string; data: Project; status: 200; error: null; pagination: null; endpoint: string; } ``` # Delete Project ## Endpoint Schedule a project for deletion. ```http DELETE /v1/projects/:project_id ``` **Scope:** `projects:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Response ```ts { message: string; data: Project; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The project is hidden immediately and permanently removed 7 days later. Restore it before then by updating it with `deleted_at` set to null. # Force Delete Project ## Endpoint Delete a project permanently, without waiting out its restore window. ```http DELETE /v1/projects/:project_id/force ``` **Scope:** `projects:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Response Project queued for permanent deletion. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Works on a live project as well as one already scheduled for deletion. - Every source, collection, view, metric and record in the project is destroyed immediately, and its servers are torn down. Nothing here can be restored. # List Late Data ## Endpoint Retrieve the events held out of charts by the project's late data window, grouped per data file. ```http GET /v1/projects/:project_id/late_data ``` **Scope:** `projects:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field used to order the late data records. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`, `"min_event_at"`. - **`refolded`** `string` Filter by re-backfill state: false returns records whose events are still excluded from charts, true returns records a completed re-backfill has folded in. Optional. Allowed values: `"true"`, `"false"`. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: LateDataFile[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - Events with overridden timestamps beyond the late data window are stored and counted here instead of entering charts. Data sent live is never held. - Records with `refolded_at` set have already been folded into charts by a completed re-backfill; filter with `refolded=false` for records still waiting. - `after` and `before` are mutually exclusive. # Re-backfill Late Data ## Endpoint Start a re-backfill that folds one late data record's events into charts. ```http POST /v1/projects/:project_id/late_data/:late_data_file_id/re_backfill ``` **Scope:** `projects:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`late_data_file_id`** `string` -- **Required** Unique identifier of the late data. ## Response Re-backfill queued. The events will appear in charts as the fold completes. ```ts { message: string; data: LateDataFile; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Idempotent: requesting a re-backfill that is already queued or complete returns the record unchanged. - The fold is bounded to the excluded events, so data already in charts is never counted twice. `refolded_at` is set once the fold's durable receipts land. # Retrieve Project Usage ## Endpoint Retrieve how much the project stored over a time range. ```http GET /v1/projects/:project_id/usage ``` **Scope:** `projects:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`start_at`** [`ISODateString`](/api/projects#iso-date-string) -- **Required** Start of the range, inclusive (ISO format). - **`end_at`** [`ISODateString`](/api/projects#iso-date-string) End of the range, inclusive (ISO format, default: now). Optional. - **`interval`** `string` Reading cadence returned: every hourly reading, or one reading per UTC day. Optional. Defaults to `"hour"`. Allowed values: `"hour"`, `"day"`. ## Response ```ts { message: string; data: UsageSample[]; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Readings are taken hourly and are the same measurements the project is billed on. Gigabytes are logical (uncompressed) bytes. - `interval=day` returns the last reading of each UTC day rather than an average, so a row is what the project held when the day closed. Its `sampled_at` is that reading's own hour. - Readings start when Tailglow began recording them, so a range reaching further back returns nothing for the hours before that. - `start_at` must be earlier than `end_at`, and the range cannot be longer than 400 days. # Retrieve Project Attention ## Endpoint Retrieve everything in the project that is asking for a human right now. ```http GET /v1/projects/:project_id/attention ``` **Scope:** `projects:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Response ```ts { message: string; data: AttentionItem[]; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - An item appears only when Tailglow entered a state on its own. Anything a project chose, such as a paused pull, a paused drain, or a paused monitor, is never reported here. - `tier` orders the list. `losing_data` means requests are being refused right now, within the last 5 minutes: for a reason a retry cannot fix, or for capacity after at least 5 minutes of unbroken refusals. `firing` means a monitor or check the project set up is currently triggered, or a server has run under sustained heavy load. `stalled` means a pipeline stopped making progress and its data is going stale. `suspended` means Tailglow switched something off and it stays off until it is fixed. `resolved` means refusals that lost data have stopped; `ended_at` says when. - Items disappear the moment their condition clears, with one exception so a loss is not missed: refusals that stop stay as `resolved`, for up to 24 hours for a key or payload refusal and up to an hour for capacity. A refusal item's `count` covers that whole window, not only the current spell. Refusals only count as stopped once every running server that was refusing has reported since; until then the item stays `losing_data`. Readings from the project's servers are cached briefly, so a condition that just started can take up to a minute to appear. - Items cover only resources the caller's key or role can read: without a resource's read permission, its conditions are left out. Refusal and server load items need `servers:read`, and firing monitors need `alerts:read`. - Items are already ranked, most urgent first. One item covers each firing monitor, and each view's failing transforms, joins, or shape waits. The response is capped per condition so a project in a bad state returns a readable list rather than every affected resource. ## Sources # Source Model ## Fields - **`object`** `"source"` - **`id`** `string` Unique identifier, prefixed with `src_`. - **`project_id`** `string` - **`project_name`** `string` - **`name`** `string` Unique within its project. - **`storage_gb`** `number` Data this source has ingested, in gigabytes of uncompressed data: collection files plus uploaded artifacts. Recalculated hourly. - **`schema_count`** `number` How many schema versions this source has produced. - **`collections_count`** `number` How many collections this source feeds. - **`deleted_at`** [`ISODateString | null`](/api/sources#iso-date-string) When the source is scheduled to be deleted; null when it is not. - **`created_at`** [`ISODateString`](/api/sources#iso-date-string) - **`updated_at`** [`ISODateString`](/api/sources#iso-date-string) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Sources ## Endpoint Retrieve a list of sources for a project. ```http GET /v1/projects/:project_id/sources ``` **Scope:** `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field used to order the sources. Optional. Defaults to `"name"`. Allowed values: `"created_at"`, `"name"`, `"updated_at"`. - **`project_id`** `string` Filter to sources belonging to a single project. Optional. - **`deleted_at`** [`NullableDateFilter`](/api/sources#nullable-date-filter) Filter by scheduled deletion date. Use `null` for sources that are not scheduled for deletion, `not:null` for sources that are. Optional. - **`limit`** `number` Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Optional. Defaults to `"asc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Source[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Source ## Endpoint Retrieve a single source. ```http GET /v1/projects/:project_id/sources/:source_id ``` **Scope:** `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`source_id`** `string` -- **Required** Unique identifier of the source. ## Response Source retrieved ```ts { message: string; data: Source; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create Source ## Endpoint Create a source in a project. ```http POST /v1/projects/:project_id/sources ``` **Scope:** `sources:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** Display name for the source. Minimum length: `1`. Maximum length: `128`. - **`project_id`** `string` Project the source belongs to. Ignored when the nested path supplies it. Optional. ## Response Source created ```ts { message: string; data: Source; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - The project is supplied by the path. - Source names are unique within a project. # Update Source ## Endpoint Update a source. ```http POST /v1/projects/:project_id/sources/:source_id ``` **Scope:** `sources:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`source_id`** `string` -- **Required** Unique identifier of the source. ## Request Body - **`name`** `string` Display name for the source. Optional. Minimum length: `1`. Maximum length: `128`. - **`deleted_at`** `null` Send `null` to restore a source that is scheduled for deletion. The deletion date itself is set by the delete endpoint and cannot be written here. Optional. ## Response Source updated ```ts { message: string; data: Source; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Send `deleted_at` as `null` to restore a source that is scheduled for deletion. # Delete Source ## Endpoint Schedule a source for deletion. ```http DELETE /v1/projects/:project_id/sources/:source_id ``` **Scope:** `sources:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`source_id`** `string` -- **Required** Unique identifier of the source. ## Response ```ts { message: string; data: Source; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The source is hidden immediately and permanently removed 7 days later. Restore it before then by updating it with `deleted_at` set to null. # Force Delete Source ## Endpoint Delete a source permanently, without waiting out its restore window. ```http DELETE /v1/projects/:project_id/sources/:source_id/force ``` **Scope:** `sources:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`source_id`** `string` -- **Required** Unique identifier of the source. ## Response Source queued for permanent deletion. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Works on a live source as well as one already scheduled for deletion. - Every collection, record and file under the source is destroyed immediately. Nothing here can be restored. ## Ingest Keys # Ingest Key Model ## Fields - **`object`** `"ingest_key"` - **`id`** `string` Unique identifier, prefixed with `ik_`. - **`source_id`** `string` The source this key writes into. - **`source_name`** `string | null` - **`url`** `string | null` The Tailglow-issued address to send records to, ready to use. POST your payload to it and append `&collection=` to choose where the records land; a collection is created the first time data arrives for it. Lasts as long as the project does. Null until the project has a provisioned server, which is the only window in which no address reaches it. - **`custom_urls`** `string[]` The same source reached through the team's verified custom ingest domains, one entry each, every one carrying the key exactly as `url` does. Empty when none are configured. Prefer these for browser traffic, where a first-party host survives the blockers that reject a shared analytics domain. An entry disappears if its domain is removed or stops resolving. - **`key`** `string` The credential embedded in `url`. Publishable, in the sense that it belongs in client-side code the way an analytics site tag does. It permits writing records into this source and nothing else: it cannot read, and it carries no access to anything outside this source. - **`status`** [`IngestKeyStatus`](/api/ingest_keys#ingest-key-status) Whether records sent to this URL are still accepted. - **`created_at`** [`ISODateString`](/api/ingest_keys#iso-date-string) - **`last_used_at`** [`ISODateString | null`](/api/ingest_keys#iso-date-string) When data was last received at this URL; null if it has never been used. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### IngestKeyStatus `"active" | "revoked" | "disabled"` # List Ingest Keys ## Endpoint Retrieve every address that can send records to a source. ```http GET /v1/projects/:project_id/sources/:source_id/ingest_keys ``` **Scope:** `ingest_keys:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`source_id`** `string` -- **Required** Unique identifier of the source. ## Query Parameters - **`order_by`** `string` Field used to order the ingest keys. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`, `"status"`. - **`status`** [`IngestKeyStatus`](/api/ingest_keys#ingest-key-status) Filter by whether the URL still accepts records. Optional. - **`project_id`** `string` Filter to URLs whose source belongs to a project. Optional. - **`source_id`** `string` Filter to URLs belonging to a single source. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: IngestKey[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Ingest Key ## Endpoint Retrieve a single ingest key. ```http GET /v1/projects/:project_id/sources/:source_id/ingest_keys/:ingest_key_id ``` **Scope:** `ingest_keys:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`source_id`** `string` -- **Required** Unique identifier of the source. - **`ingest_key_id`** `string` -- **Required** Unique identifier of the ingest key. ## Response Ingest key retrieved ```ts { message: string; data: IngestKey; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create Ingest Key ## Endpoint Create an ingest key for a source. Use this to rotate: create the replacement, deploy it, then delete the old one. ```http POST /v1/projects/:project_id/sources/:source_id/ingest_keys ``` **Scope:** `ingest_keys:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`source_id`** `string` -- **Required** Unique identifier of the source. ## Request Body - **`source_id`** `string` Source the URL writes into. Ignored when the nested path supplies it. Optional. ## Response Ingest key created. ```ts { message: string; data: IngestKey; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - The source is supplied by the path. - The source has to belong to your team. - The full `key` is returned on create and never again. Store it when you receive it. # Delete Ingest Key ## Endpoint Delete an ingest key. Records already sent to it are unaffected; the address stops being accepted. ```http DELETE /v1/projects/:project_id/sources/:source_id/ingest_keys/:ingest_key_id ``` **Scope:** `ingest_keys:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`source_id`** `string` -- **Required** Unique identifier of the source. - **`ingest_key_id`** `string` -- **Required** Unique identifier of the ingest key. ## Response Ingest key deleted ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Deletion is immediate. Anything still sending with this key starts failing straight away. ## Collections # Collection Model ## Fields - **`object`** `"collection"` - **`id`** `string` Unique identifier, prefixed with `col_`. - **`source_id`** `string` - **`source_name`** `string | null` - **`project_id`** `string` - **`slug`** `string` Permanent identifier used in endpoints. Cannot be changed after creation. - **`name`** `string` - **`storage_gb`** `number` Data stored in this collection's files, in gigabytes of uncompressed data. Recalculated hourly. - **`schema_count`** `number` How many schema versions this collection has, in every state. - **`views_count`** `number` How many views read from this collection. - **`drains_count`** `number` How many drains export from this collection. - **`schema_opaque_paths`** `string[][]` Object paths whose contents do not take part in schema identity, one key segment per entry. Records that differ only inside an opaque path share one schema version. Changing this re-keys the collection. - **`schema_tracked_paths`** `string[][]` Children of opaque paths that stay part of schema identity. Changing this re-keys the collection. - **`schema_max_depth`** `number` How many levels of nesting take part in schema identity. Changing this re-keys the collection. - **`schema_nulls`** [`SchemaRuleMode`](/api/collections#schema-rule-mode) `auto` accepts null and absent values where a mapping reads; `manual` waits for a person per view. - **`schema_optional_keys`** [`SchemaRuleMode`](/api/collections#schema-rule-mode) `auto` lets a record with a subset of a version's keys join it; `manual` treats absence as a new shape. - **`schema_detector`** [`SchemaRuleMode`](/api/collections#schema-rule-mode) `auto` applies a safe opaque-path proposal on its own; `manual` holds every proposal for a person. - **`schema_recurrence_gap_ms`** `number` How long after first sight a shape must recur before its version settles, in milliseconds. - **`schema_bulk_rows`** `number` A single batch carrying this many rows of a shape settles its version at once; `0` disables it. - **`schema_stale_after_ms`** `number` How long a candidate version waits to recur before it goes stale, in milliseconds. - **`schema_identity_limit`** `number` How many settled versions the collection may hold; past it, new shapes stay unclassified. - **`schema_candidate_pool`** `number` How many candidate and stale versions the collection may hold; past it, new shapes stay unclassified. - **`schema_alias_pool`** `number` How many exact signature hashes the collection caches for lookup. - **`schema_writer_limit`** `number` How many collection files one ingest batch may open for this collection. Shapes past the candidate pool get the same number of files per batch, the shapes with the most rows first; the rows of shapes past that budget stay unclassified and cannot be linked to a version later. - **`schema_unclassified_retention_days`** `number | null` How many days rows without a settled version are kept; null keeps them forever. - **`deleted_at`** [`ISODateString | null`](/api/collections#iso-date-string) When the collection is scheduled to be deleted; null when it is not. - **`created_at`** [`ISODateString`](/api/collections#iso-date-string) - **`updated_at`** [`ISODateString`](/api/collections#iso-date-string) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### SchemaRuleMode `"auto" | "manual"` # Collection Schema Report ## Fields - **`object`** `"collection_schema_report"` - **`collection_id`** `string` - **`rules`** `{ opaque_paths: string[][]; tracked_paths: string[][]; max_depth: number; }` The rules the report reads the collection's shapes under: the collection's own for the retrieve, the rules sent for a preview. - **`shapes`** `{ before: number; after: number; }` How many shapes the collection holds under its current rules (`before`) and under the report's rules (`after`). Equal unless the report previews a rule change; the difference is what a re-key would merge. - **`proposals`** [`CollectionSchemaProposal[]`](/api/collections#schema-proposal) Where the detector sees keys being invented, with what applying each proposal would do. - **`keys_look_like_data`** `boolean` Whether every shape's top-level keys are its own, such as records keyed by a date. Those keys are values, and no opaque path can bring the shapes together. - **`unclassified`** `{ shapes: number; rows: number; }` Shapes past the collection's pools, stored with their signature but no version, and the rows they carry. Nothing reads them until the pool frees or a rule brings them under a version. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Collection Schema Proposal ## Fields - **`object`** `"collection_schema_proposal"` - **`path`** `string[]` The path the detector proposes opaque, as key segments. - **`tracked`** `string[]` Children of the path every shape carries with one type, which stay in schema identity as tracked paths when the proposal is applied. - **`content_children`** `number` How many children of the path read as content: keys that keep being invented. - **`read_by_mapping`** `boolean` Whether a bound mapping reads inside the path. Applying the proposal would leave that mapping unverified, so the detector never applies such a proposal on its own; a person can. - **`shapes_after`** `number` How many shapes the collection would hold with this proposal applied. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Collections ## Endpoint Retrieve a list of collections for a project. ```http GET /v1/projects/:project_id/collections ``` **Scope:** `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field used to order the collections. Optional. Defaults to `"name"`. Allowed values: `"created_at"`, `"name"`, `"updated_at"`. - **`source_id`** `string` Filter to collections under a single source. Optional. - **`project_id`** `string` Filter to collections in a single project. Optional. - **`deleted_at`** [`NullableDateFilter`](/api/collections#nullable-date-filter) Filter by scheduled deletion date. Use `null` for collections that are not scheduled for deletion, `not:null` for collections that are. Optional. - **`limit`** `number` Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Optional. Defaults to `"asc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Collection[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Collection ## Endpoint Retrieve a single collection. ```http GET /v1/projects/:project_id/collections/:collection_id ``` **Scope:** `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. ## Response Collection retrieved ```ts { message: string; data: Collection; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create Collection ## Endpoint Create a collection under a source. ```http POST /v1/projects/:project_id/collections ``` **Scope:** `sources:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** Display name for the collection. Minimum length: `1`. Maximum length: `128`. - **`slug`** `string` Permanent identifier used in ingest URLs. Derived from `name` when omitted. Optional. Minimum length: `1`. Maximum length: `64`. - **`source_id`** `string` -- **Required** Source the collection is created under. ## Response Collection created ```ts { message: string; data: Collection; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - `source_id` is required. - `slug` is permanent. It appears in the ingest URL, so pick it deliberately. # Update Collection ## Endpoint Update a collection. ```http POST /v1/projects/:project_id/collections/:collection_id ``` **Scope:** `sources:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. ## Request Body - **`name`** `string` Display name for the collection. Optional. Minimum length: `1`. Maximum length: `128`. - **`expected_updated_at`** [`ISODateString`](/api/collections#iso-date-string) Reject this update if the collection changed since this inspected update time. Optional. - **`schema_opaque_paths`** `string[][]` Object paths whose contents do not take part in schema identity, each written as its key segments (`["metadata", "id"]`). A path that names an array covers its elements and their children. Records that differ only inside an opaque path share one schema version; the raw values are still stored. Changing this re-keys the collection. Optional. - **`schema_tracked_paths`** `string[][]` Children of opaque paths that stay part of schema identity, written like `schema_opaque_paths`. Changing this re-keys the collection. Optional. - **`schema_max_depth`** `integer` How many levels of nesting take part in schema identity. Changing this re-keys the collection. Optional. Minimum: `1`. Maximum: `10`. - **`schema_nulls`** `string` `auto` accepts null and absent values at any path a mapping reads; `manual` waits for a person to approve each nullable input per view. Optional. Allowed values: `"auto"`, `"manual"`. - **`schema_optional_keys`** `string` `auto` lets a record whose keys are a subset of a version's keys join that version; `manual` treats every absent key as a different shape. Optional. Allowed values: `"auto"`, `"manual"`. - **`schema_detector`** `string` `auto` applies a safe opaque-path proposal from the detector on its own; `manual` holds every proposal for a person. Optional. Allowed values: `"auto"`, `"manual"`. - **`schema_recurrence_gap_ms`** `integer` How long after first sight a shape must be seen again before its version settles, in milliseconds. Optional. Minimum: `60000`. Maximum: `604800000`. - **`schema_bulk_rows`** `integer` A single batch carrying at least this many rows of a shape settles its version immediately. `0` disables the bulk path. Optional. Minimum: `0`. Maximum: `1000000`. - **`schema_stale_after_ms`** `integer` How long a candidate version waits to be seen again before it goes stale, in milliseconds. Optional. Minimum: `3600000`. Maximum: `7776000000`. - **`schema_identity_limit`** `integer` How many settled schema versions the collection may hold. Past it, new shapes stay unclassified with their signatures kept. Optional. Minimum: `1`. Maximum: `4096`. - **`schema_candidate_pool`** `integer` How many candidate and stale versions the collection may hold. Past it, new shapes stay unclassified. Optional. Minimum: `1`. Maximum: `8192`. - **`schema_alias_pool`** `integer` How many exact signature hashes the collection remembers for fast lookup. Past it, a new hash is still resolved but not cached. Optional. Minimum: `16`. Maximum: `100000`. - **`schema_writer_limit`** `integer` How many collection files one ingest batch may open for this collection. Shapes past the candidate pool get the same number of files per batch, the shapes with the most rows first; the rows of shapes past that budget stay unclassified and cannot be linked to a version later. Optional. Minimum: `1`. Maximum: `256`. - **`schema_unclassified_retention_days`** `integer | null` How many days rows without a settled schema version are kept before they are deleted. `null` keeps them forever. Optional. - **`deleted_at`** `null` Send `null` to restore a collection that is scheduled for deletion. The deletion date itself is set by the delete endpoint and cannot be written here. Optional. ## Response Collection updated ```ts { message: string; data: Collection; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - `slug` cannot be changed after creation. - Send `deleted_at` as `null` to restore a collection that is scheduled for deletion. # Delete Collection ## Endpoint Schedule a collection for deletion. ```http DELETE /v1/projects/:project_id/collections/:collection_id ``` **Scope:** `sources:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. ## Response ```ts { message: string; data: Collection; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The collection is hidden immediately and permanently removed 7 days later. Restore it before then by updating it with `deleted_at` set to null. # Force Delete Collection ## Endpoint Delete a collection permanently, without waiting out its restore window. ```http DELETE /v1/projects/:project_id/collections/:collection_id/force ``` **Scope:** `sources:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. ## Response Collection queued for permanent deletion. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Works on a live collection as well as one already scheduled for deletion. - Every record, schema version and file in the collection is destroyed immediately. # List Collection Schemas ## Endpoint Retrieve the schema versions for a collection. ```http GET /v1/projects/:project_id/collections/:collection_id/schemas ``` **Scope:** `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. ## Query Parameters - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. - **`state`** `string` Return only schema versions in this state. Optional. Allowed values: `"candidate"`, `"settled"`, `"stale"`. ## Response ```ts { message: string; data: CollectionSchemaVersion[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `state` is `candidate` from first sight, `settled` once the shape recurs or arrives in bulk, and `stale` when a candidate is not seen again. Only a settled version is offered to views for authoring. - `after` and `before` are mutually exclusive. # Update Collection Schema ## Endpoint Settle a schema version by hand, so views can author against it before its shape recurs. ```http POST /v1/projects/:project_id/collections/:collection_id/schemas/:schema_version_id ``` **Scope:** `sources:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. - **`schema_version_id`** `string` -- **Required** Unique identifier of the schema. ## Request Body - **`state`** `string` -- **Required** The only state a person sets. `settled` trusts the version for view authoring now, without waiting for its shape to recur; a settled version never goes back. Allowed values: `"settled"`. ## Response Schema version settled ```ts { message: string; data: CollectionSchemaVersion; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - `state` accepts only `settled`; a settled version never returns to candidate or stale. - A version that is already settled is left as it is and responds with `request_no_update`. # Retrieve Collection Schema Report ## Endpoint Retrieve the detector's view of a collection: the opaque paths it proposes, whether the top-level keys are data, and how many shapes sit unclassified past the collection's pools. ```http GET /v1/projects/:project_id/collections/:collection_id/schema_report ``` **Scope:** `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. ## Response Collection schema report retrieved ```ts { message: string; data: CollectionSchemaReport; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - A proposal a bound mapping reads inside is reported and never applied on its own, whatever the detector switch; apply it by adding its path to the collection's `schema_opaque_paths` and its tracked children to `schema_tracked_paths`. - `shapes.before` and `shapes.after` are equal here; the preview is where they differ. # Preview Collection Schema Rules ## Endpoint Preview a rule change: the schema report the collection would read under the rules sent, with how many shapes it holds now and how many it would hold. Nothing is changed. ```http POST /v1/projects/:project_id/collections/:collection_id/schema_preview ``` **Scope:** `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. ## Request Body - **`schema_opaque_paths`** `string[][]` Opaque paths to preview, written like the collection's `schema_opaque_paths`. Omitted, the collection's current opaque paths apply. Optional. - **`schema_tracked_paths`** `string[][]` Tracked paths to preview, written like the collection's `schema_tracked_paths`. Omitted, the collection's current tracked paths apply. Optional. - **`schema_max_depth`** `integer` Max depth to preview. Omitted, the collection's current max depth applies. Optional. Minimum: `1`. Maximum: `10`. ## Response Collection schema rules previewed ```ts { message: string; data: CollectionSchemaReport; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - A rule left out of the body keeps the collection's current value. - `shapes.before` counts the shapes under the collection's current rules and `shapes.after` under the rules sent; the difference is what updating the collection with those rules would merge. # List Collection Documents ## Endpoint Retrieve raw documents from a collection. ```http GET /v1/projects/:project_id/collections/:collection_id/docs ``` **Scope:** `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`collection_id`** `string` -- **Required** Unique identifier of the collection. ## Response ```ts { message: string; data: CollectionDoc[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - Documents are returned exactly as they were sent, minus Tailglow's own reserved envelope. - `after` and `before` are mutually exclusive. ## Views # View Model ## Fields - **`mapping_policy_revision`** `number | null` - **`mapping_policy_nullable_inputs`** `string[]` - **`mapping_policy_fallback_groups`** `string[][]` - **`mapping_policy_allow_drops`** `boolean` - **`mapping_policy_output_bindings`** `Record` - **`mapping_generation`** `number` - **`object`** `"view"` - **`id`** `string` Unique identifier, prefixed with `viw_`. - **`team_id`** `string` - **`project_id`** `string` - **`collection_id`** `string | null` The collection this view reads from; null when it reads from another view. - **`collection_name`** `string | null` Display name of that collection. - **`parent_view_id`** `string | null` The view this one is derived from; null when it reads from a collection. - **`parent_view_name`** `string | null` Display name of that view. - **`view_mode`** `string` Where the view's records come from: a collection, another view, or a join of several. - **`transform_mode`** [`ViewTransformMode`](/api/views#view-transform-mode) Whether transform scripts are generated for new schema versions or written by you. - **`name`** `string` - **`hint`** `string | null` Plain-language guidance the generator uses when it writes transform scripts. - **`output_schema`** `ViewOutputField[]` The fields this view's records contain. - **`status`** [`ViewStatus`](/api/views#view-status) Whether the view is producing records, still being set up, or failed. - **`error_message`** `string | null` Why the view failed, when its status is `error`. - **`waiting_shapes_count`** `number` How many event shapes arrived that no transform serves yet. Their records are stored and catch up automatically once a script covers them; the shapes are listed by the view's deferrals endpoint. - **`deleted_at`** [`ISODateString | null`](/api/views#iso-date-string) When the view is scheduled to be deleted; null when it is not. - **`created_at`** [`ISODateString`](/api/views#iso-date-string) - **`updated_at`** [`ISODateString`](/api/views#iso-date-string) - **`join_base_view_id`** `string | null` The base view on a join view; null on other views. - **`join_base_view_name`** `string | null` - **`join_status`** [`ViewJoinStatus | null`](/api/views#view-join-status) - **`join_backfill_cutoff_at`** [`ISODateString | null`](/api/views#iso-date-string) Records after this instant are joined live. - **`join_live_started_at`** [`ISODateString | null`](/api/views#iso-date-string) When the join started matching new records. - **`join_lookup_progress`** `LookupProgress | null` Lookup progress keyed by clause alias. - **`join_base_file_count`** `number | null` Number of base-view files to backfill. - **`join_base_files_done`** `number | null` Number of base-view files already processed. - **`join_error_message`** `string | null` - **`join_created_at`** [`ISODateString | null`](/api/views#iso-date-string) - **`join_updated_at`** [`ISODateString | null`](/api/views#iso-date-string) - **`joins`** `ViewJoinClause[]` The views joined onto the base view, on a join view. - **`metrics_count`** `number` How many metrics read from this view. - **`derived_views_count`** `number` How many views are derived from this one. - **`join_views_count`** `number` How many join views use this one as an input. - **`transform_count`** `number` How many transforms this view has. - **`drains_count`** `number` How many drains forward this view's records. - **`backfill_file_count`** `number` How many files every transform on this view has to process between them. - **`backfill_files_done`** `number` How many of those files they have processed. - **`backfill_started_at`** [`ISODateString | null`](/api/views#iso-date-string) When the earliest of those backfills began. This is the earliest start across the whole view, which is what a throughput estimate has to measure elapsed time from. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### ViewTransformMode `"auto" | "manual"` ### ViewStatus `"empty" | "building" | "needs_transform" | "active" | "error" | "paused" | "cancelled"` ### ViewJoinStatus `"waiting_for_inputs" | "building_lookups" | "backfilling" | "active" | "error"` # View Transform Model ## Fields - **`object`** `"view_transform"` - **`id`** `string` Unique identifier, prefixed with `vtr_`. - **`view_id`** `string` The view this transform produces records for. - **`transform_script`** `string | null` The TGL script that maps incoming records onto the view's fields; null until one is written. - **`status`** [`ViewTransformStatus`](/api/views#view-transform-status) Whether the transform is running, waiting for a script, or failed. - **`error_message`** `string | null` Why the transform failed, when its status is `error`. - **`tgl_retry_count`** `number` How many times script generation has been retried for this transform. - **`max_read_depth`** `number | null` How many levels deep into a record the script reads. - **`evidence_notice`** `ViewEvidenceNotice | null` Set when a path this mapping read as empty at authoring time has since carried a value with a type, listing those paths as `L:` read keys. Rows keep flowing; re-author the mapping to use the new column. Cleared when a new script is generated. - **`backfill_status`** [`ViewTransformBackfillStatus`](/api/views#view-transform-backfill-status) Whether existing records have been reprocessed through this transform yet. - **`backfill_cutoff_at`** [`ISODateString | null`](/api/views#iso-date-string) Records after this time are handled live rather than by the backfill. - **`backfill_start_at`** [`ISODateString | null`](/api/views#iso-date-string) The earliest record the backfill will reach. - **`backfill_started_at`** [`ISODateString | null`](/api/views#iso-date-string) When the backfill began. - **`backfill_completed_at`** [`ISODateString | null`](/api/views#iso-date-string) When the backfill finished. - **`backfill_file_count`** `number` How many files the backfill has to process. - **`backfill_files_done`** `number` How many of those files it has processed. - **`backfill_error`** `string | null` Why the backfill failed, when it did. - **`assignments`** `ViewTransformAssignment[]` Backfill progress for each source schema version this transform covers. - **`created_at`** [`ISODateString`](/api/views#iso-date-string) - **`updated_at`** [`ISODateString`](/api/views#iso-date-string) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### ViewTransformStatus `"queued" | "analyzing" | "active" | "error" | "draft"` ### ViewTransformBackfillStatus `"pending" | "enqueuing" | "in_progress" | "completed" | "failed" | "cancelled"` # View Version Model ## Fields - **`object`** `"view_version"` - **`id`** `string` Unique identifier, prefixed with `vta_`. - **`view_id`** `string` - **`version`** `number` The source schema version this row covers. Versions rise as the source's shape changes. - **`transform_id`** `string` The transform whose script serves this version. Several versions can share one transform. - **`status`** [`ViewTransformStatus`](/api/views#view-transform-status) Whether the transform is running, waiting for a script, or failed. - **`error_message`** `string | null` Why the transform failed, when its status is `error`. - **`evidence_notice`** `ViewEvidenceNotice | null` Set when a path the serving script read as empty at authoring time has since carried a value with a type; lists those paths as `L:` read keys. Re-author the mapping to use the new column. Cleared when a new script is generated. - **`script_hash`** `string | null` Identity of the script text. Versions sharing a hash run the identical script. - **`script`** `string | null` The TGL script serving this version; null until one is written. - **`backfill_status`** [`ViewTransformBackfillStatus`](/api/views#view-transform-backfill-status) Whether the records already on this schema version have been reprocessed yet. - **`backfill_start_at`** [`ISODateString | null`](/api/views#iso-date-string) The earliest record the backfill will reach. - **`backfill_started_at`** [`ISODateString | null`](/api/views#iso-date-string) When the backfill began. - **`backfill_completed_at`** [`ISODateString | null`](/api/views#iso-date-string) When the backfill finished. - **`backfill_file_count`** `number` How many files the backfill has to process for this version. - **`backfill_files_done`** `number` How many of those files it has processed. - **`backfill_error`** `string | null` Why the backfill failed, when it did. - **`created_at`** [`ISODateString`](/api/views#iso-date-string) When the view started covering this schema version. - **`updated_at`** [`ISODateString`](/api/views#iso-date-string) When the transform serving this version last changed. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### ViewTransformStatus `"queued" | "analyzing" | "active" | "error" | "draft"` ### ViewTransformBackfillStatus `"pending" | "enqueuing" | "in_progress" | "completed" | "failed" | "cancelled"` # Waiting Shape Model ## Fields - **`episode`** `number` - **`observation_count`** `string | null` - **`retained_rows`** `number` - **`first_observed_at`** [`ISODateString | null`](/api/views#iso-date-string) - **`last_observed_at`** [`ISODateString | null`](/api/views#iso-date-string) - **`next_action_at`** [`ISODateString | null`](/api/views#iso-date-string) - **`hint_question`** `string | null` - **`hint_reason`** `string | null` - **`hint_paths`** `string[]` - **`hint_requested_at`** `string | null` - **`hint_mapping_generation`** `number | null` - **`exclusion_reason`** `string | null` - **`excluded_at`** [`ISODateString | null`](/api/views#iso-date-string) - **`transform_id`** `string | null` - **`object`** `"view_shape_deferral"` - **`id`** `string` Unique identifier, prefixed with `vsd_`. - **`view_id`** `string` - **`full_signature`** `string` The typed signature identifying the event shape. - **`event_count`** `number` Roughly how many events of the shape arrived while it was waiting; retries can count an event more than once. - **`first_event_at`** [`ISODateString | null`](/api/views#iso-date-string) The earliest event time seen for the shape. Completeness reporting pins to this instant. - **`first_deferred_at`** [`ISODateString`](/api/views#iso-date-string) - **`last_deferred_at`** [`ISODateString`](/api/views#iso-date-string) - **`resolved_at`** [`ISODateString | null`](/api/views#iso-date-string) When the shape became served; null while it is still waiting. - **`reason`** [`ViewShapeDeferralReason`](/api/views#view-shape-deferral-reason) Why the shape is waiting: `collecting_samples` until enough evidence is available to author a mapping, `awaiting_script` until a transform covers it, `generation_failed` when script generation gave up, `catching_up` while its records backfill, `served` once resolved. - **`schema_version`** `number | null` The schema version the shape belongs to. Null while no version is linked to it. - **`created_at`** [`ISODateString`](/api/views#iso-date-string) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### ViewShapeDeferralReason `"collecting_samples" | "needs_decision" | "needs_hint" | "manual_mapping" | "generating" | "budget_limited" | "shape_overflow" | "runtime_error" | "excluded" | "recovery_pending" | "awaiting_script" | "generation_failed" | "catching_up" | "served"` What unblocks a waiting shape. # Shape Inspection Model ## Fields - **`view_id`** `string` - **`deferral_id`** `string` - **`episode`** `number` - **`mapping_generation`** `number` - **`version`** `number | null` - **`signatures`** `Record` - **`decision`** `ViewMappingReuseDecision` - **`candidates`** `{ transform_id: string; verdict: string; reason: string; exact_paths: string[]; present_null_paths: string[]; absent_paths: string[]; incompatible_paths: string[]; substitution_paths: string[]; unknown_paths: string[]; bindings: Record<...>; }[]` ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Waiting Shape Hint Model ## Fields - **`question`** `string` - **`reason`** `string` - **`paths`** `string[]` Verified JSON bracket paths such as $["account"]["id"], with literal key characters escaped. - **`requested_at`** `string` - **`mapping_generation`** `number` - **`view_id`** `string` - **`deferral_id`** `string` - **`episode`** `number` - **`transform_id`** `string` ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Views ## Endpoint Retrieve a list of views for a project. ```http GET /v1/projects/:project_id/views ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field the results are sorted by. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`, `"name"`, `"updated_at"`. - **`project_id`** `string` Return only views in this project. Optional. - **`collection_id`** `string` Return only views reading from this collection. Optional. - **`parent_view_id`** `string` Return only views derived from this view. Optional. - **`deleted_at`** [`NullableDateFilter`](/api/views#nullable-date-filter) Filter on deletion state. Soft-deleted views are excluded unless you ask for them. Optional. - **`limit`** `number` Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Optional. Defaults to `"asc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: View[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve View ## Endpoint Retrieve a single view. ```http GET /v1/projects/:project_id/views/:view_id ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Response View retrieved ```ts { message: string; data: View; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create View ## Endpoint Create a view that transforms records from a collection or another view. ```http POST /v1/projects/:project_id/views ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** Name for the view. Minimum length: `1`. Maximum length: `128`. - **`output_schema`** `object[]` The fields this view produces. Can be left until transforms define it. Optional. - **`hint`** `string | null` Instructions the generator cannot infer from field names alone, such as a formatting rule or a business threshold. Optional. - **`mapping_policy`** `object` Optional. - **`project_id`** `string` Project ID. Optional when using the /projects/:project/views route. Optional. - **`collection_id`** `string` Collection to derive from, when reading raw ingested records. Optional. - **`parent_view_id`** `string` View to derive from, when deriving from a view. Optional. - **`transform_script`** `string` TGL transform script. When set, the view skips automatic TGL generation. Optional. Minimum length: `1`. Maximum length: `65536`. - **`transform_mode`** `string` Whether a new schema version that no existing transform covers gets a script generated for it, or waits for you to write one. Defaults to auto. Optional. Allowed values: `"auto"`, `"manual"`. ## Response View created ```ts { message: string; data: View; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - A view reads from exactly one source: a collection, or another view to derive from. - The output schema defines the fields the view produces. A transform is created alongside the view to populate them. - Leaving the transform script empty queues it for generation instead of rejecting it, so a view can be created before its TGL is written. - Backfilling existing records starts shortly after creation and runs in the background. The view reports its progress while it catches up. - A view reads from exactly one place: set `collection_id` to derive from raw ingested records, or `parent_view_id` to derive from another view. Setting both, or neither, is rejected. - There is no `source_id` on this endpoint. One source can hold many collections, and the collection is what owns the schema and the records a view transforms. List a source's collections with `GET /v1/projects/:project/collections?source_id=...` and pass the one you want. - `output_schema` field names must be unique by name, cannot conflict on type, and cannot collide with a reserved query key such as `limit` or `cursor`. - `transform_script` cannot be whitespace-only. Supplying one activates the view's first transform immediately and skips automatic TGL generation. - Use `hint` for rules the generator cannot read off the field names: a formatting rule ("display_name should be Name (Type)"), a business threshold ("classify as high above 500"), or a disambiguation when a source field could map more than one way. Skip it for obvious mappings like renames and type conversions, which the generator already handles. # Create Join View ## Endpoint Create a view that joins two existing views on a shared key. ```http POST /v1/projects/:project_id/views/join ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** Name shown for this join view. Minimum length: `1`. Maximum length: `128`. - **`project_id`** `string` Project the join view belongs to. Optional. - **`base_view_id`** `string` -- **Required** View every output record starts from. Minimum length: `1`. - **`joins`** `object[]` -- **Required** Views joined onto the base view, each with its own match fields. - **`output_schema`** `object[]` Fields the join produces. Leave empty to have one inferred. Optional. Defaults to `[]`. - **`transform_script`** `string` TGL transform script. Omit to have one generated. Optional. Minimum length: `1`. Maximum length: `65536`. - **`hint`** `string` Instructions the generator cannot infer from field names alone, such as a formatting rule or a business threshold. Optional. Maximum length: `4096`. ## Response Join view created ```ts { message: string; data: View; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - Both sides must be views in this project. Join a collection by creating a view over it first. - The join key must exist in the output schema of both sides. - A join view rebuilds when either side produces new records, so it trails its inputs rather than updating in the same instant. - Records are enriched with each joined view's latest value, by record timestamp, at the time they are processed. Records already produced are not revisited. - Each join clause's `alias` must be lowercase letters, digits and underscores, and start with a letter. It is how the clause's fields are addressed in the transform script. - `transform_script` cannot be whitespace-only. Omit it entirely to have one generated. - Use `hint` for rules the generator cannot read off the field names: a formatting rule ("display_name should be Name (Type)"), a business threshold ("classify as high above 500"), or a disambiguation when an input field could map more than one way. Skip it for obvious mappings like renames and type conversions, which the generator already handles. # Update View ## Endpoint Update a view's name or output schema. ```http POST /v1/projects/:project_id/views/:view_id ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Request Body - **`mapping_policy`** `object` Optional. - **`name`** `string` Name for the view. Optional. Minimum length: `1`. Maximum length: `128`. - **`output_schema`** `object[]` The fields this view produces. Can be left until transforms define it. Optional. - **`hint`** `string | null` Instructions the generator cannot infer from field names alone, such as a formatting rule or a business threshold. Optional. - **`transform_mode`** `string` Whether a new schema version that no existing transform covers gets a script generated for it, or waits for you to write one. Optional. Allowed values: `"auto"`, `"manual"`. - **`view_transform_id`** `string` Which transform adopts the schema versions still waiting for a script when switching transform_mode to manual. Required only when the view has more than one distinct transform script. Optional. - **`deleted_at`** `null` Send `null` to restore a view that is scheduled for deletion. The deletion date itself is set by the delete endpoint and cannot be written here. Optional. ## Response View updated ```ts { message: string; data: View; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Output schema changes are accepted only before a mapping or stored output exists. Changing an existing view's output schema requires a recovery transition that is not yet supported. - Mapping policy changes on an existing mapping require reviewed coverage recovery. Hint changes preserve accepted mappings and retry undecided work with the new hint. - What a view reads from is fixed at creation, so `collection_id` and `parent_view_id` are not accepted here. Create a new view to read from something else. - `output_schema` field names must be unique by name, cannot conflict on type, and cannot collide with a reserved query key such as `limit` or `cursor`. - Use `hint` for rules the generator cannot read off the field names: a formatting rule ("display_name should be Name (Type)"), a business threshold ("classify as high above 500"), or a disambiguation when a source field could map more than one way. Skip it for obvious mappings like renames and type conversions, which the generator already handles. # Delete View ## Endpoint Delete a view and every view derived from it. ```http DELETE /v1/projects/:project_id/views/:view_id ``` **Scope:** `views:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Response ```ts { message: string; data: View; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Views derived from this one are deleted with it. - The delete is refused while an active drain reads from this view or from any view that would cascade with it. Delete those drains first. Draft drains are removed silently. - Backfill and indexing work for the whole cascade is cancelled immediately, so a deleted view stops consuming capacity before its rows are removed. # Force Delete View ## Endpoint Delete a view permanently, without waiting out its restore window. ```http DELETE /v1/projects/:project_id/views/:view_id/force ``` **Scope:** `views:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Response View queued for permanent deletion. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Works on a live view as well as one already scheduled for deletion. - Views derived from this one go with it, and the rollups of any metric reading them are destroyed. The records they were built from are not affected, so both can be rebuilt. # List View Records ## Endpoint Retrieve the transformed records a view has produced. ```http GET /v1/projects/:project_id/views/:view_id/records ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Response ```ts { message: string; data: ViewRecord[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - Records are only filterable on fields that have a facet. Filtering on any other field is rejected, so create a facet for a field before querying it. - Paging is forward-only. Pass `pagination.next_cursor` back as `after` to get the next page; a null `next_cursor` means there is nothing more to read. No `prev_cursor` is issued, and `before` is ignored. - A cursor is only valid for the query that produced it. Changing the sort direction, the filter, or (on a filtered read) the time range and reusing an older cursor returns a 400 rather than a page of skipped or repeated records, so start again without a cursor after any of those change. - `start_at` and `end_at` narrow a filtered read only. An unfiltered read returns the view's records regardless of the window, so pass a facet filter when you need a time-bounded result. - A cursor stays valid while Tailglow reorganizes stored data in the background, so a paging client is never interrupted by storage maintenance. It is a position in this result set, not a snapshot: records that arrive while you page appear only if they sort after your position. - `after` and `before` are mutually exclusive. # List Waiting Shapes ## Endpoint Retrieve the event shapes a view has deferred because no transform serves them yet. ```http GET /v1/projects/:project_id/views/:view_id/deferrals ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Query Parameters - **`resolved`** `string` Filter by resolution. `false` returns only shapes still waiting. Optional. Allowed values: `"true"`, `"false"`. - **`order_by`** `string` Sort field. Defaults to `last_deferred_at`. Optional. Allowed values: `"first_deferred_at"`, `"last_deferred_at"`. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: ViewShapeDeferral[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - Deferred records are stored, not lost. They backfill automatically once a script covers the shape, and each entry's `reason` says what unblocks it. - `event_count` is approximate: ingest retries can count an event more than once. - `after` and `before` are mutually exclusive. # Inspect Waiting Shape ## Endpoint Inspect structural differences and candidate output bindings for a waiting shape. ```http GET /v1/projects/:project_id/views/:view_id/deferrals/:deferral_id ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`deferral_id`** `string` -- **Required** Unique identifier of the deferral. ## Response Waiting shape inspected ```ts { message: string; data: ViewShapeInspection; status: 200; error: null; pagination: null; endpoint: string; } ``` # Retrieve Waiting Shape Hint ## Endpoint Retrieve the model's current binding question for a waiting shape. ```http GET /v1/projects/:project_id/views/:view_id/deferrals/:deferral_id/hint ``` **Scopes:** `views:read` + `sources:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`deferral_id`** `string` -- **Required** Unique identifier of the deferral. ## Response 200 (1) No pending hint question ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Response 200 (2) Waiting shape hint retrieved ```ts { message: string; data: ViewPendingHint; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Requires both views:read and sources:read because model prose may refer to source records. Suggested paths are verified source fields in unambiguous JSON bracket notation. - Returns null when no current question remains. Answer using this question's episode, mapping_generation, requested_at, and transform_id. # Decide Waiting Shape ## Endpoint Resolve the next action for one view and schema version. ```http POST /v1/projects/:project_id/views/:view_id/deferrals/:deferral_id/decision ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`deferral_id`** `string` -- **Required** Unique identifier of the deferral. ## Request Body - **`episode`** `integer` -- **Required** The deferral episode shown when the decision was inspected. Minimum: `1`. - **`action`** `string` -- **Required** Authorize a bounded authoring attempt, answer a hint, or exclude this exact version in this view. Allowed values: `"author"`, `"hint"`, `"exclude"`. - **`mapping_generation`** `integer` -- **Required** The mapping generation shown when the decision was inspected. Minimum: `1`. - **`hint`** `string` Answer to the model's binding question. Optional. Minimum length: `1`. Maximum length: `4096`. - **`hint_requested_at`** [`ISODateString`](/api/views#iso-date-string) Exact requested_at of the pending hint being answered. Optional. - **`hint_transform_id`** `string` Transform that owns the pending hint being answered. Optional. Minimum length: `1`. Maximum length: `32`. - **`reason`** `string` Required audit reason for an exclusion. Optional. Minimum length: `1`. Maximum length: `2000`. - **`mapping_policy`** `object` Explicit null, fallback, drop, and source-binding rules. Optional. ## Response ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Authoring and hint answers reserve a bounded model budget. Exclusion covers unprocessed and future records of this exact version in this view. - Answering a hint requires `hint`; excluding a version requires `reason`. Exclusion covers unprocessed and future records with this exact schema version in this view. - Answering a pending model question also requires its exact `hint_requested_at` and `hint_transform_id`. Superseded or answered questions return a conflict; manual guidance without a pending question may omit both fields. # List View Transforms ## Endpoint Retrieve a list of a view's transforms. ```http GET /v1/projects/:project_id/views/:view_id/transforms ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Query Parameters - **`order_by`** `string` Field the results are sorted by. Creation order matches schema version order. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`, `"updated_at"`. - **`status`** [`ViewTransformStatus`](/api/views#view-transform-status) Return only transforms in this state. Optional. - **`limit`** `number` Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Optional. Defaults to `"asc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: ViewTransform[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve View Transform ## Endpoint Retrieve a single transform. ```http GET /v1/projects/:project_id/views/:view_id/transforms/:transform_id ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`transform_id`** `string` -- **Required** Unique identifier of the transform. ## Response Transform retrieved ```ts { message: string; data: ViewTransform; status: 200; error: null; pagination: null; endpoint: string; } ``` # List View Versions ## Endpoint Retrieve a list of the schema versions a view covers. ```http GET /v1/projects/:project_id/views/:view_id/versions ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Query Parameters - **`order_by`** `string` Field the results are sorted by. Optional. Defaults to `"version"`. Allowed values: `"version"`. - **`status`** [`ViewTransformStatus`](/api/views#view-transform-status) Return only versions whose transform is in this state. Optional. - **`script_hash`** `string` Return only versions served by this script. Take the value from a version's row. Optional. Minimum length: `64`. Maximum length: `64`. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: ViewVersion[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - One row per source schema version the view covers, newest version first. A view that reads another view has no schema versions, so its list is empty. - Versions sharing a `script_hash` run the same transform. Filter by it to see every version one script serves. - `after` and `before` are mutually exclusive. # Retrieve View Version ## Endpoint Retrieve one schema version a view covers. ```http GET /v1/projects/:project_id/views/:view_id/versions/:version_id ``` **Scope:** `views:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`version_id`** `string` -- **Required** Unique identifier of the version. ## Response Version retrieved ```ts { message: string; data: ViewVersion; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - `version_id` is the schema version NUMBER, the `version` a row carries, not a `vta_` id. # Create View Transform ## Endpoint Add a transform that maps incoming records into the view's output schema. ```http POST /v1/projects/:project_id/views/:view_id/transforms ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Request Body - **`collection_schema_version`** `integer | null` Collection schema version this transform covers. Null for view-to-view transforms. Optional. - **`transform_script`** `string` TGL transform script. Omit to have one generated. Optional. Minimum length: `1`. Maximum length: `65536`. ## Response Transform created ```ts { message: string; data: ViewTransform; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - `transform_script` is TGL and must compile. A script that does not parse is rejected rather than stored, because an unparseable script would fail on every record it later touched. - The script must write every field the view's output schema declares. - Omitting the script queues the transform for generation instead of rejecting it. - A transform on a collection-backed view must name the `collection_schema_version` it covers. View-to-view transforms pass null, because they read another view's output rather than a collection schema. - `transform_script` cannot be whitespace-only. Omit it to have TGL generated instead. # Update View Transform ## Endpoint Update a transform's script. ```http POST /v1/projects/:project_id/views/:view_id/transforms/:transform_id ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`transform_id`** `string` -- **Required** Unique identifier of the transform. ## Request Body - **`transform_script`** `string` TGL transform script. To clear and regenerate, use the regenerate endpoint instead. Optional. Minimum length: `1`. Maximum length: `65536`. - **`conflict_resolution`** `string` How conflicting schema versions are handled when a script edit fans out. Optional. Defaults to `"strand"`. Allowed values: `"strand"`, `"keep"`. - **`dry_run`** `boolean` Preview the edit: returns the per-version verdict report without changing anything. Optional. Defaults to `false`. - **`preview_token`** `string` The `edit_report.preview_token` from this edit's dry run. Required to save: it pins the save to the set of schema versions the preview reported on, so a version assigned or reassigned in between is rejected instead of silently included. Optional. Minimum length: `1`. Maximum length: `128`. ## Response 200 (1) ```ts { message: string; data: ViewTransform & { edit_report: { script_hash: string | null; version_verdicts: { collection_schema_version_id: string; version: number; verdict: "compatible" | "conflict"; action: "updated" | "kept" | "stranded"; null_paths: string[]; }[]; preview_token?: string | undefined; } }; status: 200; error: null; pagination: null; endpoint: string; } ``` ### Additional Response Fields - **`edit_report`** `{ script_hash: string | null; version_verdicts: { collection_schema_version_id: string; version: number; verdict: "compatible" | "conflict"; action: "updated" | "kept" | "stranded"; null_paths: string[]; }[]; preview_token?: string | undefined; }` -- **Required** ## Response 200 (2) Transform updated ```ts { message: string; data: ViewTransform & { edit_report: { script_hash: string | null; version_verdicts: never[]; } }; status: 200; error: null; pagination: null; endpoint: string; } ``` ### Additional Response Fields - **`edit_report`** `{ script_hash: string | null; version_verdicts: never[]; }` -- **Required** ## Comments - `transform_script` is TGL and must compile, and must write every field the view's output schema declares. - On collection-backed views, an edit fans out to every schema version using the same prior script and returns a verdict for each version. Additive reads report paths that produce null. - Conflicting versions are moved to queued placeholders by default. Set `conflict_resolution` to `keep` to leave those versions on their prior script. - Removing an output field is rejected while a metric, facet, child view, or join clause reads it. Consumer checks use the complete nested output path. Records already produced keep their existing values until the transform is re-backfilled. - Set `dry_run` to preview the per-version verdict report without saving. A dry run changes nothing and triggers nothing, and returns a `preview_token` alongside the report. - Saving requires the `preview_token` from that dry run. It pins the save to the set of schema versions the report described, so a version added or reassigned between the preview and the save cannot be silently included. - A save with a missing or outdated token is rejected with 409 and changes nothing. The error carries the report as it stands now, so the next preview is already in hand. - `transform_script` cannot be whitespace-only. To clear a script and have it regenerated, use the regenerate endpoint rather than sending an empty one. - Saving is a two-step gesture: send `dry_run` to get the report and its `preview_token`, then send the same edit with that token. A save without one, or with a token whose set has since changed, is rejected with 409 and a fresh report. # Generate View Transform Script ## Endpoint Queue TGL generation for a transform from the view's input and output schemas. ```http POST /v1/projects/:project_id/views/:view_id/transforms/:transform_id/generate ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`transform_id`** `string` -- **Required** Unique identifier of the transform. ## Response TGL generation queued ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Generation runs in the background. This returns once the work is queued, not once a script exists; poll the transform to see the result. - The generated script is written to the transform and replaces whatever was there. # Re-backfill View Transform ## Endpoint Re-run a transform over every record the view has already read. ```http POST /v1/projects/:project_id/views/:view_id/transforms/:transform_id/rebackfill ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`transform_id`** `string` -- **Required** Unique identifier of the transform. ## Response Transform re-backfill started ```ts { message: string; data: ViewTransform; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Use this after editing a script so existing records pick up the new logic. Without it, an edit only affects records that arrive afterwards. - The re-backfill runs in the background and replaces the view's output as it progresses. Anything reading the view sees a mix of old and new values until it finishes. - Metrics and views that depend on this one are rebuilt as well. # Regenerate View ## Endpoint Replace a view's output schema and queue every transform to be regenerated against it. ```http POST /v1/projects/:project_id/views/:view_id/regenerate ``` **Scope:** `views:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. ## Request Body - **`output_schema`** `object[]` The fields the view should produce. Omit to regenerate against the current schema. Optional. - **`hint`** `string | null` Instructions the generator cannot infer from field names alone, such as a formatting rule or a business threshold. Optional. ## Response View schema updated and transforms queued for regeneration ```ts { message: string; data: View; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - This is the schema-change path: it updates the output schema and re-queues the view's transforms in one step, so the scripts are rewritten to produce the new fields. - Existing records keep their old shape until the regenerated transforms backfill over them. - `output_schema` field names must be unique by name, cannot conflict on type, and cannot collide with a reserved query key such as `limit` or `cursor`. - Use `hint` for rules the generator cannot read off the field names: a formatting rule ("display_name should be Name (Type)"), a business threshold ("classify as high above 500"), or a disambiguation when a source field could map more than one way. Skip it for obvious mappings like renames and type conversions, which the generator already handles. # Delete View Transform ## Endpoint Delete a transform from a view. ```http DELETE /v1/projects/:project_id/views/:view_id/transforms/:transform_id ``` **Scope:** `views:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`view_id`** `string` -- **Required** Unique identifier of the view. - **`transform_id`** `string` -- **Required** Unique identifier of the transform. ## Response Transform deleted ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Records the transform already produced are left in place. Re-backfill the view's remaining transforms to rebuild its output without this one. ## Metrics # Metric Model ## Fields - **`object`** `"metric"` - **`id`** `string` - **`name`** `string` - **`team_id`** `string` - **`project_id`** `string` - **`deleted_at`** [`ISODateString | null`](/api/metrics#iso-date-string) When the metric is scheduled to be deleted; null when it is not. - **`view_id`** `string` The view whose records the metric aggregates. Changing it to a compatible view in the same project rebuilds the metric's historical data. - **`status`** [`MetricStatus`](/api/metrics#metric-status) Current lifecycle state for live collection and historical backfill. - **`group_by`** `string[]` View fields whose value combinations define distinct metric series. - **`filters`** `string` Filter expression applied to records before aggregation. - **`timestamp_field`** `string` View field used as the aggregation timestamp. - **`value_field`** `string | null` View field used as the numeric aggregation value. - **`unique_field`** `string | null` View field used for distinct-value counts. - **`null_handling`** [`NullHandling`](/api/metrics#null-handling) How null or missing metric values are aggregated. - **`empty_bucket_handling`** [`EmptyBucketHandling`](/api/metrics#empty-bucket-handling) How chart buckets without observations are represented. - **`group_by_display_fields`** `Record | null` Display labels for the fields in `group_by`. - **`backfill_strategy`** [`BackfillStrategy`](/api/metrics#backfill-strategy) Order used when historical data is rebuilt. - **`ui_chart_family`** [`ChartFamily`](/api/metrics#chart-family) Read-only: derived from `ui_chart_type`, grouping chart types by layout family. - **`ui_chart_type`** [`ChartType`](/api/metrics#chart-type) - **`ui_chart_color_mode`** [`ChartColorMode`](/api/metrics#chart-color-mode) Strategy used to assign chart colors. - **`ui_chart_color_base`** `string | null` Base color used by intensity mode, one of `CHART_COLORS`. Null when the color mode does not use one. - **`ui_chart_color_rules`** `MetricColorRule[] | null` Ordered value-to-color rules used by value mode. - **`ui_chart_curve`** [`ChartCurve`](/api/metrics#chart-curve) Line interpolation style. - **`ui_chart_show_alerts`** `boolean` Whether the chart displays alert markers. - **`ui_chart_compact_values`** `boolean` Whether chart tooltips round values to compact notation, such as 321.3M. - **`ui_chart_y_min`** `number | null` Fixed lower bound for the y axis. Null lets the axis fit the data. - **`ui_chart_y_max`** `number | null` Fixed upper bound for the y axis. Null lets the axis fit the data. - **`ui_chart_show_monitors`** `boolean` Whether the chart displays monitor thresholds. - **`ui_chart_show_trends`** `boolean` Whether the chart displays regression trends. - **`ui_chart_show_forecast`** `boolean` Whether the chart opens with its forecast shown, projecting the fitted trend past now to the saved horizon. Viewers in the app can change the forecast for their own view without changing this setting. - **`ui_chart_forecast_horizon`** [`ForecastHorizon`](/api/metrics#forecast-horizon) How far past now the chart projects when it draws a forecast. Relative values resolve against the moment the chart is viewed, not the moment they were saved. - **`ui_chart_forecast_model`** [`ForecastModel`](/api/metrics#forecast-model) Curve the forecast is fitted with. `auto` follows whichever model fits the series best at view time, so the projected shape can change as data arrives. - **`ui_value_unit`** `string | null` Unit label displayed with chart values. - **`ui_chart_value`** [`MetricChartValue`](/api/metrics#metric-chart-value) Aggregation value displayed by default. - **`ui_chart_time_range`** [`AnalyticsTimeRange`](/api/metrics#analytics-time-range) Window the chart covers by default. - **`ui_chart_interval`** [`ChartInterval`](/api/metrics#chart-interval) Bucket size the chart uses by default. - **`ui_chart_custom_range_start_at`** [`ISODateString | null`](/api/metrics#iso-date-string) Start of the custom chart range. - **`ui_chart_custom_range_end_at`** [`ISODateString | null`](/api/metrics#iso-date-string) End of the custom chart range. - **`ui_chart_max_series`** `number` Maximum number of individual series displayed by default. - **`created_at`** [`ISODateString`](/api/metrics#iso-date-string) - **`updated_at`** [`ISODateString`](/api/metrics#iso-date-string) - **`backfill_percent`** `number` Percentage of the view's data files the historical backfill has processed. - **`backfill_total_count`** `number` How many of the view's data files the historical backfill has to process. Seeded as 1 before the run is planned. - **`backfill_completed_count`** `number` How many of those files it has processed. - **`backfill_completed_at`** [`ISODateString | null`](/api/metrics#iso-date-string) Null until the backfill finishes. - **`backfill_started_at`** [`ISODateString | null`](/api/metrics#iso-date-string) Null until the backfill starts. - **`compact_percent`** `number` Percentage of rollup-building steps completed. - **`compact_total_count`** `number` How many rollup-building steps the run has planned; 0 until that pass starts. - **`compact_completed_count`** `number` How many of those steps are done. - **`compact_started_at`** [`ISODateString | null`](/api/metrics#iso-date-string) Null until the rollup-building pass starts. - **`has_triggered_monitors`** `boolean` Whether at least one alert is currently open. Ended alerts remain in history. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### MetricStatus `"initializing" | "waiting_for_transforms" | "backfilling" | "active" | "error" | "cancelled"` ### NullHandling `"skip" | "count_as_zero"` ### EmptyBucketHandling `"zero" | "gaps"` ### BackfillStrategy `"newest_first" | "oldest_first"` ### ChartFamily `"cartesian" | "radial" | "geographic" | "temporal" | "hierarchical"` ### ChartType `"line" | "area" | "bar" | "pie" | "scatter" | "radar" | "stat" | "gauge" | "calendar" | "uptime"` ### ChartColorMode `"by_series" | "by_intensity" | "by_value"` ### ChartColor `"blue" | "red" | "amber" | "green" | "teal" | "purple" | "pink"` ### ChartCurve `"linear" | "smooth" | "step"` ### ForecastHorizon `"next_7_days" | "next_30_days" | "next_90_days" | "end_of_quarter" | "end_of_year" | "next_year"` How far past now a chart projects its forecast. Values are relative to the moment the chart is viewed, so a saved horizon keeps projecting the same distance ahead as time passes rather than expiring on a fixed date. `end_of_quarter` and `end_of_year` run to the end of the calendar period that contains today, in UTC. ### ForecastModel `"auto" | "linear" | "exponential" | "logarithmic" | "logistic" | "sinusoidal"` The curve a forecast is fitted with. `auto` follows the best-fitting model for the series, which is recalculated as data arrives and can therefore change between views; naming a model pins the projection to that curve. ### MetricChartValue `"count" | "average" | "min" | "max" | "sum" | "last" | "cumulative_count" | "cumulative_sum" | "p50" | "p95" | "p99" | "count_unique"` Aggregation applied to a metric's values. Use `last` when records are snapshots of a persistent thing such as a deal, user, or inventory item: each time bucket contains the latest reading for that series in the bucket. Within the requested range, the last observed value carries forward across complete empty intervals instead of reading them as zero. ### AnalyticsTimeRange `"last_hour" | "last_6_hours" | "today" | "last_24_hours" | "yesterday" | "this_week" | "last_week" | "this_month" | "last_month" | "this_quarter" | "last_quarter" | "this_year" | "last_year" | "last_7_days" | "last_30_days" | "last_90_days" | "last_365_days" | "all_time" | "custom" | "next_7_days" | "next_30_days" | "next_90_days"` The window a chart reads. Stored as a plain string rather than a database enum: the set is presentation, not something any query filters on, and the forward ranges in particular are expected to change as we learn what people forecast over. A `next_*` range ends after now, which is what turns a fitted trend into a visible forecast. The measured half of such a range is still measured; only the part past now is projected. ### ChartInterval `"minute" | "hour" | "day" | "month" | "auto"` The Data Interval _setting_ (`Metric.ui_chart_interval` and the aggregation `interval` query param). `"auto"` means the server picks the finest-safe tier for the current view, so brush-zoom naturally drills into a finer bucket. The RESOLVED tier returned by aggregation is always a plain `DataInterval`. # Timeseries Aggregation Model ## Fields - **`object`** `"aggregation"` - **`coverage_mode`** `"strict" | "observed" | null` Null for telemetry endpoints without a metric completeness contract. - **`coverage_reasons`** `{ view_id: string; view_name: string; reason: string; count: number | null; }[]` Count is null when the reason reports a status rather than a measured count. - **`start_at`** [`ISODateString`](/api/metrics#iso-date-string) - **`end_at`** [`ISODateString`](/api/metrics#iso-date-string) - **`interval`** [`DataInterval`](/api/metrics#data-interval) Bucket size each entry in a series' `records` covers. - **`values`** [`MetricChartValue[]`](/api/metrics#metric-chart-value) Declares what each number in a series' `records` arrays means; positions align. - **`series`** [`MetricSeries[]`](/api/metrics#aggregation-series-model) One entry per charted series. An explicit series filter returns exactly those series; otherwise pinned series are kept and every other series folds into a synthetic `__other__` entry, and with no pins the top series by value are kept up to the chart's limit. - **`series_total`** `number` Distinct real series permutations that had data in the requested range before the server folded the tail into the synthetic `__other__` series. Always present; equals the named series count when nothing folds. Clients subtract the number of named series they display to size the single "Other (N)" row and its warning, instead of counting the (already-folded) `series` array. - **`complete_through_at`** [`ISODateString | null`](/api/metrics#iso-date-string) Everything before this instant is final. Later buckets may still be filling in while ingest, transforms, or backfills catch up, so treat them as provisional. Null when no statement can be made, which is not the same as complete. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### DataInterval `"minute" | "hour" | "day" | "month"` ### MetricChartValue `"count" | "average" | "min" | "max" | "sum" | "last" | "cumulative_count" | "cumulative_sum" | "p50" | "p95" | "p99" | "count_unique"` Aggregation applied to a metric's values. Use `last` when records are snapshots of a persistent thing such as a deal, user, or inventory item: each time bucket contains the latest reading for that series in the bucket. Within the requested range, the last observed value carries forward across complete empty intervals instead of reading them as zero. # Aggregation Series Model ## Fields - **`details`** `{ label: string; hash: string; dimensions: Record; color: string | null; }` The series' identity (`hash`, `dimensions`) and current presentation (`label`, `color`). - **`records`** `Record` One entry per bucket, values aligned with the aggregation's `values` list. `null` means the bucket had no data and the metric's `empty_bucket_handling` is `gaps`. - **`regression`** `LinearRegression | ExponentialRegression | LogarithmicRegression | LogisticRegression | SinusoidalRegression | null` Trend line fitted over the series; null when none was computed. - **`forecast`** `RegressionForecast | null` The trend line's projected next value; null when no trend was computed. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Metric Series Model ## Fields - **`object`** `"metric_series"` - **`id`** `string` - **`metric_id`** `string` - **`hash`** `string` Opaque identifier of the series' dimension combination, stable for the life of the metric. - **`dimensions`** `Record` The `group_by` field values that define this series. - **`display_values`** `Record | null` Readable value per dimension, read from the metric's `group_by_display_fields`; null when the metric defines none. - **`display_label`** `string | null` Readable name for the series, auto-derived at discovery or set explicitly. When null, charts build a label from the raw `dimensions`. - **`first_seen_at`** [`ISODateString`](/api/metrics#iso-date-string) When the series was registered. Stamped with the processing time, so a backfill registers historical combinations at run time. - **`last_seen_at`** [`ISODateString`](/api/metrics#iso-date-string) Also stamped at registration; not a recency signal, use `last_value_at` for that. - **`last_value`** `number | null` The most recent aggregated value observed for the series; used to rank series when none are pinned. - **`last_value_at`** [`ISODateString | null`](/api/metrics#iso-date-string) When `last_value` was recorded. - **`color`** `string | null` Chart color override; null means the color is picked automatically. - **`pinned_at`** [`ISODateString | null`](/api/metrics#iso-date-string) When the series was pinned; null means not pinned. Pins replace ranking: charts keep the pinned series and fold every other series into `__other__`, unless an explicit series filter is sent. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Metrics ## Endpoint Retrieve a list of metrics for a project. ```http GET /v1/projects/:project_id/metrics ``` **Scope:** `metrics:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`view_id`** `string` Return metrics that read from this view. Optional. - **`order_by`** `string` Field used to order the metrics. Optional. Defaults to `"name"`. Allowed values: `"name"`. - **`deleted_at`** [`NullableDateFilter`](/api/metrics#nullable-date-filter) Filter on deletion state. Pass `null` for metrics that are not scheduled for deletion. Optional. - **`limit`** `number` Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Optional. Defaults to `"asc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Metric[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Metric ## Endpoint Retrieve a single metric. ```http GET /v1/projects/:project_id/metrics/:metric_id ``` **Scope:** `metrics:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Response Metric retrieved ```ts { message: string; data: Metric; status: 200; error: null; pagination: null; endpoint: string; } ``` # Retrieve Metric Aggregation ## Endpoint Retrieve aggregated time-series data for a metric. ```http GET /v1/projects/:project_id/metrics/:metric_id/aggregation ``` **Scope:** `metrics:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Query Parameters - **`coverage_mode`** `string` Strict returns only final data. Observed includes partial data beyond complete_through_at without filling missing buckets. Optional. Defaults to `"strict"`. Allowed values: `"strict"`, `"observed"`. - **`start_at`** [`ISODateString`](/api/metrics#iso-date-string) Start of the aggregation range. Send together with `end_at`. Optional. - **`end_at`** [`ISODateString`](/api/metrics#iso-date-string) End of the aggregation range. Send together with `start_at`. Optional. - **`interval`** [`ChartInterval`](/api/metrics#chart-interval) Requested aggregation bucket interval. Optional. - **`time_range`** [`AnalyticsTimeRange`](/api/metrics#analytics-time-range) Preset used to calculate the aggregation range. Ignored when `start_at` and `end_at` are both sent. Defaults to the metric's saved chart range. Optional. - **`timezone`** `string` IANA timezone used to calculate date boundaries. Optional. - **`page_id`** `string` Page whose saved custom range should be used. Applies only when `time_range` is `custom`. Optional. - **`normalize`** `boolean` Whether the response includes empty time buckets. Optional. Defaults to `true`. - **`forecast_at`** [`ISODateString`](/api/metrics#iso-date-string) Future timestamp requested for a forecast. Optional. - **`max_series`** `integer` Maximum number of individual series to return. Optional. Minimum: `1`. Maximum: `50`. - **`series`** `string` Comma-separated series hashes to return. Optional. ## Response ```ts { message: string; data: TimeseriesAggregation; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - `last` returns the latest reading in each time bucket within the requested range. - `coverage_mode=observed` returns partial observed rows beyond the strict boundary without filling missing buckets. `coverage_reasons` names unresolved view scopes; `excluded` is informational. - Record keys are UTC bucket starts. A bucket is final only when its UTC calendar end (start plus one `interval`) is at or before `complete_through_at`; strict omits all other buckets. A null cutoff means unknown completeness. Observed may include populated partial buckets even when the requested end lies inside one, and does not synthesize empty partial buckets. - The aggregation window is resolved in order: an explicit `start_at` plus `end_at` wins; otherwise `time_range` is used; otherwise the metric's saved chart range is used. - `start_at` and `end_at` only take effect when sent together. Sending one without the other has no effect on the window. - When both are provided, `start_at` must be earlier than `end_at`. - `time_range=custom` without explicit dates falls back to the saved custom range of `page_id`, then the metric, then the project. - `timezone` must be a valid IANA timezone name, or `UTC`. # Create Metric ## Endpoint Create a metric for a project. ```http POST /v1/projects/:project_id/metrics ``` **Scope:** `metrics:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** The subject only, without the aggregation. Charts title themselves as the aggregation followed by this name, so `API Latency` renders as `P95 of API Latency`. Putting the aggregation here produces `P95 of API P95 Latency`. Minimum length: `1`. Maximum length: `64`. - **`view_id`** `string` -- **Required** View that provides the metric's records. Maximum length: `32`. - **`group_by`** `string[]` View fields used to split records into series. Optional. Defaults to `[]`. - **`group_by_display_fields`** `object | null` Maps a field in `group_by` to another view field whose value labels the series, so a chart grouped on an opaque id reads as `api.example.com` instead of `chk_a1b2c3`. Each label is read from the first record of a series and kept from then on. Optional. - **`filters`** `string` A query string of `?field=operator:value` pairs joined by `&`, applied when records are aggregated. For example `?status=equals:200` or `?level=in:error,warn&path=starts_with:/api`. Comma-separate the values of `in`, `not_in`, and `between`. Every operator must be spelled in full; short forms such as `eq:` are rejected. Optional. Defaults to `""`. Maximum length: `8192`. - **`timestamp_field`** `string` View field used as the aggregation timestamp. Optional. Defaults to `"timestamp"`. Minimum length: `1`. Maximum length: `256`. - **`value_field`** `string | null` View field used as the numeric aggregation value. Optional. - **`unique_field`** `string | null` View field used to count distinct values. Optional. - **`null_handling`** [`NullHandling`](/api/metrics#null-handling) How null or missing metric values are aggregated. Optional. Defaults to `"skip"`. - **`empty_bucket_handling`** [`EmptyBucketHandling`](/api/metrics#empty-bucket-handling) How chart buckets without observations are represented. Optional. - **`ui_chart_type`** [`ChartType`](/api/metrics#chart-type) Default chart type. Optional. - **`ui_chart_color_mode`** [`ChartColorMode`](/api/metrics#chart-color-mode) Strategy used to assign chart colors. Optional. - **`ui_chart_color_base`** [`ChartColor`](/api/metrics#chart-color) Base color used by intensity mode. Optional. - **`ui_chart_color_rules`** `object[] | null` Ordered value-to-color rules used by value mode. Optional. - **`ui_chart_show_alerts`** `boolean` Whether the chart displays alert markers. Optional. - **`ui_chart_show_monitors`** `boolean` Whether the chart displays monitor thresholds. Optional. - **`ui_chart_show_trends`** `boolean` Whether the chart displays regression trends. Optional. - **`ui_chart_compact_values`** `boolean` Whether chart tooltips round values to compact notation, such as 321.3M instead of the full number. Optional. - **`ui_chart_y_min`** `number | null` Fixed lower bound for the chart's y axis. Null lets the axis fit the data. Optional. - **`ui_chart_y_max`** `number | null` Fixed upper bound for the chart's y axis. Null lets the axis fit the data. Optional. - **`ui_chart_show_forecast`** `boolean` Whether the chart opens with its forecast shown, projecting the fitted trend past now to the saved horizon. Optional. - **`ui_chart_forecast_horizon`** [`ForecastHorizon`](/api/metrics#forecast-horizon) How far past now the chart projects its forecast. The value is relative to when the chart is viewed, so it keeps projecting the same distance ahead as time passes. Optional. - **`ui_chart_forecast_model`** [`ForecastModel`](/api/metrics#forecast-model) Curve the forecast is fitted with. Use `auto` to follow whichever model currently fits the series best. Optional. - **`ui_value_unit`** `string` Unit label displayed with chart values. Optional. Maximum length: `32`. - **`ui_chart_curve`** [`ChartCurve`](/api/metrics#chart-curve) Chart line interpolation style. Optional. - **`ui_chart_value`** [`MetricChartValue`](/api/metrics#metric-chart-value) Aggregation value displayed by default. Optional. - **`ui_chart_time_range`** [`AnalyticsTimeRange`](/api/metrics#analytics-time-range) Time range displayed by default. Optional. - **`ui_chart_interval`** [`ChartInterval`](/api/metrics#chart-interval) Aggregation interval displayed by default. Optional. - **`ui_chart_custom_range_start_at`** [`ISODateString`](/api/metrics#iso-date-string) Start of the custom chart range. Optional. - **`ui_chart_custom_range_end_at`** [`ISODateString`](/api/metrics#iso-date-string) End of the custom chart range. Optional. - **`ui_chart_max_series`** `integer` Maximum number of individual series displayed by default. Optional. Minimum: `1`. Maximum: `50`. - **`backfill_strategy`** [`BackfillStrategy`](/api/metrics#backfill-strategy) Order used to rebuild historical data. Optional. ## Response Your metric has been created and will begin collecting data immediately. ```ts { message: string; data: Metric; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - `view_id` is required when creating a metric. - Field references and filters must be compatible with the selected view. - Custom chart ranges require both dates, with an interval of at least 30 minutes. - Color-mode configuration must match the selected chart color mode. - `filters` must be a valid filter expression. - `timestamp_field` cannot reference `__meta__` metadata. - `group_by_display_fields` is set at create and cannot be changed afterwards, because each series takes its label from the first record it sees. Map a `group_by` field to a view field that carries a readable value for the same record. # Update Metric ## Endpoint Update an existing metric. ```http POST /v1/projects/:project_id/metrics/:metric_id ``` **Scope:** `metrics:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Request Body - **`name`** `string` The subject only, without the aggregation. Charts title themselves as the aggregation followed by this name, so `API Latency` renders as `P95 of API Latency`. Putting the aggregation here produces `P95 of API P95 Latency`. Optional. Minimum length: `1`. Maximum length: `64`. - **`view_id`** `string` View that provides the metric's records. Optional. Maximum length: `32`. - **`group_by`** `string[]` View fields used to split records into series. Optional. - **`filters`** `string` A query string of `?field=operator:value` pairs joined by `&`, applied when records are aggregated. For example `?status=equals:200` or `?level=in:error,warn&path=starts_with:/api`. Comma-separate the values of `in`, `not_in`, and `between`. Every operator must be spelled in full; short forms such as `eq:` are rejected. Optional. Maximum length: `8192`. - **`timestamp_field`** `string` View field used as the aggregation timestamp. Optional. Minimum length: `1`. Maximum length: `256`. - **`value_field`** `string | null` View field used as the numeric aggregation value. Optional. - **`unique_field`** `string | null` View field used to count distinct values. Optional. - **`null_handling`** [`NullHandling`](/api/metrics#null-handling) How null or missing metric values are aggregated. Optional. - **`empty_bucket_handling`** [`EmptyBucketHandling`](/api/metrics#empty-bucket-handling) How chart buckets without observations are represented. Optional. - **`ui_chart_type`** [`ChartType`](/api/metrics#chart-type) Default chart type. Optional. - **`ui_chart_color_mode`** [`ChartColorMode`](/api/metrics#chart-color-mode) Strategy used to assign chart colors. Optional. - **`ui_chart_color_base`** [`ChartColor`](/api/metrics#chart-color) Base color used by intensity mode. Optional. - **`ui_chart_color_rules`** `object[] | null` Ordered value-to-color rules used by value mode. Optional. - **`ui_chart_show_alerts`** `boolean` Whether the chart displays alert markers. Optional. - **`ui_chart_show_monitors`** `boolean` Whether the chart displays monitor thresholds. Optional. - **`ui_chart_show_trends`** `boolean` Whether the chart displays regression trends. Optional. - **`ui_chart_compact_values`** `boolean` Whether chart tooltips round values to compact notation, such as 321.3M instead of the full number. Optional. - **`ui_chart_y_min`** `number | null` Fixed lower bound for the chart's y axis. Null lets the axis fit the data. Optional. - **`ui_chart_y_max`** `number | null` Fixed upper bound for the chart's y axis. Null lets the axis fit the data. Optional. - **`ui_chart_show_forecast`** `boolean` Whether the chart opens with its forecast shown, projecting the fitted trend past now to the saved horizon. Optional. - **`ui_chart_forecast_horizon`** [`ForecastHorizon`](/api/metrics#forecast-horizon) How far past now the chart projects its forecast. The value is relative to when the chart is viewed, so it keeps projecting the same distance ahead as time passes. Optional. - **`ui_chart_forecast_model`** [`ForecastModel`](/api/metrics#forecast-model) Curve the forecast is fitted with. Use `auto` to follow whichever model currently fits the series best. Optional. - **`ui_value_unit`** `string` Unit label displayed with chart values. Optional. Maximum length: `32`. - **`ui_chart_curve`** [`ChartCurve`](/api/metrics#chart-curve) Chart line interpolation style. Optional. - **`ui_chart_value`** [`MetricChartValue`](/api/metrics#metric-chart-value) Aggregation value displayed by default. Optional. - **`ui_chart_time_range`** [`AnalyticsTimeRange`](/api/metrics#analytics-time-range) Time range displayed by default. Optional. - **`ui_chart_interval`** [`ChartInterval`](/api/metrics#chart-interval) Aggregation interval displayed by default. Optional. - **`ui_chart_custom_range_start_at`** [`ISODateString`](/api/metrics#iso-date-string) Start of the custom chart range. Optional. - **`ui_chart_custom_range_end_at`** [`ISODateString`](/api/metrics#iso-date-string) End of the custom chart range. Optional. - **`ui_chart_max_series`** `integer` Maximum number of individual series displayed by default. Optional. Minimum: `1`. Maximum: `50`. - **`backfill_strategy`** [`BackfillStrategy`](/api/metrics#backfill-strategy) Order used to rebuild historical data. Optional. - **`deleted_at`** `null` Send `null` to restore a metric that is scheduled for deletion. The deletion date itself is set by the delete endpoint and cannot be written here. Optional. ## Response Your metric has been updated and is calculating historical data ```ts { message: string; data: Metric; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Field references and filters must be compatible with the selected view. - Changing the metric's data feed rebuilds its historical rollups. - Custom chart ranges require both dates, with an interval of at least 30 minutes. - Color-mode configuration must match the selected chart color mode. - `filters` must be a valid filter expression. - `timestamp_field` cannot reference `__meta__` metadata. # Backfill Metric Data ## Endpoint Backfill a metric's historical data from its view. ```http POST /v1/projects/:project_id/metrics/:metric_id/backfill ``` **Scope:** `metrics:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Response Your metric data is being rebuilt from its view ```ts { message: string; data: Metric; status: 200; error: null; pagination: null; endpoint: string; } ``` # Delete Metric ## Endpoint Delete a metric. ```http DELETE /v1/projects/:project_id/metrics/:metric_id ``` **Scope:** `metrics:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Response ```ts { message: string; data: Metric; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The metric is hidden immediately and permanently removed once its restore window elapses. Restore it before then by updating it with `deleted_at` set to null. - Collection and backfill keep running for the whole window, so a restored metric resumes with no gap in its history. Its monitors stop evaluating until it is restored. # Force Delete Metric ## Endpoint Delete a metric permanently, without waiting out its restore window. ```http DELETE /v1/projects/:project_id/metrics/:metric_id/force ``` **Scope:** `metrics:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Response Metric queued for permanent deletion. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Works on a live metric as well as one already scheduled for deletion. - Its rollups and monitors are destroyed. The view it reads is not affected, so the metric can be recreated and backfilled. # List Metric Series ## Endpoint Retrieve the series discovered for a metric. ```http GET /v1/projects/:project_id/metrics/:metric_id/series ``` **Scope:** `metrics:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Query Parameters - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. - **`order_by`** `string` Field used to order the metric series. Optional. Defaults to `"first_seen_at"`. Allowed values: `"first_seen_at"`, `"last_seen_at"`. - **`search`** `string` Substring matched against labels, hashes, and dimension values. Optional. Minimum length: `1`. Maximum length: `128`. ## Response ```ts { message: string; data: MetricSeriesRecord[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Update Metric Series ## Endpoint Update the appearance overrides for one metric series. ```http POST /v1/projects/:project_id/metrics/:metric_id/series/:series_id ``` **Scope:** `metrics:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. - **`series_id`** `string` -- **Required** Unique identifier of the sery. ## Request Body - **`color`** [`ChartColor`](/api/metrics#chart-color) Color override; null restores automatic color selection. Optional. - **`pinned`** `boolean` Whether the series is pinned ahead of ranked series. Optional. - **`display_label`** `string | null` Display label override; null restores the derived label. Optional. ## Response Series appearance updated. ```ts { message: string; data: MetricSeriesRecord; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - At least one of `color`, `pinned`, or `display_label` must be provided. ## Monitors # Monitor Model ## Fields - **`object`** `"monitor"` - **`id`** `string` Unique identifier, prefixed with `mon_`. - **`slug`** `string` URL-safe identifier for the monitor. - **`team_id`** `string` - **`project_id`** `string` - **`metric_id`** `string` The metric this monitor watches. Fixed for the life of the monitor. - **`created_at`** [`ISODateString`](/api/monitors#iso-date-string) - **`updated_at`** [`ISODateString`](/api/monitors#iso-date-string) - **`name`** `string` - **`description`** `string | null` What this monitor watches for. - **`status`** [`MonitorStatus`](/api/monitors#monitor-status) Whether the monitor evaluates on its schedule or is paused. - **`chart_value`** [`MetricChartValue`](/api/monitors#metric-chart-value) Which value of the metric is compared against the threshold. - **`scope`** [`MonitorScope`](/api/monitors#monitor-scope) Whether the monitor fires once for the metric, or tracks each series separately. - **`time_window_minutes`** `number | null` How far back each evaluation looks when it reads the metric. - **`condition_type`** [`MonitorConditionType`](/api/monitors#monitor-condition-type) Threshold compares a value; sustained adds a duration; existence means value > 0; absence means no observations in a complete window. - **`operator`** [`MonitorOperator`](/api/monitors#monitor-operator) How the metric value is compared against the threshold. - **`threshold_value`** `number | null` The value the metric is compared against. - **`sustained_minutes`** `number | null` How long the condition must hold before the monitor fires. - **`schedule_cron`** `string` Cron expression, in UTC, setting how often the monitor evaluates. - **`alert_mode`** [`MonitorAlertMode`](/api/monitors#monitor-alert-mode) Whether an alert stays open until the condition clears, or opens and ends at once. - **`expires_at`** [`ISODateString | null`](/api/monitors#iso-date-string) When the monitor stops evaluating; null when it does not expire. - **`series_filters`** `{ include?: Record[] | undefined; exclude?: Record[] | undefined; } | null` Narrows which of the metric's series this monitor watches. - **`min_occurrences`** `number | null` How many times the condition must be met before the monitor fires. - **`occurrence_window_minutes`** `number | null` The window those occurrences have to fall within. - **`last_evaluated_at`** [`ISODateString | null`](/api/monitors#iso-date-string) When the monitor last evaluated. - **`next_evaluation_at`** [`ISODateString | null`](/api/monitors#iso-date-string) When the monitor evaluates next. - **`recent_alerts`** [`Alert[]`](/api/alerts#model) The most recent alerts this monitor raised. - **`series_states`** [`MonitorSeriesState[]`](/api/monitors#series-state-model) Current state of each series the monitor watches. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### MonitorStatus `"active" | "paused" | "disabled"` ### MetricChartValue `"count" | "average" | "min" | "max" | "sum" | "last" | "cumulative_count" | "cumulative_sum" | "p50" | "p95" | "p99" | "count_unique"` Aggregation applied to a metric's values. Use `last` when records are snapshots of a persistent thing such as a deal, user, or inventory item: each time bucket contains the latest reading for that series in the bucket. Within the requested range, the last observed value carries forward across complete empty intervals instead of reading them as zero. ### MonitorScope `"total" | "any_series" | "each_series"` ### MonitorConditionType `"threshold" | "sustained" | "existence" | "absence"` Threshold compares values; sustained adds duration; existence fires for value > 0; absence detects a complete window with no observations, including chart gaps. ### MonitorOperator `"gt" | "gte" | "lt" | "lte" | "eq" | "neq"` ### MonitorAlertMode `"spanning" | "instant"` # Monitor Preview Model ## Fields - **`object`** `"monitor_preview"` - **`start_at`** [`ISODateString`](/api/monitors#iso-date-string) - **`end_at`** [`ISODateString`](/api/monitors#iso-date-string) - **`complete_through_at`** [`ISODateString | null`](/api/monitors#iso-date-string) - **`ready`** `boolean` False means the window is not complete yet, so no condition verdict is available. - **`verdicts`** [`MonitorVerdict[]`](/api/monitors#verdict-model) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Monitor Verdict Model ## Fields - **`series_hash`** `string` - **`series_label`** `string | null` - **`value`** `number | null` - **`is_met`** `boolean | null` ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Monitor Series State Model ## Fields - **`monitor_id`** `string` - **`series_hash`** `string` Identifies which series of the metric this state tracks. - **`is_firing`** `boolean` Whether this series currently meets the monitor's condition. - **`last_triggered_at`** [`ISODateString | null`](/api/monitors#iso-date-string) When this series last met the condition. - **`last_value`** `number | null` The value this series had at the last evaluation. - **`started_firing_at`** [`ISODateString | null`](/api/monitors#iso-date-string) When the current firing period began; null when the series is not firing. - **`occurrence_timestamps`** `string[] | null` When the condition was met, for a monitor that counts occurrences. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Monitors ## Endpoint List the monitors watching a project's metrics. ```http GET /v1/projects/:project_id/monitors GET /v1/projects/:project_id/metrics/:metric_id/monitors ``` **Scope:** `monitors:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` Unique identifier of the metric. Only used by `/v1/projects/:project_id/metrics/:metric_id/monitors`. ## Query Parameters - **`order_by`** `string` Field the results are sorted by. Optional. Defaults to `"name"`. Allowed values: `"name"`, `"created_at"`. - **`metric_id`** `string` Return only monitors watching this metric. Optional. - **`status`** `string` Return only monitors in this state. Optional. Allowed values: `"active"`, `"paused"`, `"disabled"`. - **`limit`** `number` Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Optional. Defaults to `"asc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Monitor[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - Call the nested path to scope the results to one metric, or the flat path with an optional `metric_id` filter. - `after` and `before` are mutually exclusive. # Retrieve Monitor ## Endpoint Retrieve a single monitor. ```http GET /v1/projects/:project_id/metrics/:metric_id/monitors/:monitor_id ``` **Scope:** `monitors:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. - **`monitor_id`** `string` -- **Required** Unique identifier of the monitor. ## Response Monitor retrieved ```ts { message: string; data: Monitor; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Includes the monitor's recent alerts and the current state of every series it watches. # Create Monitor ## Endpoint Create a monitor that raises alerts when a metric meets a condition. ```http POST /v1/projects/:project_id/metrics/:metric_id/monitors ``` **Scope:** `monitors:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Request Body - **`name`** `string` Name shown for this monitor. Optional. Minimum length: `2`. Maximum length: `64`. - **`description`** `string | null` What this monitor watches for. Optional. - **`status`** `string` Whether the monitor starts evaluating immediately or switched off. `disabled` is not accepted: the system uses it to record that it stopped the monitor itself. Optional. Defaults to `"active"`. Allowed values: `"active"`, `"paused"`. - **`chart_value`** [`MetricChartValue`](/api/monitors#metric-chart-value) Which value of the metric is compared against the threshold. Optional. Defaults to `"sum"`. - **`scope`** [`MonitorScope`](/api/monitors#monitor-scope) Whether the monitor fires once for the metric as a whole, or tracks each series separately. Optional. Defaults to `"total"`. - **`time_window_minutes`** `integer | null` Evaluation lookback in whole minutes (1 to 525600). Null means since the metric was created. No-data conditions require a finite window. Optional. - **`condition_type`** [`MonitorConditionType`](/api/monitors#monitor-condition-type) threshold compares a value, sustained requires that comparison to hold, existence fires when the selected value is greater than zero, and absence fires when no observations exist in the complete evaluation window, regardless of chart gap handling. Optional. Defaults to `"threshold"`. - **`operator`** [`MonitorOperator`](/api/monitors#monitor-operator) How the metric value is compared against the threshold. Optional. Defaults to `"gt"`. - **`threshold_value`** `number | null` The value the metric is compared against. Optional. - **`sustained_minutes`** `number | null` How long the condition must hold before the monitor fires. Optional. - **`schedule_cron`** `string` Cron expression, in UTC, setting how often the monitor evaluates. Optional. Defaults to `"* * * * *"`. Minimum length: `1`. Maximum length: `128`. - **`alert_mode`** [`MonitorAlertMode`](/api/monitors#monitor-alert-mode) Whether an alert stays open until the condition clears, or opens and ends in one moment. Optional. Defaults to `"spanning"`. - **`expires_at`** [`ISODateString | null`](/api/monitors#iso-date-string) When the monitor stops evaluating. Leave null for no expiry. Optional. - **`series_filters`** `object | null` Narrows which of the metric's series this monitor watches. Optional. - **`min_occurrences`** `integer | null` How many times the condition must be met before the monitor fires. Optional. - **`occurrence_window_minutes`** `integer | null` The window those occurrences have to fall within. Optional. - **`metric_id`** `string` Metric to watch. Optional when using the /metrics/:metric/monitors route. Optional. ## Response Your monitor has been created. ```ts { message: string; data: Monitor; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - The monitor starts evaluating on its schedule as soon as it is created. - `scope` decides how many alerts a monitor can raise at once: `any_series` fires once for the metric as a whole, `each_series` tracks every series separately. - No-data (`absence`) conditions require `chart_value=count` and a finite `time_window_minutes`. - `sustained_minutes` is required when `condition_type` is `sustained`, and `threshold_value` is required when it is `threshold`. - `min_occurrences` and `occurrence_window_minutes` must both be set or both be null, and occurrence-based triggering cannot be combined with a sustained condition. - `schedule_cron` must be a valid cron expression. It is evaluated in UTC, and the finest granularity is one minute. - A monitor cannot be created active with an `expires_at` already in the past. # Preview Monitor ## Endpoint Preview a monitor condition over its current evaluation window without saving or raising alerts. ```http POST /v1/projects/:project_id/metrics/:metric_id/monitors/preview ``` **Scope:** `monitors:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Request Body - **`name`** `string` Name shown for this monitor. Optional. Minimum length: `2`. Maximum length: `64`. - **`description`** `string | null` What this monitor watches for. Optional. - **`status`** `string` Whether the monitor starts evaluating immediately or switched off. `disabled` is not accepted: the system uses it to record that it stopped the monitor itself. Optional. Defaults to `"active"`. Allowed values: `"active"`, `"paused"`. - **`chart_value`** [`MetricChartValue`](/api/monitors#metric-chart-value) Which value of the metric is compared against the threshold. Optional. Defaults to `"sum"`. - **`scope`** [`MonitorScope`](/api/monitors#monitor-scope) Whether the monitor fires once for the metric as a whole, or tracks each series separately. Optional. Defaults to `"total"`. - **`time_window_minutes`** `integer | null` Evaluation lookback in whole minutes (1 to 525600). Null means since the metric was created. No-data conditions require a finite window. Optional. - **`condition_type`** [`MonitorConditionType`](/api/monitors#monitor-condition-type) threshold compares a value, sustained requires that comparison to hold, existence fires when the selected value is greater than zero, and absence fires when no observations exist in the complete evaluation window, regardless of chart gap handling. Optional. Defaults to `"threshold"`. - **`operator`** [`MonitorOperator`](/api/monitors#monitor-operator) How the metric value is compared against the threshold. Optional. Defaults to `"gt"`. - **`threshold_value`** `number | null` The value the metric is compared against. Optional. - **`sustained_minutes`** `number | null` How long the condition must hold before the monitor fires. Optional. - **`schedule_cron`** `string` Cron expression, in UTC, setting how often the monitor evaluates. Optional. Defaults to `"* * * * *"`. Minimum length: `1`. Maximum length: `128`. - **`alert_mode`** [`MonitorAlertMode`](/api/monitors#monitor-alert-mode) Whether an alert stays open until the condition clears, or opens and ends in one moment. Optional. Defaults to `"spanning"`. - **`expires_at`** [`ISODateString | null`](/api/monitors#iso-date-string) When the monitor stops evaluating. Leave null for no expiry. Optional. - **`series_filters`** `object | null` Narrows which of the metric's series this monitor watches. Optional. - **`min_occurrences`** `integer | null` How many times the condition must be met before the monitor fires. Optional. - **`occurrence_window_minutes`** `integer | null` The window those occurrences have to fall within. Optional. - **`metric_id`** `string` Metric to watch. Optional when using the /metrics/:metric/monitors route. Optional. ## Response Monitor preview retrieved ```ts { message: string; data: MonitorPreview; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Uses the same series filtering and condition evaluation as scheduled monitors. This is a condition preview, not a simulation of cron timing, sustained duration, or occurrence counting. - An incomplete window returns ready=false with no verdicts. No-data conditions count observations across the whole window, including when the chart displays missing buckets as gaps. - No-data (`absence`) conditions require `chart_value=count` and a finite `time_window_minutes`. - `sustained_minutes` is required when `condition_type` is `sustained`, and `threshold_value` is required when it is `threshold`. - `min_occurrences` and `occurrence_window_minutes` must both be set or both be null, and occurrence-based triggering cannot be combined with a sustained condition. - `schedule_cron` must be a valid cron expression. It is evaluated in UTC, and the finest granularity is one minute. - A monitor cannot be created active with an `expires_at` already in the past. # Update Monitor ## Endpoint Change a monitor's condition, schedule, or status. ```http POST /v1/projects/:project_id/metrics/:metric_id/monitors/:monitor_id ``` **Scope:** `monitors:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. - **`monitor_id`** `string` -- **Required** Unique identifier of the monitor. ## Request Body - **`name`** `string` Name shown for this monitor. Optional. Minimum length: `2`. Maximum length: `64`. - **`description`** `string | null` What this monitor watches for. Optional. - **`chart_value`** [`MetricChartValue`](/api/monitors#metric-chart-value) Which value of the metric is compared against the threshold. Optional. - **`scope`** [`MonitorScope`](/api/monitors#monitor-scope) Whether the monitor fires once for the metric as a whole, or tracks each series separately. Optional. - **`time_window_minutes`** `integer | null` Evaluation lookback in whole minutes (1 to 525600). Null means since the metric was created. No-data conditions require a finite window. Optional. - **`condition_type`** [`MonitorConditionType`](/api/monitors#monitor-condition-type) threshold compares a value, sustained requires that comparison to hold, existence fires when the selected value is greater than zero, and absence fires when no observations exist in the complete evaluation window, regardless of chart gap handling. Optional. - **`operator`** [`MonitorOperator`](/api/monitors#monitor-operator) How the metric value is compared against the threshold. Optional. - **`threshold_value`** `number | null` The value the metric is compared against. Optional. - **`sustained_minutes`** `number | null` How long the condition must hold before the monitor fires. Optional. - **`schedule_cron`** `string` Cron expression, in UTC, setting how often the monitor evaluates. Optional. Minimum length: `1`. Maximum length: `128`. - **`alert_mode`** [`MonitorAlertMode`](/api/monitors#monitor-alert-mode) Whether an alert stays open until the condition clears, or opens and ends in one moment. Optional. - **`expires_at`** [`ISODateString | null`](/api/monitors#iso-date-string) When the monitor stops evaluating. Leave null for no expiry. Optional. - **`series_filters`** `object | null` Narrows which of the metric's series this monitor watches. Optional. - **`min_occurrences`** `integer | null` How many times the condition must be met before the monitor fires. Optional. - **`occurrence_window_minutes`** `integer | null` The window those occurrences have to fall within. Optional. ## Response Your monitor has been updated. ```ts { message: string; data: Monitor; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Send only the fields you are changing. Anything omitted keeps its current value. - Changing what the monitor MEANS (its condition, scope, series filters or alert mode) ends any period currently firing, because the old alert no longer describes the new rule. - `metric_id` cannot be changed. Create a new monitor against the other metric instead. - The metric a monitor watches cannot be changed. Create a second monitor instead. - No-data (`absence`) conditions require `chart_value=count` and a finite `time_window_minutes`. - `sustained_minutes` is required when `condition_type` is `sustained`, and `threshold_value` is required when it is `threshold`. - `min_occurrences` and `occurrence_window_minutes` must both be set or both be null, and occurrence-based triggering cannot be combined with a sustained condition. - `schedule_cron` must be a valid cron expression. It is evaluated in UTC, and the finest granularity is one minute. - `status` is not editable here. Use the pause and resume operations, which is also what keeps a customer from writing the `disabled` the system uses for expiry. - Moving `expires_at` is rejected when that would leave an active monitor with an expiry already in the past. Editing a monitor that has already expired is allowed, including the update that extends its expiry. - Conditions are checked against the monitor as it will be stored, not against the fields you send, so a change that would leave the monitor in an invalid combination is rejected even when the conflicting value is one you did not send. # Pause Monitor ## Endpoint Pause a monitor so it stops evaluating. ```http POST /v1/projects/:project_id/metrics/:metric_id/monitors/:monitor_id/pause ``` **Scope:** `monitors:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. - **`monitor_id`** `string` -- **Required** Unique identifier of the monitor. ## Response Monitor paused ```ts { message: string; data: Monitor; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - A paused monitor raises no alerts and closes nothing that is already firing. Resuming evaluates it again on its next scheduled tick. # Resume Monitor ## Endpoint Resume a paused monitor so it evaluates on its schedule again. ```http POST /v1/projects/:project_id/metrics/:metric_id/monitors/:monitor_id/resume ``` **Scope:** `monitors:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. - **`monitor_id`** `string` -- **Required** Unique identifier of the monitor. ## Response Monitor resumed ```ts { message: string; data: Monitor; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - A monitor the system stopped because its expiry passed can be resumed once the expiry is moved into the future. Resuming one whose expiry is still in the past is rejected. # Delete Monitor ## Endpoint Delete a monitor. ```http DELETE /v1/projects/:project_id/metrics/:metric_id/monitors/:monitor_id ``` **Scope:** `monitors:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. - **`monitor_id`** `string` -- **Required** Unique identifier of the monitor. ## Response Your monitor has been deleted. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Alerts the monitor already raised are deleted with it. ## Alerts # Alert Model ## Fields - **`object`** `"alert"` - **`id`** `string` Unique identifier, prefixed with `alr_`. - **`slug`** `string` URL-safe identifier for the alert. - **`team_id`** `string` - **`project_id`** `string` - **`metric_id`** `string` The metric the monitor was watching. - **`metric_name`** `string | null` - **`monitor_id`** `string` The monitor that raised the alert. - **`monitor_name`** `string | null` - **`created_at`** [`ISODateString`](/api/alerts#iso-date-string) When the condition first held. The start of the firing period. - **`ended_at`** [`ISODateString | null`](/api/alerts#iso-date-string) When the condition stopped holding. Null while the alert is still firing. - **`series_hash`** `string` Identifies which series of the metric fired, when the monitor watches series separately. - **`series_label`** `string | null` - **`trigger_value`** `number` The metric value at the moment the alert opened. - **`threshold_value`** `number` The value the metric had to cross for the monitor to fire. - **`condition_description`** `string` The condition in words, for example `above 500 for 10 minutes`. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Alerts ## Endpoint List the alerts a metric's monitors have raised. ```http GET /v1/projects/:project_id/metrics/:metric_id/alerts ``` **Scope:** `alerts:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`metric_id`** `string` -- **Required** Unique identifier of the metric. ## Query Parameters - **`order_by`** `string` Field the results are sorted by. Alerts sort by when their period opened. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`. - **`metric_id`** `string` Return only alerts raised on this metric. Optional. - **`monitor_id`** `string` Return only alerts raised by this monitor. Optional. - **`is_open`** `string` Set true for periods still firing, false for periods that have ended. Optional. Allowed values: `"true"`, `"false"`, `"1"`, `"0"`. - **`time_range`** [`AnalyticsTimeRange`](/api/metrics#analytics-time-range) Window to search, relative to now. Ignored when start_at and end_at are sent. Optional. - **`timezone`** `string` IANA timezone the time range is anchored to. Defaults to UTC. Optional. - **`page_id`** `string` Resolve the time range from this page's setting instead of the metric's. Optional. - **`start_at`** [`ISODateString`](/api/alerts#iso-date-string) Start of the window to search, as an ISO 8601 value. Optional. - **`end_at`** [`ISODateString`](/api/alerts#iso-date-string) End of the window to search, as an ISO 8601 value. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Alert[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - An alert is a firing PERIOD, not a single notification. `created_at` is when the condition started holding and `ended_at` is when it stopped, so one incident is one row for its whole duration. - Results cover a time window. Send `start_at` and `end_at`, or a `time_range`; with neither, the metric's own configured chart range is used. - An alert is returned when its period OVERLAPS the window, so a period that opened before the window and is still firing is included. - Use `is_open=true` to see only what is currently firing. - `before` and `after` are mutually exclusive. Send one or neither. - `timezone` must be a valid IANA timezone name, or `UTC`. - `after` and `before` are mutually exclusive. # Retrieve Alert ## Endpoint Retrieve a single alert. ```http GET /v1/projects/:project_id/alerts/:alert_id ``` **Scope:** `alerts:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`alert_id`** `string` -- **Required** Unique identifier of the alert. ## Response Alert retrieved ```ts { message: string; data: Alert; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - A null `ended_at` means the condition still holds and the period is still open. ## Pages # Page Model ## Fields - **`object`** `"page"` - **`id`** `string` Unique identifier, prefixed with `pag_`. - **`team_id`** `string` - **`project_id`** `string` - **`name`** `string` - **`created_at`** [`ISODateString`](/api/pages#iso-date-string) - **`updated_at`** [`ISODateString`](/api/pages#iso-date-string) - **`is_public`** `boolean` Whether the page is reachable by anyone holding its URL. - **`public_url`** `string` Where the page is served once published. The address resolves only while `is_public` is true. - **`slug`** `string` The random segment of the public URL. Changes whenever the URL is refreshed. - **`access_code`** `string | null` Code a visitor must enter to view the public page; null when none is set. - **`components`** [`Component[]`](/api/components#model) The components displayed on the page, in the order they appear. - **`time_range`** [`AnalyticsTimeRange`](/api/pages#analytics-time-range) Window every chart on the page covers. - **`custom_range_start_at`** [`ISODateString | null`](/api/pages#iso-date-string) Start of the window, when the time range is custom. - **`custom_range_end_at`** [`ISODateString | null`](/api/pages#iso-date-string) End of the window, when the time range is custom. - **`interval`** [`ChartInterval`](/api/pages#chart-interval) Bucket size the charts use. - **`public_ui_show_alerts`** `boolean` Whether alert markers are drawn on the charts of the public page. - **`public_ui_show_trends`** `boolean` Whether trend lines enabled on each metric are shown publicly. Defaults to true. - **`public_ui_show_forecast`** `boolean` Whether forecasts enabled on each metric are shown publicly. Defaults to true. - **`domain_routes`** [`PageDomainRoute[]`](/api/pages#domain-route-model) The custom domains this page is published on. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### ComponentCardSize `"1/1" | "1/2"` ### MetricStatus `"initializing" | "waiting_for_transforms" | "backfilling" | "active" | "error" | "cancelled"` ### NullHandling `"skip" | "count_as_zero"` ### EmptyBucketHandling `"zero" | "gaps"` ### BackfillStrategy `"newest_first" | "oldest_first"` ### ChartFamily `"cartesian" | "radial" | "geographic" | "temporal" | "hierarchical"` ### ChartType `"line" | "area" | "bar" | "pie" | "scatter" | "radar" | "stat" | "gauge" | "calendar" | "uptime"` ### ChartColorMode `"by_series" | "by_intensity" | "by_value"` ### ChartColor `"blue" | "red" | "amber" | "green" | "teal" | "purple" | "pink"` ### ChartCurve `"linear" | "smooth" | "step"` ### ForecastHorizon `"next_7_days" | "next_30_days" | "next_90_days" | "end_of_quarter" | "end_of_year" | "next_year"` How far past now a chart projects its forecast. Values are relative to the moment the chart is viewed, so a saved horizon keeps projecting the same distance ahead as time passes rather than expiring on a fixed date. `end_of_quarter` and `end_of_year` run to the end of the calendar period that contains today, in UTC. ### ForecastModel `"auto" | "linear" | "exponential" | "logarithmic" | "logistic" | "sinusoidal"` The curve a forecast is fitted with. `auto` follows the best-fitting model for the series, which is recalculated as data arrives and can therefore change between views; naming a model pins the projection to that curve. ### MetricChartValue `"count" | "average" | "min" | "max" | "sum" | "last" | "cumulative_count" | "cumulative_sum" | "p50" | "p95" | "p99" | "count_unique"` Aggregation applied to a metric's values. Use `last` when records are snapshots of a persistent thing such as a deal, user, or inventory item: each time bucket contains the latest reading for that series in the bucket. Within the requested range, the last observed value carries forward across complete empty intervals instead of reading them as zero. ### AnalyticsTimeRange `"last_hour" | "last_6_hours" | "today" | "last_24_hours" | "yesterday" | "this_week" | "last_week" | "this_month" | "last_month" | "this_quarter" | "last_quarter" | "this_year" | "last_year" | "last_7_days" | "last_30_days" | "last_90_days" | "last_365_days" | "all_time" | "custom" | "next_7_days" | "next_30_days" | "next_90_days"` The window a chart reads. Stored as a plain string rather than a database enum: the set is presentation, not something any query filters on, and the forward ranges in particular are expected to change as we learn what people forecast over. A `next_*` range ends after now, which is what turns a fitted trend into a visible forecast. The measured half of such a range is still measured; only the part past now is projected. ### ChartInterval `"minute" | "hour" | "day" | "month" | "auto"` The Data Interval _setting_ (`Metric.ui_chart_interval` and the aggregation `interval` query param). `"auto"` means the server picks the finest-safe tier for the current view, so brush-zoom naturally drills into a finer bucket. The RESOLVED tier returned by aggregation is always a plain `DataInterval`. # Page Domain Route Model ## Fields - **`object`** `"page_domain_route"` - **`id`** `string` Unique identifier, prefixed with `pdr_`. - **`domain_id`** `string` - **`page_id`** `string` - **`domain`** `string` The domain name itself. - **`pathname`** `string` Path the page is served at on that domain, leading slash included. `/` is the domain root. - **`public_url`** `string` The full address the page is reachable at. - **`created_at`** [`ISODateString`](/api/pages#iso-date-string) - **`updated_at`** [`ISODateString`](/api/pages#iso-date-string) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Pages ## Endpoint List a project's pages. ```http GET /v1/projects/:project_id/pages ``` **Scope:** `pages:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field the results are sorted by. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`. - **`team_id`** `string` Return only pages in this team. Optional. - **`project_id`** `string` Return only pages in this project. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Page[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Page ## Endpoint Retrieve a single page. ```http GET /v1/projects/:project_id/pages/:page_id ``` **Scope:** `pages:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. ## Response Page retrieved ```ts { message: string; data: Page; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Includes every component on the page and the custom domains it is published to. # Create Page ## Endpoint Create a page that displays a set of metrics. ```http POST /v1/projects/:project_id/pages ``` **Scope:** `pages:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** Display name for the page. Minimum length: `1`. Maximum length: `64`. - **`is_public`** `boolean` Whether the page is reachable by anyone holding its URL. Optional. - **`public_ui_show_alerts`** `boolean` Whether alert markers are drawn on the charts of the public page. Optional. - **`public_ui_show_trends`** `boolean` Whether trend lines enabled on each metric are shown on the public page. Defaults to true. Optional. - **`public_ui_show_forecast`** `boolean` Whether forecasts enabled on each metric are shown on the public page. Defaults to true. Optional. - **`access_code`** `string | null` Code a visitor must enter to view the public page. Send null for no code. Optional. - **`time_range`** [`AnalyticsTimeRange`](/api/pages#analytics-time-range) Window every chart on the page covers. Optional. - **`interval`** [`ChartInterval`](/api/pages#chart-interval) Bucket size the charts use. Set to auto to pick one from the time range. Optional. - **`custom_range_start_at`** [`ISODateString`](/api/pages#iso-date-string) Start of the window, when the time range is custom. Optional. - **`custom_range_end_at`** [`ISODateString`](/api/pages#iso-date-string) End of the window, when the time range is custom. Optional. ## Response Your page has been created ```ts { message: string; data: Page; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - A page is private until `is_public` is set. Publishing one generates the slug that forms its public URL. - A `custom` time range requires both `custom_range_start_at` and `custom_range_end_at`, at least 30 minutes apart, with the start before the end. - An `access_code` is trimmed, and an empty one is stored as no code at all. # Update Page ## Endpoint Change a page's name, time range, or public access. ```http POST /v1/projects/:project_id/pages/:page_id ``` **Scope:** `pages:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. ## Request Body - **`name`** `string` Display name for the page. Optional. Minimum length: `1`. Maximum length: `64`. - **`is_public`** `boolean` Whether the page is reachable by anyone holding its URL. Optional. - **`public_ui_show_alerts`** `boolean` Whether alert markers are drawn on the charts of the public page. Optional. - **`public_ui_show_trends`** `boolean` Whether trend lines enabled on each metric are shown on the public page. Defaults to true. Optional. - **`public_ui_show_forecast`** `boolean` Whether forecasts enabled on each metric are shown on the public page. Defaults to true. Optional. - **`access_code`** `string | null` Code a visitor must enter to view the public page. Send null for no code. Optional. - **`time_range`** [`AnalyticsTimeRange`](/api/pages#analytics-time-range) Window every chart on the page covers. Optional. - **`interval`** [`ChartInterval`](/api/pages#chart-interval) Bucket size the charts use. Set to auto to pick one from the time range. Optional. - **`custom_range_start_at`** [`ISODateString`](/api/pages#iso-date-string) Start of the window, when the time range is custom. Optional. - **`custom_range_end_at`** [`ISODateString`](/api/pages#iso-date-string) End of the window, when the time range is custom. Optional. ## Response Your page has been updated ```ts { message: string; data: Page; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Send only the fields you are changing. Anything omitted keeps its current value. - Making a page private clears its public URL. Making it public again issues a new slug, so any previously shared link stops working. - A `custom` time range requires both `custom_range_start_at` and `custom_range_end_at`, at least 30 minutes apart, with the start before the end. The rule is checked against the page as it will be after the update, not against the fields you send. - An `access_code` is trimmed, and an empty one clears the code. # Add Page Domain ## Endpoint Publish a page on one of your verified domains. ```http POST /v1/projects/:project_id/pages/:page_id/domains/:domain_id ``` **Scopes:** `pages:write` + `domains:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. - **`domain_id`** `string` -- **Required** Unique identifier of the domain. ## Request Body - **`pathname`** `string` -- **Required** Path this page is served from on one custom Page domain. `/` serves the root. ## Response 201 Custom Page URL saved ```ts { message: string; data: PageDomainRoute; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Response 200 Custom Page URL saved ```ts { message: string; data: PageDomainRoute; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The domain has to be verified before a page can be served on it. - Sending this again for the same domain moves the page to the new pathname rather than creating a second route. - Send `/` to serve the page at the domain root. - `pathname` is trimmed, lowercased, given a leading slash and stripped of any trailing slash before it is stored, so `Status`, `/status` and `status/` all resolve to the same path rather than becoming separate routes. - `pathname` is either `/`, which serves the domain root, or a single segment of lowercase letters, numbers and single hyphens. Nested paths such as `/team/status` are rejected. - A small set of paths is reserved by Tailglow Pages and cannot be used. - Only one page can hold a given path on a domain, including `/`. - A stored `pathname` is at most 64 characters. The limit is applied after normalization, so the leading slash counts toward it even when you leave it off, while surrounding whitespace and a trailing slash do not. - A `pathname` longer than 256 characters is rejected before any of that, counting whatever you send including whitespace. - An empty or blank `pathname` is rejected. Delete the route to stop serving the page on a domain. # Remove Page Domain ## Endpoint Stop serving a page on one of your domains. ```http DELETE /v1/projects/:project_id/pages/:page_id/domains/:domain_id ``` **Scopes:** `pages:write` + `domains:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. - **`domain_id`** `string` -- **Required** Unique identifier of the domain. ## Response Custom Page URL removed ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The page stays reachable on its Tailglow URL if it is still public. # Refresh Page URL ## Endpoint Issue a new public URL for a page. ```http POST /v1/projects/:project_id/pages/:page_id/refresh ``` **Scope:** `pages:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. ## Response Your page slug has been updated ```ts { message: string; data: Page; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Use this when a shared link should stop working. The old URL returns a 404 immediately. # Delete Page ## Endpoint Delete a page. ```http DELETE /v1/projects/:project_id/pages/:page_id ``` **Scope:** `pages:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. ## Response Your page has been deleted. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The metrics the page displayed are not affected. ## Components # Component Model ## Fields - **`object`** `"component"` - **`id`** `string` Unique identifier, prefixed with `comp_`. - **`page_id`** `string` - **`created_at`** [`ISODateString`](/api/components#iso-date-string) - **`updated_at`** [`ISODateString`](/api/components#iso-date-string) - **`ui_card_size`** [`ComponentCardSize`](/api/components#component-card-size) How much of the page width the component occupies. - **`ui_sort_index`** `number` Position of the component on the page. Lower appears first. - **`metric`** [`Metric`](/api/metrics#model) The metric this component displays. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### ComponentCardSize `"1/1" | "1/2"` ### MetricStatus `"initializing" | "waiting_for_transforms" | "backfilling" | "active" | "error" | "cancelled"` ### NullHandling `"skip" | "count_as_zero"` ### EmptyBucketHandling `"zero" | "gaps"` ### BackfillStrategy `"newest_first" | "oldest_first"` ### ChartFamily `"cartesian" | "radial" | "geographic" | "temporal" | "hierarchical"` ### ChartType `"line" | "area" | "bar" | "pie" | "scatter" | "radar" | "stat" | "gauge" | "calendar" | "uptime"` ### ChartColorMode `"by_series" | "by_intensity" | "by_value"` ### ChartColor `"blue" | "red" | "amber" | "green" | "teal" | "purple" | "pink"` ### ChartCurve `"linear" | "smooth" | "step"` ### ForecastHorizon `"next_7_days" | "next_30_days" | "next_90_days" | "end_of_quarter" | "end_of_year" | "next_year"` How far past now a chart projects its forecast. Values are relative to the moment the chart is viewed, so a saved horizon keeps projecting the same distance ahead as time passes rather than expiring on a fixed date. `end_of_quarter` and `end_of_year` run to the end of the calendar period that contains today, in UTC. ### ForecastModel `"auto" | "linear" | "exponential" | "logarithmic" | "logistic" | "sinusoidal"` The curve a forecast is fitted with. `auto` follows the best-fitting model for the series, which is recalculated as data arrives and can therefore change between views; naming a model pins the projection to that curve. ### MetricChartValue `"count" | "average" | "min" | "max" | "sum" | "last" | "cumulative_count" | "cumulative_sum" | "p50" | "p95" | "p99" | "count_unique"` Aggregation applied to a metric's values. Use `last` when records are snapshots of a persistent thing such as a deal, user, or inventory item: each time bucket contains the latest reading for that series in the bucket. Within the requested range, the last observed value carries forward across complete empty intervals instead of reading them as zero. ### AnalyticsTimeRange `"last_hour" | "last_6_hours" | "today" | "last_24_hours" | "yesterday" | "this_week" | "last_week" | "this_month" | "last_month" | "this_quarter" | "last_quarter" | "this_year" | "last_year" | "last_7_days" | "last_30_days" | "last_90_days" | "last_365_days" | "all_time" | "custom" | "next_7_days" | "next_30_days" | "next_90_days"` The window a chart reads. Stored as a plain string rather than a database enum: the set is presentation, not something any query filters on, and the forward ranges in particular are expected to change as we learn what people forecast over. A `next_*` range ends after now, which is what turns a fitted trend into a visible forecast. The measured half of such a range is still measured; only the part past now is projected. ### ChartInterval `"minute" | "hour" | "day" | "month" | "auto"` The Data Interval _setting_ (`Metric.ui_chart_interval` and the aggregation `interval` query param). `"auto"` means the server picks the finest-safe tier for the current view, so brush-zoom naturally drills into a finer bucket. The RESOLVED tier returned by aggregation is always a plain `DataInterval`. # Add Component ## Endpoint Add a metric to a page. ```http POST /v1/projects/:project_id/pages/:page_id/components ``` **Scope:** `pages:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. ## Request Body - **`ui_sort_index`** `integer` Position of the component on the page. Lower appears first. Optional. - **`ui_card_size`** [`ComponentCardSize`](/api/components#component-card-size) How much of the page width the component occupies. Optional. - **`metric_id`** `string` -- **Required** Metric this component displays. - **`page_id`** `string` Page the component is added to. Optional. ## Response Your component has been created ```ts { message: string; data: Component; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - A component is one metric placed on one page. The metric has to belong to the same project. - The metric must belong to the same project as the page. - A page holds a limited number of components. Adding one past the limit is rejected. # Update Component ## Endpoint Change which metric a component shows, its size, or its position. ```http POST /v1/projects/:project_id/pages/:page_id/components/:component_id ``` **Scope:** `pages:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. - **`component_id`** `string` -- **Required** Unique identifier of the component. ## Request Body - **`ui_sort_index`** `integer` Position of the component on the page. Lower appears first. Optional. - **`ui_card_size`** [`ComponentCardSize`](/api/components#component-card-size) How much of the page width the component occupies. Optional. - **`metric_id`** `string` Metric this component displays. Optional. ## Response Your component has been updated ```ts { message: string; data: Component; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Send only the fields you are changing. Anything omitted keeps its current value. - Reorder a page by sending a new `ui_sort_index` for each component you are moving. - A new `metric_id` must belong to the same project as the page. # Delete Component ## Endpoint Remove a component from a page. ```http DELETE /v1/projects/:project_id/pages/:page_id/components/:component_id ``` **Scope:** `pages:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`page_id`** `string` -- **Required** Unique identifier of the page. - **`component_id`** `string` -- **Required** Unique identifier of the component. ## Response Your component has been deleted. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The metric itself is not affected, only its placement on this page. ## Teams # Team Model ## Fields - **`object`** `"team"` - **`id`** `string` - **`name`** `string` - **`created_at`** [`ISODateString`](/api/teams#iso-date-string) - **`updated_at`** [`ISODateString`](/api/teams#iso-date-string) - **`deleted_at`** [`ISODateString | null`](/api/teams#iso-date-string) When the team is scheduled to be deleted; null when it is not. - **`logo_url`** `string | null` - **`status`** [`TeamStatus`](/api/teams#team-status) Account standing. Any status other than `active` stops ingest: `delinquent` marks a missed payment, `restricted` also makes the API read-only apart from the billing fields needed to recover the account, and `blocked` is applied manually by Tailglow. - **`billing_email`** `string` - **`billing_plan`** [`BillingPlan`](/api/teams#billing-plan) - **`billing_address`** [`Address`](/api/teams#address-model) Postal address that appears on the team's invoices. - **`storage_gb`** `number` Stored data across the team's projects, in gigabytes of uncompressed data: raw ingested files and artifacts, plus view output and minute-level rollups. Recalculated hourly; `billing_updated_at` is the last refresh. - **`billing_period_server_months`** `number` Server-months the team's servers have accrued in the current calendar-month billing period, counted up to the last refresh. - **`billing_period_input_tokens`** `number` AI input tokens consumed through Tailglow-provided model access this billing period, counting only tokens charged at the full input rate. Anything served from or written to the prompt cache is counted separately below. Chats running on your own provider keys are not counted at all. - **`billing_period_output_tokens`** `number` AI output tokens consumed through Tailglow-provided model access this billing period. - **`billing_period_cache_read_tokens`** `number` Input tokens served from the prompt cache this billing period, charged at the cache rate. - **`billing_period_cache_write_tokens`** `number` Input tokens written to the prompt cache this billing period, charged at the cache rate. - **`billing_updated_at`** [`ISODateString | null`](/api/teams#iso-date-string) When the cached billing quantities were last recalculated; null before the first pass. - **`max_servers_per_project`** `number` How many servers each project may run. Scale requests beyond it are rejected. - **`is_mfa_required`** `boolean` Whether every member must verify with two-factor authentication before their session can act. - **`is_tailglow_ai_enabled`** `boolean` Whether members may run the assistant on Tailglow's model, billed to this team. When false, each member must add their own provider key before they can use the assistant at all. - **`has_payment_method`** `boolean` Whether the team has a payment method on file. - **`promo_expires_at`** [`ISODateString | null`](/api/teams#iso-date-string) When the team's free trial window ends. A time in the past means the trial has ended and the trial servers are being settled; null when the team has no trial window. - **`server_trial_used_at`** [`ISODateString | null`](/api/teams#iso-date-string) When the team used its once-per-account server trial; retained after the trial is settled. - **`promo_server_hours`** `number` Shared server-hour credits remaining after the last invoice; unbilled usage is not deducted. - **`promo_ai_tokens`** `number` Shared Tailglow AI token credits remaining after the last invoice. - **`tgl_generations_count`** `number` Automatic transform-script generations counted against the hourly budget. The counter rolls over lazily: after the window elapses it keeps its last value until the next generation. - **`tgl_generations_reset_at`** [`ISODateString | null`](/api/teams#iso-date-string) When the counted window ends or ended. A past timestamp means no generation has happened since. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### TeamStatus `"active" | "restricted" | "delinquent" | "blocked"` ### BillingPlan `"pro_v1" | "enterprise_v1"` # Team Billing Model ## Fields - **`is_estimate_complete`** `boolean` False when a saved AI rate needs support; monetary estimates are incomplete until resolved. - **`object`** `"billing"` - **`team_id`** `string` - **`calculated_at`** [`ISODateString`](/api/teams#iso-date-string) - **`billing_plan`** [`BillingPlan`](/api/teams#billing-plan) - **`has_payment_method`** `boolean` - **`promo_expires_at`** [`ISODateString | null`](/api/teams#iso-date-string) Cardless trial deadline; unused promotional units do not expire at this time. - **`server_count`** `number` Non-surge capacity across the team, including provisioning and excluding idle/terminating. - **`uninvoiced_server_hours`** `number` Billable server-hours since the last saved invoice, including preceding-month usage. - **`promo_server_hours`** `number` Stored server-hour balance after the last invoice. - **`promo_ai_tokens`** `number` Stored Tailglow-funded token balance after the last invoice. - **`available_promo_server_hours`** `number` Server-hour credits remaining after accrued, uninvoiced usage. - **`available_promo_ai_tokens`** `number` Tailglow-funded token credits remaining after accrued, uninvoiced usage. - **`included_storage_gb_months`** `number` Storage, in GB-months, the plan credits on every monthly invoice. - **`available_included_storage_gb_months`** `number` Included storage this period has not used yet, in GB-months. - **`period_start_at`** [`ISODateString`](/api/teams#iso-date-string) First moment of the billing period being estimated, in UTC. - **`period_end_at`** [`ISODateString`](/api/teams#iso-date-string) First moment of the following period, so the period is `[start, end)`. - **`billed_at`** [`ISODateString`](/api/teams#iso-date-string) When the invoice for this period is calculated, which is after the period has closed. - **`line_items`** [`InvoiceEstimateLineItem[]`](/api/teams#billing-line-item-model) One entry per billable line. Lines that accrued nothing are present with a zero quantity. - **`subtotal_cents`** `number` - **`discount_cents`** `number` - **`total_cents`** `number` What the period has accrued so far, after discounts. Excludes tax, which Stripe calculates when the invoice is finalized, and any credit note balance, which is applied at payment. - **`projected_line_items`** [`InvoiceEstimateLineItem[]`](/api/teams#billing-line-item-model) The same period carried to `billed_at`: storage held and grown at its recent rate, servers that are up staying up, tokens continuing at the month-to-date rate. A subscription appears unchanged because it is committed for the whole period. A forecast rather than a measurement, so it assumes today's usage continues and moves the moment a server is added or removed. Discounts here are read as of `billed_at`, so one that lapses mid-period counts toward `total_cents` but not toward this. - **`projected_subtotal_cents`** `number` - **`projected_discount_cents`** `number` - **`projected_total_cents`** `number` ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### BillingPlan `"pro_v1" | "enterprise_v1"` ### BillingLineItemType `"compute" | "storage" | "subscription" | "ai_input" | "ai_output" | "ai_cache_read" | "ai_cache_write"` # Billing Line Item Model ## Fields - **`line_item_type`** [`BillingLineItemType`](/api/teams#billing-line-item-type) - **`description`** `string` The label this line carries on the issued invoice, so an estimate reads like the bill. - **`quantity`** `number` Units billed, in the line item's own unit: GB-months, server-months, or token millions. - **`unit_price_cents`** `number` - **`subtotal_cents`** `number` - **`discount_cents`** `number` Zero when no discount applies to this line item. - **`total_cents`** `number` - **`discount_id`** `string | null` The negotiated discount applied in addition to promo credits, or null. - **`discount_percent`** `number | null` Set only for percent discounts; a fixed-amount discount reports its value in cents. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### BillingLineItemType `"compute" | "storage" | "subscription" | "ai_input" | "ai_output" | "ai_cache_read" | "ai_cache_write"` # Billing Estimate Model ## Fields - **`line_items`** [`InvoiceEstimateLineItem[]`](/api/teams#billing-line-item-model) One entry per billable line, in the order the invoice lists them. Lines that accrued nothing are present with a zero quantity. - **`subtotal_cents`** `number` - **`discount_cents`** `number` - **`total_cents`** `number` ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### BillingLineItemType `"compute" | "storage" | "subscription" | "ai_input" | "ai_output" | "ai_cache_read" | "ai_cache_write"` # Address Model ## Fields - **`thoroughfare`** `string | null` Street line: street number and street name. - **`premise`** `string | null` Unit, suite, or building within the street address. - **`sublocality`** `string | null` District or neighborhood within the city, where addresses use one. - **`locality`** `string | null` City or town. - **`administrative_area`** `string | null` State, province, or region. - **`postal_code`** `string | null` ZIP or postal code. - **`country`** `string | null` Two-letter ISO country code. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Teams ## Endpoint Retrieve a list of teams the caller belongs to. ```http GET /v1/teams ``` ## Query Parameters - **`order_by`** `string` Field used to order the teams. Optional. Defaults to `"name"`. Allowed values: `"created_at"`, `"name"`. - **`name`** [`TextFilter`](/api/teams#text-filter) Filter by team name, written as `operator:value`. For example `contains:acme` or `equals:Acme Inc`. Optional. - **`status`** [`TeamStatus`](/api/teams#team-status) Filter by team status, written as `operator:value`. For example `equals:active` or `in:active,delinquent`. Optional. - **`billing_plan`** [`BillingPlan`](/api/teams#billing-plan) Filter by billing plan, written as `operator:value`. For example `in:pro_v1,enterprise_v1`. Optional. - **`created_at`** [`DateFilter`](/api/teams#date-filter) Filter by creation date, written as `operator:value`. For example `gt:2026-01-01` or `between:2026-01-01,2026-02-01`. Optional. - **`deleted_at`** [`NullableDateFilter`](/api/teams#nullable-date-filter) Filter by scheduled deletion date. Use `null` for teams that are not scheduled for deletion, `not:null` for teams that are. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Team[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - API key callers only ever receive the single team the key belongs to. - Teams scheduled for deletion are only returned to their Owners. - `after` and `before` are mutually exclusive. # Retrieve Team ## Endpoint Retrieve a single team. ```http GET /v1/teams/:team_id ``` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. ## Response ```ts { message: string; data: Team; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - You can only retrieve the team your credentials are scoped to. # Retrieve Team Billing ## Endpoint Retrieve the team's current billing summary. ```http GET /v1/teams/:team_id/billing ``` **Scope:** `billing:read` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. ## Response Team billing retrieved ```ts { message: string; data: TeamBilling; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Requires `billing:read` and credentials scoped to this team. Every response includes accrued and projected charges, stored and available promotional credits, and server usage. - Available credits account for uninvoiced usage, including the preceding month before its invoice is saved. Reading this summary does not consume credits or create an invoice. - Amounts exclude tax and credit notes applied at payment. Projections assume current usage continues; the final invoice can differ. # Create Team ## Endpoint Create a new team owned by the authenticated user. ```http POST /v1/teams ``` ## Request Body - **`name`** `string` Display name for the team. Optional. Minimum length: `2`. Maximum length: `60`. - **`billing_email`** `string (email)` Email address that receives invoices and billing notifications. Optional. Maximum length: `64`. - **`billing_plan`** [`BillingPlan`](/api/teams#billing-plan) Billing plan for the team. Optional. - **`status`** [`TeamStatus`](/api/teams#team-status) Account status for the team. Optional. - **`is_mfa_required`** `boolean` Whether every member must sign in with multi-factor authentication. Optional. - **`max_servers_per_project`** `integer` Maximum number of servers each project in the team can run. Optional. Minimum: `1`. Maximum: `1000`. - **`billing_address`** `object` Billing address printed on invoices. Optional. - **`logo_url`** `string` Team logo, sent as a JPEG or PNG base64 data URI. Optional. ## Response ```ts { message: string; data: Team; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - Teams cannot be created with an API key. Use a signed-in user session. - `name` defaults to `Team` and `billing_email` defaults to the authenticated user's email address when they are omitted. - The team starts on the `pro_v1` plan with a generated logo. `billing_plan`, `status`, `logo_url`, `is_mfa_required`, `billing_address`, and `max_servers_per_project` are ignored on create. Send them to the update endpoint instead. - There is a maximum number of teams a single user can create. - The authenticated user is added to the new team as its Owner. - `billing_email` cannot use the `@tailglow.io` domain. - `logo_url` must be a JPEG or PNG base64 data URI of at most 5 MB. # Update Team ## Endpoint Update an existing team. ```http POST /v1/teams/:team_id ``` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. ## Request Body - **`name`** `string` Display name for the team. Optional. Minimum length: `2`. Maximum length: `60`. - **`billing_email`** `string (email)` Email address that receives invoices and billing notifications. Optional. Maximum length: `64`. - **`billing_plan`** [`BillingPlan`](/api/teams#billing-plan) Billing plan for the team. Optional. - **`status`** [`TeamStatus`](/api/teams#team-status) Account status for the team. Optional. - **`expected_status`** [`TeamStatus`](/api/teams#team-status) The status the team had when you loaded it. Required with `status`; the change is refused if the status has changed since. Optional. - **`is_mfa_required`** `boolean` Whether every member must sign in with multi-factor authentication. Optional. - **`is_tailglow_ai_enabled`** `boolean` Whether members may run the AI assistant on Tailglow's model, billed to this team. When false, each member must add their own provider key before they can use the assistant. Optional. - **`max_servers_per_project`** `integer` Maximum number of servers each project in the team can run. Optional. Minimum: `1`. Maximum: `1000`. - **`billing_address`** `object` Billing address printed on invoices. Optional. - **`logo_url`** `string` Team logo, sent as a JPEG or PNG base64 data URI. Optional. - **`deleted_at`** [`ISODateString | null`](/api/teams#iso-date-string) Date and time when the team is scheduled to be permanently deleted. Optional. ## Response ```ts { message: string; data: Team; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Teams cannot be updated with an API key. Use a signed-in user session. - At least one field must be provided. - Only team Owners can change billing, security, or account settings. Other members can update `name` and `logo_url` only. - `status`, `max_servers_per_project`, and `deleted_at` are managed by Tailglow and cannot be set by team members. - `status` requires `expected_status`, the status you loaded; the change is refused with a conflict if the team's status has changed since. - Changing `is_mfa_required` requires a recently verified multi-factor sign-in. - Moving to a plan that bills a payment method requires a valid payment method on the team. - `billing_email` cannot use the `@tailglow.io` domain. - `logo_url` must be a JPEG or PNG base64 data URI of at most 5 MB. # Delete Team ## Endpoint Schedule a team for deletion. ```http DELETE /v1/teams/:team_id ``` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. ## Response ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Teams cannot be deleted with an API key. Use a signed-in user session. - Only the team Owner can delete a team. - The team must be active. Contact support to delete a suspended or blocked team. - Deletion is scheduled, not immediate. Permanent removal happens 40 days later, the team's projects and API keys are cancelled, and every signed-in member is signed out. An owner who signs back in before then cancels the deletion. # List Team Members ## Endpoint Retrieve a list of members in a team. ```http GET /v1/teams/:team_id/users ``` **Scope:** `users:read` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. ## Query Parameters - **`order_by`** `string` Field used to order the team members. Optional. Defaults to `"name"`. Allowed values: `"created_at"`, `"name"`. - **`name`** [`TextFilter`](/api/teams#text-filter) Filter by member name, written as `operator:value`. For example `contains:riley` or `starts_with:Ri`. Optional. - **`status`** [`UserStatus`](/api/users#user-status) Filter by member account status, written as `operator:value`. For example `in:active,blocked`. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: User[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - You can only list members of the team your credentials are scoped to. - `after` and `before` are mutually exclusive. # Retrieve Team Member ## Endpoint Retrieve a single member of a team. ```http GET /v1/teams/:team_id/users/:user_id ``` **Scope:** `users:read` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. - **`user_id`** `string` -- **Required** Unique identifier of the user. ## Response User retrieved ```ts { message: string; data: User; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - You can only retrieve members of the team your credentials are scoped to. # Add Team Member ## Endpoint Add a person to a team. This does not create a standalone user account: an existing Tailglow account is matched by email address, and an account is created for the address only when none exists yet. ```http POST /v1/teams/:team_id/users ``` **Scope:** `users:write` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. ## Request Body - **`name`** `string` Display name for the member. Optional. Minimum length: `2`. Maximum length: `60`. - **`role_id`** `string` -- **Required** Role the member holds in this team. - **`email`** `string (email)` -- **Required** Email address of the person to add. They receive a sign-in link at this address, and an account is created for them if they do not already have one. ## Response New user was added to the team ```ts { message: string; data: User; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - The person receives an email with a sign-in link for the team. - Someone who is already a member of the team cannot be added again. - Only Owners can assign the Owner role. - There is a maximum number of members per team. - Blocked and locked accounts cannot be added to a team. - You can assign only scopes that your own authorization has. # Update Team Member ## Endpoint Update a member of a team. ```http POST /v1/teams/:team_id/users/:user_id ``` **Scope:** `users:write` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. - **`user_id`** `string` -- **Required** Unique identifier of the user. ## Request Body - **`name`** `string` Display name for the member. Optional. Minimum length: `2`. Maximum length: `60`. - **`role_id`** `string` Role the member holds in this team. Optional. ## Response User updated ```ts { message: string; data: User; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - You cannot change your own role. - You can only change your own name. Another member's name is theirs to change. - You cannot assign a role that holds scopes you do not hold yourself, and only Owners can assign or replace the Owner role. - Changing a member's role signs them out and emails them the new role. - A member's email address cannot be changed. Remove them and add them again with the new address. # Remove Team Member ## Endpoint Remove a member from a team. ```http DELETE /v1/teams/:team_id/users/:user_id ``` **Scope:** `users:delete` ## Path Parameters - **`team_id`** `string` -- **Required** Unique identifier of the team. - **`user_id`** `string` -- **Required** Unique identifier of the user. ## Response User removed from team ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - You cannot remove yourself from a team. Delete the team instead if you are its last member. - You cannot remove a member whose role holds scopes you do not hold yourself, and only Owners can remove another Owner. - The last Owner of a team cannot be removed. - The member is emailed to let them know they were removed. Their Tailglow account is not deleted, only their membership in this team. ## Users # User Model ## Fields - **`object`** `"user"` - **`name`** `string` - **`email`** `string` - **`id`** `string` - **`default_team_id`** `string | null` The team the user lands in at sign-in; null falls back to the first team they belong to. - **`created_at`** [`ISODateString`](/api/users#iso-date-string) - **`updated_at`** [`ISODateString`](/api/users#iso-date-string) - **`last_active_at`** [`ISODateString | null`](/api/users#iso-date-string) When the user last made an authenticated request. Updated at most once every few minutes. - **`profile_url`** `string | null` URL of the user's avatar image; null when none is set. - **`role`** [`Role | null`](/api/roles#model) The user's role on the team the request is scoped to; null when they have none. - **`status`** [`UserStatus`](/api/users#user-status) `blocked` and `locked` accounts cannot act; `waitlisted` accounts signed up but have not been granted access yet. - **`default_auth_method`** [`AuthMethod`](/api/users#auth-method) The sign-in method preselected for the user. - **`available_auth_methods`** [`AuthMethod[]`](/api/users#auth-method) The sign-in methods enabled on the account. - **`is_totp_enabled`** `boolean` Whether an authenticator app is set up for two-factor sign-in. - **`totp_backup_codes_count`** `number` How many unused two-factor backup codes remain. - **`totp_default_count`** `number` How many backup codes a full set contains, for showing "N of M remaining". - **`password_updated_at`** [`ISODateString | null`](/api/users#iso-date-string) When the password was last changed; null when password sign-in is not enabled. - **`monitor_auto_subscribe`** `boolean` Whether the user is automatically subscribed to alert emails for monitors newly created in their team. - **`monitor_cooloff_minutes`** `number` Minimum minutes between alert emails about the same monitor. - **`product_update_notifications`** `boolean` Whether the user receives product update emails. - **`appearance_palette`** `string` Color palette the dashboard renders in for this user. - **`appearance_type_set`** `string` Font pairing the dashboard uses. - **`appearance_accent`** `string` Accent color the dashboard uses. - **`appearance_scale`** `string` Interface density preference. Applied to dashboard content at tablet and desktop widths; phones always render at full size. - **`default_ai_model`** [`AiChatSelection | null`](/api/users#ai-chat-selection) Selection a new chat opens on. Null when no preference is set. An unavailable saved selection requires an explicit replacement; it never silently changes the payer. - **`default_ai_effort`** [`AiEffortLevel`](/api/users#ai-effort-level) How hard the assistant is asked to work on each turn by default. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### Scope `"users" | "roles" | "keys" | "records" | "projects" | "metrics" | "views" | "billing" | "pages" | "monitors" | "alerts" | "chats" | "secrets" | "servers" | "ingest_keys" | "sources" | "domains" | "facets" | "drains" | "pulls" | "checks" | "logs"` ### ScopeValue `"read" | "write" | "delete"` ### UserStatus `"active" | "blocked" | "waitlisted" | "locked"` ### AuthMethod `"magic_link" | "password"` ### AiChatSelection `"claude-opus-5-5" | "claude-sonnet-5" | "gpt-6-sol" | "gpt-5.6-terra" | "gpt-6-luna" | "claude-opus-5" | "gpt-5.6-sol" | "gpt-5.6-luna" | "claude-opus-4-6" | "tailglow"` An explicit choice of Tailglow-managed access or a model using the member's own key. ### AiEffortLevel `"low" | "medium" | "high" | "xhigh" | "max"` How hard a model works on a turn. A model that accepts a narrower range declares it in `AI_MODEL_CONFIGS[model].efforts`. # List Users ## Endpoint Retrieve a list of users in the current team. ```http GET /v1/users ``` **Scope:** `users:read` ## Query Parameters - **`order_by`** `string` Field used to order the users. Optional. Defaults to `"name"`. Allowed values: `"created_at"`, `"name"`. - **`name`** [`TextFilter`](/api/users#text-filter) Filter by display name. Accepts a filter operator, for example `contains:ada` or `starts_with:ada`. Optional. - **`status`** [`UserStatus`](/api/users#user-status) Filter by status. Accepts a filter operator, for example `in:active,blocked`. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: User[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve User ## Endpoint Retrieve a single user. ```http GET /v1/users/:user_id ``` ## Path Parameters - **`user_id`** `string` -- **Required** Unique identifier of the user. ## Response User retrieved ```ts { message: string; data: User; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - You can retrieve your own user, or a user who is a member of your team. # Update User ## Endpoint Update a user's profile and preferences. ```http POST /v1/users/:user_id ``` ## Path Parameters - **`user_id`** `string` -- **Required** Unique identifier of the user. ## Request Body - **`name`** `string` Display name for the user. Optional. Minimum length: `2`. Maximum length: `60`. - **`default_team_id`** `string` ID of the team the user lands in after signing in. Optional. - **`profile_url`** `string` Profile image as a JPEG or PNG base64 data URI. Optional. - **`email`** `string (email)` Email address of the user. Optional. - **`monitor_auto_subscribe`** `boolean` Whether the user is subscribed to new monitors automatically. Optional. - **`monitor_cooloff_minutes`** `integer` Minutes to wait before sending another notification for the same monitor. Between 30 and 1440. Optional. Minimum: `30`. Maximum: `1440`. - **`product_update_notifications`** `boolean` Whether the user receives product update emails. Optional. - **`appearance_palette`** `string` Color palette used by the dashboard. Optional. Allowed values: `"light"`, `"dark"`, `"dim"`, `"midnight"`, `"paper"`. - **`appearance_type_set`** `string` Font pairing used by the dashboard. Optional. Allowed values: `"system"`, `"grotesk"`, `"editorial"`, `"geometric"`. - **`appearance_accent`** `string` Accent color used by the dashboard. Optional. Allowed values: `"orange"`, `"azure"`, `"burgundy"`, `"ink"`, `"emerald"`, `"violet"`. - **`appearance_scale`** `string` Interface density used by the dashboard. Optional. Allowed values: `"comfortable"`, `"cozy"`, `"compact"`. - **`default_ai_model`** [`AiChatSelection`](/api/users#ai-chat-selection) Model a new chat opens on. Null clears the preference. An unavailable selection asks the member to choose again; it never changes who pays automatically. Optional. - **`default_ai_effort`** [`AiEffortLevel`](/api/users#ai-effort-level) How hard the assistant is asked to work on each turn by default. Optional. - **`role_id`** `string` ID of the role that grants the user their permissions. Optional. - **`default_auth_method`** [`AuthMethod`](/api/users#auth-method) Method the user signs in with by default. Optional. - **`status`** [`UserStatus`](/api/users#user-status) Status of the user. Optional. ## Response User updated ```ts { message: string; data: User; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - You can only update your own profile. - `email` cannot be changed here. Sending a different address returns an error. - `role_id` and `status` are ignored here. Manage a user's role through the team endpoints. - `default_team_id` must be a team the user is already a member of. - Setting `default_auth_method` to `password` requires password authentication and MFA to be enabled first. - `profile_url` images must be at least 256x256 pixels. They are resized and stored as PNG, and the response returns the hosted image URL. - `profile_url` images must not exceed 5 MB. # Enable Password Authentication ## Endpoint Enable password authentication for a user. ```http POST /v1/users/:user_id/enable_password ``` ## Path Parameters - **`user_id`** `string` -- **Required** Unique identifier of the user. ## Response Password auth has been enabled ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - You can only enable password authentication for your own user. - MFA must be enabled before password authentication can be turned on. # List User Teams ## Endpoint Retrieve a list of teams a user belongs to. ```http GET /v1/users/:user_id/teams ``` ## Path Parameters - **`user_id`** `string` -- **Required** Unique identifier of the user. ## Query Parameters - **`order_by`** `string` Field used to order the teams. Optional. Defaults to `"name"`. Allowed values: `"created_at"`, `"name"`. - **`name`** [`TextFilter`](/api/users#text-filter) Filter by team name, written as `operator:value`. For example `contains:acme` or `equals:Acme Inc`. Optional. - **`status`** [`TeamStatus`](/api/teams#team-status) Filter by team status, written as `operator:value`. For example `equals:active` or `in:active,delinquent`. Optional. - **`billing_plan`** [`BillingPlan`](/api/teams#billing-plan) Filter by billing plan, written as `operator:value`. For example `in:pro_v1,enterprise_v1`. Optional. - **`created_at`** [`DateFilter`](/api/users#date-filter) Filter by creation date, written as `operator:value`. For example `gt:2026-01-01` or `between:2026-01-01,2026-02-01`. Optional. - **`deleted_at`** [`NullableDateFilter`](/api/users#nullable-date-filter) Filter by scheduled deletion date. Use `null` for teams that are not scheduled for deletion, `not:null` for teams that are. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Team[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - You can only list your own teams. - `after` and `before` are mutually exclusive. ## Roles # Role Model ## Fields - **`object`** `"role"` - **`id`** `string` - **`name`** `string` - **`team_id`** `string` - **`scopes`** [`Scopes`](/api/roles#scopes) The permissions the role grants: each resource mapped to its allowed actions (`read`, `write`, `delete`). ## Referenced Types ### Scopes `Record` Scope names mapped to their permitted actions. Allowed scope keys: `"users"`, `"roles"`, `"keys"`, `"records"`, `"projects"`, `"metrics"`, `"views"`, `"billing"`, `"pages"`, `"monitors"`, `"alerts"`, `"chats"`, `"secrets"`, `"servers"`, `"ingest_keys"`, `"sources"`, `"domains"`, `"facets"`, `"drains"`, `"pulls"`, `"checks"`, `"logs"`. Allowed action values: `"read"`, `"write"`, `"delete"`. ### Scope `"users" | "roles" | "keys" | "records" | "projects" | "metrics" | "views" | "billing" | "pages" | "monitors" | "alerts" | "chats" | "secrets" | "servers" | "ingest_keys" | "sources" | "domains" | "facets" | "drains" | "pulls" | "checks" | "logs"` ### ScopeValue `"read" | "write" | "delete"` # List Roles ## Endpoint Retrieve a list of roles for the current team. ```http GET /v1/roles ``` **Scope:** `roles:read` ## Query Parameters - **`order_by`** `string` Field used to order the roles. Optional. Defaults to `"name"`. Allowed values: `"name"`. - **`limit`** `number` Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Optional. Defaults to `"asc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Role[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Role ## Endpoint Retrieve a single role. ```http GET /v1/roles/:role_id ``` **Scope:** `roles:read` ## Path Parameters - **`role_id`** `string` -- **Required** Unique identifier of the role. ## Response Role retrieved ```ts { message: string; data: Role; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create Role ## Endpoint Create a new role for the current team. ```http POST /v1/roles ``` **Scope:** `roles:write` ## Request Body - **`id`** `string` Custom identifier for the role. One is generated when omitted. Optional. - **`name`** `string` -- **Required** Display name for the role. Minimum length: `2`. Maximum length: `60`. - **`scopes`** [`Scopes`](/api/roles#scopes) Scope names mapped to their permitted actions. Optional. Allowed scope keys: `"users"`, `"roles"`, `"keys"`, `"records"`, `"projects"`, `"metrics"`, `"views"`, `"billing"`, `"pages"`, `"monitors"`, `"alerts"`, `"chats"`, `"secrets"`, `"servers"`, `"ingest_keys"`, `"sources"`, `"domains"`, `"facets"`, `"drains"`, `"pulls"`, `"checks"`, `"logs"`. Allowed action values: `"read"`, `"write"`, `"delete"`. ## Response ```ts { message: string; data: Role; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - `id` cannot be `role_owner`, which is reserved. - Omit `id` and one is generated for you. - You can assign only scopes that your own authorization has. - The built-in `role_owner` role cannot be created, updated, or deleted. - Human roles must include `projects:read`. # Update Role ## Endpoint Update an existing role. ```http POST /v1/roles/:role_id ``` **Scope:** `roles:write` ## Path Parameters - **`role_id`** `string` -- **Required** Unique identifier of the role. ## Request Body - **`name`** `string` Display name for the role. Optional. Minimum length: `2`. Maximum length: `60`. - **`scopes`** [`Scopes`](/api/roles#scopes) Scope names mapped to their permitted actions. Optional. Allowed scope keys: `"users"`, `"roles"`, `"keys"`, `"records"`, `"projects"`, `"metrics"`, `"views"`, `"billing"`, `"pages"`, `"monitors"`, `"alerts"`, `"chats"`, `"secrets"`, `"servers"`, `"ingest_keys"`, `"sources"`, `"domains"`, `"facets"`, `"drains"`, `"pulls"`, `"checks"`, `"logs"`. Allowed action values: `"read"`, `"write"`, `"delete"`. ## Response Your role has been updated. ```ts { message: string; data: Role; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - A role's `id` cannot be changed. Every user assignment points at it, so a rename would orphan them. - You can assign only scopes that your own authorization has. - The built-in `role_owner` role cannot be created, updated, or deleted. - Human roles must include `projects:read`. # Delete Role ## Endpoint Delete a role from the current team. ```http DELETE /v1/roles/:role_id ``` **Scope:** `roles:delete` ## Path Parameters - **`role_id`** `string` -- **Required** Unique identifier of the role. ## Response ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Roles with assigned users cannot be deleted. Reassign those users before deleting the role. - The built-in `role_owner` role cannot be created, updated, or deleted. ## API Keys # API Key Model ## Fields - **`object`** `"key"` - **`id`** `string` - **`last4`** `string` The last four characters of the key, for telling keys apart. The full secret is only returned at creation. - **`created_at`** [`ISODateString`](/api/keys#iso-date-string) - **`updated_at`** [`ISODateString`](/api/keys#iso-date-string) - **`scopes`** [`Scopes`](/api/keys#scopes) What the key may do: each resource mapped to its allowed actions (`read`, `write`, `delete`). - **`team_id`** `string` - **`name`** `string` - **`updated_by`** `string | null` Who last changed the key, including at creation. ## Referenced Types ### Scopes `Record` Scope names mapped to their permitted actions. Allowed scope keys: `"users"`, `"roles"`, `"keys"`, `"records"`, `"projects"`, `"metrics"`, `"views"`, `"billing"`, `"pages"`, `"monitors"`, `"alerts"`, `"chats"`, `"secrets"`, `"servers"`, `"ingest_keys"`, `"sources"`, `"domains"`, `"facets"`, `"drains"`, `"pulls"`, `"checks"`, `"logs"`. Allowed action values: `"read"`, `"write"`, `"delete"`. ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### Scope `"users" | "roles" | "keys" | "records" | "projects" | "metrics" | "views" | "billing" | "pages" | "monitors" | "alerts" | "chats" | "secrets" | "servers" | "ingest_keys" | "sources" | "domains" | "facets" | "drains" | "pulls" | "checks" | "logs"` ### ScopeValue `"read" | "write" | "delete"` # List API Keys ## Endpoint Retrieve a list of API keys for the current team. ```http GET /v1/keys ``` **Scope:** `keys:read` ## Query Parameters - **`order_by`** `string` Field used to order the API keys. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`, `"name"`. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Key[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve API Key ## Endpoint Retrieve a single API key. ```http GET /v1/keys/:key_id ``` **Scope:** `keys:read` ## Path Parameters - **`key_id`** `string` -- **Required** Unique identifier of the key. ## Response Key retrieved ```ts { message: string; data: Key; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create API Key ## Endpoint Create a new API key for the current team. ```http POST /v1/keys ``` **Scope:** `keys:write` ## Request Body - **`name`** `string` -- **Required** Display name for the API key. Minimum length: `2`. Maximum length: `60`. - **`scopes`** [`Scopes`](/api/keys#scopes) Scope names mapped to their permitted actions. Optional. Allowed scope keys: `"users"`, `"roles"`, `"keys"`, `"records"`, `"projects"`, `"metrics"`, `"views"`, `"billing"`, `"pages"`, `"monitors"`, `"alerts"`, `"chats"`, `"secrets"`, `"servers"`, `"ingest_keys"`, `"sources"`, `"domains"`, `"facets"`, `"drains"`, `"pulls"`, `"checks"`, `"logs"`. Allowed action values: `"read"`, `"write"`, `"delete"`. ## Response You'll only be able to see your API key one time. ```ts { message: string; data: Key & { api_key: string }; status: 201; error: null; pagination: null; endpoint: string; } ``` ### Additional Response Fields - **`api_key`** `string` -- **Required** The full API key. Returned once, when the key is created, and never again. Store it at that point; afterwards only `last4` is available. ## Comments - You can assign only scopes that your own authorization has. # Update API Key ## Endpoint Update an existing API key. ```http POST /v1/keys/:key_id ``` **Scope:** `keys:write` ## Path Parameters - **`key_id`** `string` -- **Required** Unique identifier of the key. ## Request Body - **`name`** `string` Display name for the API key. Optional. - **`scopes`** [`Scopes`](/api/keys#scopes) Scope names mapped to their permitted actions. Optional. Allowed scope keys: `"users"`, `"roles"`, `"keys"`, `"records"`, `"projects"`, `"metrics"`, `"views"`, `"billing"`, `"pages"`, `"monitors"`, `"alerts"`, `"chats"`, `"secrets"`, `"servers"`, `"ingest_keys"`, `"sources"`, `"domains"`, `"facets"`, `"drains"`, `"pulls"`, `"checks"`, `"logs"`. Allowed action values: `"read"`, `"write"`, `"delete"`. ## Response Your API key has been updated. ```ts { message: string; data: Key; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - You can assign only scopes that your own authorization has. # Delete API Key ## Endpoint Delete an API key from the current team. ```http DELETE /v1/keys/:key_id ``` **Scope:** `keys:delete` ## Path Parameters - **`key_id`** `string` -- **Required** Unique identifier of the key. ## Response Your API key has been deleted. ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Domains # Domain Model ## Fields - **`object`** `"domain"` - **`id`** `string` Unique identifier, prefixed with `dom_`. - **`team_id`** `string` - **`domain`** `string` The hostname the customer added, stored lowercase. - **`ownership_type`** [`DnsRecordType`](/api/domains#dns-record-type) The record proving the customer controls this hostname. Always a TXT at `_tailglow-verify.{domain}`, required even for a domain with no purpose, which needs nothing else. Verification is per-hostname: it proves nothing about the parent domain or a sibling. - **`ownership_name`** `string` - **`ownership_value`** `string` - **`ownership_status`** [`DnsRecordStatus`](/api/domains#dns-record-status) What the last lookup found. `unchecked` means no lookup has run yet, which is different from `missing` (looked up, definitively not there). - **`ownership_actual`** `string | null` What DNS actually returned. Null when the record is absent or has not been looked up. - **`ownership_checked_at`** [`ISODateString | null`](/api/domains#iso-date-string) - **`ownership_verified`** `boolean` Whether Tailglow currently treats the ownership record as good. True while it resolves, and it stays true for 24 hours after it stops so a brief DNS problem does not unverify a working domain. - **`ownership_failed_at`** [`ISODateString | null`](/api/domains#iso-date-string) When the ownership record had been missing long enough that Tailglow stops serving the domain. Null while ownership holds, including during the grace period that follows a failed check. - **`routing_type`** [`DnsRecordType | null`](/api/domains#dns-record-type) The record routing traffic to Tailglow, or null while the domain has no purpose and so asks for no record. Always a CNAME at the hostname itself. - **`routing_name`** `string | null` - **`routing_value`** `string | null` - **`routing_status`** [`DnsRecordStatus`](/api/domains#dns-record-status) What the last lookup found. A routing record whose target has since moved reads as `unchecked`: the stored answer described the old target, so it says nothing about the current one. - **`routing_actual`** `string | null` - **`routing_checked_at`** [`ISODateString | null`](/api/domains#iso-date-string) - **`routing_verified`** `boolean` Whether Tailglow currently treats the routing record as good. True while it resolves, and it stays true for seven days after it stops so a DNS change in progress does not take a live domain out of service. - **`certificate_status`** [`CertificateStatus`](/api/domains#certificate-status) Progress of the TLS certificate Tailglow provisions once routing is verified. - **`certificate_error`** `string | null` Why the last certificate attempt failed; null unless `certificate_status` is `failed`. - **`certificate_provisioned_at`** [`ISODateString | null`](/api/domains#iso-date-string) When the current certificate was issued. - **`purpose`** [`DomainTrafficPurpose | null`](/api/domains#domain-traffic-purpose) What this domain serves, or null when it serves nothing yet. A domain serves ingest traffic or status pages, never both. - **`is_sso_enabled`** `boolean` Whether members with an email at this domain sign in through SSO. Adds no DNS record. - **`lifecycle_action`** [`DomainLifecycleAction | null`](/api/domains#domain-lifecycle-action) Infrastructure work Tailglow is currently doing for this domain; null when idle. - **`lifecycle_status`** [`DomainLifecycleStatus | null`](/api/domains#domain-lifecycle-status) How that work is progressing. - **`lifecycle_error`** `string | null` Why the last attempt failed. Tailglow retries automatically. - **`last_checked_at`** [`ISODateString | null`](/api/domains#iso-date-string) When this domain was last checked. A domain can be checked once every 30 seconds; per-record timing lives on `ownership_checked_at` and `routing_checked_at`. - **`created_at`** [`ISODateString`](/api/domains#iso-date-string) - **`updated_at`** [`ISODateString`](/api/domains#iso-date-string) - **`updated_by`** `string | null` The user who last changed this domain. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### DnsRecordType `"txt" | "cname"` ### DnsRecordStatus `"unchecked" | "valid" | "invalid" | "missing" | "unavailable"` ### CertificateStatus `"none" | "provisioning" | "active" | "failed"` ### DomainTrafficPurpose `"ingest" | "pages"` What a domain serves. Stored on the domain. ### DomainLifecycleAction `"attach" | "reconcile" | "disable_ingest" | "disable_pages" | "delete_domain" | "delete_team"` ### DomainLifecycleStatus `"pending" | "processing" | "failed"` # List Domains ## Endpoint Retrieve a list of custom domains for the current team. ```http GET /v1/domains ``` **Scope:** `domains:read` ## Query Parameters - **`order_by`** `string` Field used to order the domains. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`, `"domain"`, `"certificate_status"`. - **`ownership_verified`** `string` Filter domains by ownership verification state. Optional. Allowed values: `"true"`, `"false"`. - **`certificate_status`** [`CertificateStatus`](/api/domains#certificate-status) Filter domains by the status of their TLS certificate. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Domain[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `ownership_verified` accepts the strings `true` and `false`. Any other value is rejected. - `after` and `before` are mutually exclusive. # Retrieve Domain ## Endpoint Retrieve a single custom domain, including the DNS records needed to verify and route it. ```http GET /v1/domains/:domain_id ``` **Scope:** `domains:read` ## Path Parameters - **`domain_id`** `string` -- **Required** Unique identifier of the domain. ## Response Domain retrieved ```ts { message: string; data: Domain; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create Domain ## Endpoint Add a custom domain to the current team. ```http POST /v1/domains ``` **Scope:** `domains:write` ## Request Body - **`domain`** `string` -- **Required** The custom domain to add, for example `analytics.example.com`. Stored in lowercase. Minimum length: `1`. Maximum length: `255`. - **`purpose`** [`DomainTrafficPurpose`](/api/domains#domain-traffic-purpose) Traffic purpose to configure for this domain. Use `ingest` to receive analytics data, or `pages` to serve status pages. Leave it out to add the domain without a purpose and choose one later. Optional. ## Response ```ts { message: string; data: Domain; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - The number of custom domains a team can add is limited by its billing plan. - A hostname can only be registered once. Adding one that already exists returns a conflict. - Some hostnames are reserved and cannot be added. - `domain` cannot contain a wildcard (`*`). Add each hostname you want to serve as its own domain. - `domain` must be a valid hostname such as `analytics.example.com`. Labels may contain letters, digits and hyphens, cannot start or end with a hyphen, and the top level domain must be at least two letters. # Check Domain DNS ## Endpoint Look up every DNS record this domain needs and report what is currently there. ```http POST /v1/domains/:domain_id/check ``` **Scope:** `domains:write` ## Path Parameters - **`domain_id`** `string` -- **Required** Unique identifier of the domain. ## Response ```ts { message: string; data: Domain; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - A check that completes always returns 200. A record that does not resolve is a result, not an error, so read the outcome from `ownership_status` and `routing_status` rather than the status code. - Ownership is checked first. Routing is only checked once ownership has been verified and the domain has a traffic purpose enabled. - A record that has never been looked up reports `unchecked`, which is not the same as `missing`. - A domain can be checked at most once every 30 seconds. # Update Domain ## Endpoint Update a domain's traffic purpose or SSO assignment. ```http POST /v1/domains/:domain_id ``` **Scope:** `domains:write` ## Path Parameters - **`domain_id`** `string` -- **Required** Unique identifier of the domain. ## Request Body - **`purpose`** [`DomainTrafficPurpose`](/api/domains#domain-traffic-purpose) What this domain serves. Ownership must be verified before a purpose can be set, and `null` takes the domain out of service. Omit to leave it unchanged. Optional. - **`is_sso_enabled`** `boolean` Whether SSO is assigned to this domain. Optional. ## Response ```ts { message: string; data: Domain; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Domain ownership must be verified before a purpose can be set. - A domain serves either ingest traffic or pages. Send `purpose: null` to take it out of service before setting the other, rather than switching between them directly. - Setting `purpose` to null queues infrastructure teardown. The domain keeps reporting its old purpose until that work completes. - Only one lifecycle operation runs at a time. If another is in progress, retry shortly. # Delete Domain ## Endpoint Delete a custom domain from the current team. ```http DELETE /v1/domains/:domain_id ``` **Scope:** `domains:delete` ## Path Parameters - **`domain_id`** `string` -- **Required** Unique identifier of the domain. ## Response ```ts { message: string; data: null; status: 202; error: null; pagination: null; endpoint: string; } ``` ## Comments - Deletion runs in the background. The domain remains listed with a pending lifecycle state until its edge configuration has been removed. ## Servers # Server Model ## Fields - **`object`** `"server"` - **`id`** `string` - **`project_id`** `string` - **`project_name`** `string` Display name of that project. - **`team_id`** `string` - **`name`** `string | null` Generated friendly name, for example `swift-hawk`. - **`sku`** `string` The server's size, as a named bundle of CPU and memory, for example `v1-1cpu-2gb`. - **`status`** [`ServerStatus`](/api/servers#server-status) Lifecycle state: `provisioning` until the server first comes up, then `active`. A paused free-trial server is `draining` while it finishes the data it accepted, then `idle`. A server removed by scaling down is `terminating` until it has finished that data and been deleted. - **`provisioning_phase`** [`ServerProvisioningPhase | null`](/api/servers#server-provisioning-phase) Why provisioning is still in flight (e.g. "awaiting_capacity"); null once active. - **`ordinal`** `number` The server's stable position in the project's fleet, starting at 0. - **`created_at`** [`ISODateString`](/api/servers#iso-date-string) - **`updated_at`** [`ISODateString`](/api/servers#iso-date-string) - **`heartbeat_at`** [`ISODateString | null`](/api/servers#iso-date-string) When the server last reported its vitals. Servers report every 30 seconds; null means it has never reported. - **`cpu_percent`** `number` CPU usage the server last reported, from 0 to 100. Zero until the first report. - **`memory_percent`** `number` Memory usage the server last reported, from 0 to 100. Zero until the first report. - **`spool_percent`** `number | null` Actual PVC fullness 0-100, derived as max(bytes, inodes), or null before the first heartbeat. - **`spool_bytes_percent`** `number | null` Actual PVC byte fullness 0-100, or null before the first heartbeat. - **`spool_inodes_percent`** `number | null` Actual PVC inode (file-count) fullness 0-100, or null before the first heartbeat. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### ServerStatus `"provisioning" | "active" | "upgrading" | "draining" | "idle" | "terminating"` ### ServerProvisioningPhase `"allocating" | "awaiting_capacity" | "attaching_storage" | "pulling_image" | "starting"` # Server Event Model ## Fields - **`object`** `"server_rollout_event"` - **`id`** `string` - **`project_id`** `string` - **`started_at`** [`ISODateString`](/api/servers#iso-date-string) When the deploy of the project's servers began. - **`completed_at`** [`ISODateString | null`](/api/servers#iso-date-string) When the deploy finished; null while it is still in progress. - **`image_tag`** `string | null` Version tag the deploy moves the project's servers to. - **`phase`** `string | null` The most recent step the deploy reached; null before the first step is recorded. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # List Servers ## Endpoint Retrieve a list of servers in a project. ```http GET /v1/projects/:project_id/servers ``` **Scope:** `servers:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field used to order the servers. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`, `"status"`. - **`status`** [`ServerStatus`](/api/servers#server-status) Filter by server status. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Server[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - A server is a dedicated machine that receives and processes the project's data. Every project runs its own fleet. - A server that is still coming up is returned with a status of `provisioning`, and a server on its way out with a status of `terminating`. - `after` and `before` are mutually exclusive. # Retrieve Server ## Endpoint Retrieve a single server. ```http GET /v1/projects/:project_id/servers/:server_id ``` **Scope:** `servers:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`server_id`** `string` -- **Required** Unique identifier of the server. ## Response Server retrieved ```ts { message: string; data: Server; status: 200; error: null; pagination: null; endpoint: string; } ``` # Scale Servers ## Endpoint Scale a project's fleet to a desired total number of servers. ```http POST /v1/projects/:project_id/servers ``` **Scope:** `servers:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`count`** `integer` -- **Required** Total number of servers the project should run after this request. This is the desired total, not the number of servers to add or remove. The maximum is the team's per-project server limit, which is set by its plan. Minimum: `0`. ## Response 200 ```ts { message: string; data: Server[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Response 202 ```ts { message: string; data: Server[]; status: 202; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `count` is the total number of servers the project should end up running, not the number to add. A project already running two servers reaches three by sending `count: 3`. - Scaling down is the same call with a lower `count`, and `count: 0` takes the whole fleet down. Tailglow chooses which servers to retire and drains them first, so they stay in the response with a status of `terminating` until they finish. - There is no endpoint that deletes an individual server. Removing capacity is always a scale request with a lower `count`. - Scaling up requires the team to have a payment method, and `count` must stay within the team's per-project server limit. - The response is the project's whole fleet after the request, not only the servers that changed. - Requesting the count the project already runs, with nothing in flight, returns a `409`. - During a platform update, a scale request is queued and answered with a `202`; it is applied once the update finishes, and the project's `queued_server_count` shows it meanwhile. A project that has no servers yet still gets its first server immediately. - Adding servers to a project that has not finished moving to the current platform version is queued the same way, even with no update in progress. Removing servers is not held back by it. - Requesting the count the project currently runs while a change is queued cancels the queued change, or returns a `409` if that change has already started. A newer request replaces an older queued one. # Update Server ## Endpoint Rename a server. ```http POST /v1/projects/:project_id/servers/:server_id ``` **Scope:** `servers:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`server_id`** `string` -- **Required** Unique identifier of the server. ## Request Body - **`name`** `string` -- **Required** Display name for the server. Minimum length: `1`. Maximum length: `64`. ## Response Server updated ```ts { message: string; data: Server; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - `name` is the only editable field on a server. It is a display label and does not change how data is routed or how much capacity the server has. - Renaming never adds or removes servers. Use `POST /v1/projects/:project_id/servers` to change how many servers the project runs. # Retrieve Server Vitals ## Endpoint Retrieve CPU, memory, and buffer usage for a server over a time range. ```http GET /v1/projects/:project_id/servers/:server_id/vitals ``` **Scope:** `servers:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`server_id`** `string` -- **Required** Unique identifier of the server. ## Query Parameters - **`start_at`** [`ISODateString`](/api/servers#iso-date-string) Start time (ISO format, default: 12 hours ago). Optional. - **`end_at`** [`ISODateString`](/api/servers#iso-date-string) End time (ISO format, default: now). Optional. - **`interval`** `string` Aggregation interval. Optional. Defaults to `"minute"`. Allowed values: `"minute"`, `"hour"`. ## Response Vitals retrieved ```ts { message: string; data: TimeseriesAggregation; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - The response carries Worker CPU, Worker Memory, Buffer, Bytes, and Inodes series, plus ingress CPU and memory when available, bucketed by `interval`. - Older points come from archived data and recent points come from the running server, stitched into one continuous timeline. A server replaced by a platform deploy does not break the series. - Without `start_at` and `end_at` the range is the last 12 hours. # Retrieve Server Pipeline ## Endpoint Retrieve queue depth, throughput, and error counts for a server over a time range. ```http GET /v1/projects/:project_id/servers/:server_id/pipeline ``` **Scope:** `servers:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`server_id`** `string` -- **Required** Unique identifier of the server. ## Query Parameters - **`start_at`** [`ISODateString`](/api/servers#iso-date-string) Start time (ISO format, default: 12 hours ago). Optional. - **`end_at`** [`ISODateString`](/api/servers#iso-date-string) End time (ISO format, default: now). Optional. - **`interval`** `string` Aggregation interval. Optional. Defaults to `"minute"`. Allowed values: `"minute"`, `"hour"`. ## Response Pipeline retrieved ```ts { message: string; data: TimeseriesAggregation; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Pending averages valid queued records, Throughput counts drained records, and Errors counts rejected requests and dropped frames. Older pending history without record counts is unknown. - Takes the same range and interval parameters as the vitals endpoint, so the two can be read over the same window. - Without `start_at` and `end_at` the range is the last 12 hours. # List Server Events ## Endpoint Retrieve the platform events recorded for a server's project over a time range. ```http GET /v1/projects/:project_id/servers/:server_id/events ``` **Scope:** `servers:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`server_id`** `string` -- **Required** Unique identifier of the server. ## Query Parameters - **`start_at`** [`ISODateString`](/api/servers#iso-date-string) -- **Required** Earliest event date and time to return (ISO format). - **`end_at`** [`ISODateString`](/api/servers#iso-date-string) -- **Required** Latest event date and time to return (ISO format). - **`type`** `string` Filter by event type. Optional. Allowed values: `"rollout"`. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: ServerRolloutEvent[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - An event is a Tailglow deploy of the project's servers. Requesting events over the same window as the vitals and pipeline endpoints shows whether a change in those charts lines up with a deploy. - `start_at` and `end_at` are both required. - An event whose `completed_at` is `null` is still in progress. - Events belong to the project, so every server in the project returns the same list. - `after` and `before` are mutually exclusive. ## Drains # Drain Model ## Fields - **`object`** `"drain"` - **`id`** `string` Unique identifier, prefixed with `drn_`. - **`project_id`** `string` - **`team_id`** `string` - **`name`** `string` - **`collection_id`** `string | null` The collection whose records are forwarded. Null when the drain reads from a view. - **`view_id`** `string | null` The view whose records are forwarded. Null when the drain reads from a collection. - **`destination_url`** `string` The HTTPS URL records are delivered to. - **`headers_configured`** `string[]` Names of the headers sent with every delivery. The values are stored encrypted and are never returned, so this shows what was configured without revealing the secrets. - **`body_format`** [`DrainBodyFormat`](/api/drains#drain-body-format) The shape of each delivered request body. - **`compression`** [`DrainCompression`](/api/drains#drain-compression) The compression applied to each delivered request body. - **`backfill_enabled`** `boolean` Whether records that already existed when the drain first activated were delivered too. Decided once at first activation and cannot be changed afterwards. - **`exclude_fields`** `string[]` Top-level field names removed from every record before delivery, for destinations that reject fields they do not expect. Empty means nothing is removed. - **`status`** [`DrainStatus`](/api/drains#drain-status) Where the drain is in its lifecycle, from unverified through delivering or paused. - **`schedule_cron`** `string` Cron expression setting how often undelivered records are looked for, evaluated in UTC. A drain that is behind keeps delivering without waiting for the next run, so this controls how quickly new records are picked up rather than how fast a backlog clears. - **`next_send_at`** [`ISODateString | null`](/api/drains#iso-date-string) When the drain is next due to look for records. Null means no time is set rather than nothing scheduled: on an active drain it is due immediately, and on a stopped one it is ignored. Whether a drain runs at all is `status`. - **`verified_at`** [`ISODateString | null`](/api/drains#iso-date-string) When the destination was proven reachable. Null until the drain is verified. - **`last_success_at`** [`ISODateString | null`](/api/drains#iso-date-string) When the destination last accepted a delivery. Null if it never has. - **`last_failure_at`** [`ISODateString | null`](/api/drains#iso-date-string) When a delivery last failed. Null if none ever has. - **`consecutive_failure_count`** `number` How many deliveries have failed in a row. Resets to zero on the next success. - **`last_error`** `string | null` What went wrong on the most recent failed delivery. Null if none ever has. - **`last_batch_size`** `number` How many records were in the most recent successful delivery. - **`records_sent_hourly`** `DrainHourlyRecords[]` The last 24 hours of delivery volume, oldest first. Always 24 entries, so an hour with no deliveries reads as a zero rather than being absent, and a drain that has never sent still returns a full window of zeros. Sum the counts for "records sent in the last 24 hours". - **`created_at`** [`ISODateString`](/api/drains#iso-date-string) - **`updated_at`** [`ISODateString`](/api/drains#iso-date-string) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### DrainBodyFormat `"ndjson" | "json"` ### DrainCompression `"none" | "gzip"` ### DrainStatus `"draft" | "pending_verification" | "active" | "paused" | "disabled"` # List Drains ## Endpoint Retrieve a list of drains for a project. ```http GET /v1/projects/:project_id/drains ``` **Scope:** `drains:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field the results are ordered by. Optional. Defaults to `"created_at"`. Allowed values: `"name"`, `"created_at"`. - **`status`** [`DrainStatus`](/api/drains#drain-status) Return only drains in this state. Optional. - **`collection_id`** `string` Return only drains that read from this collection. Optional. - **`view_id`** `string` Return only drains that read from this view. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Drain[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Drain ## Endpoint Retrieve a single drain. ```http GET /v1/projects/:project_id/drains/:drain_id ``` **Scope:** `drains:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`drain_id`** `string` -- **Required** Unique identifier of the drain. ## Response Drain retrieved ```ts { message: string; data: Drain; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create Drain ## Endpoint Create a drain that forwards records from one collection or view to an external destination. ```http POST /v1/projects/:project_id/drains ``` **Scope:** `drains:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** Name shown for this drain. Minimum length: `2`. Maximum length: `128`. - **`collection_id`** `string | null` Collection whose records are forwarded. Set this or `view_id`, not both. Optional. - **`view_id`** `string | null` View whose records are forwarded. Set this or `collection_id`, not both. Optional. - **`destination_url`** `string` -- **Required** HTTPS URL records are delivered to. Must resolve to a public address. Minimum length: `1`. Maximum length: `2048`. - **`headers`** `object | null` Headers sent with every delivery, for authenticating to the destination. Stored encrypted and never returned; responses list only the header names, as `headers_configured`. Optional. - **`body_format`** [`DrainBodyFormat`](/api/drains#drain-body-format) Shape of each delivered request body. Optional. - **`compression`** [`DrainCompression`](/api/drains#drain-compression) Compression applied to each delivered request body. Optional. - **`backfill_enabled`** `boolean` Whether records that already existed when the drain first activates are delivered too. Decided once at first activation and cannot be changed afterwards. Optional. - **`exclude_fields`** `string[]` Top-level field names stripped from every record before delivery, for destinations that reject fields they do not expect. Optional. - **`schedule_cron`** `string` Cron expression setting how often undelivered records are looked for, evaluated in UTC. Defaults to hourly. A drain that is behind keeps delivering without waiting for the next run, so this sets how quickly new records are picked up, not how fast a backlog clears. Optional. Minimum length: `1`. Maximum length: `128`. ## Response ```ts { message: string; data: Drain; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - The destination must be reachable over HTTPS at a public address. Private, loopback and link-local addresses are rejected. - A new drain starts unverified and sends nothing. Verify it before it delivers records. - A destination that is Tailglow ingest or a domain this team has verified is trusted, so it skips verification and is activated on create. - A trusted destination that would write back into the same collection the drain reads from is rejected, because it would loop. - Exactly one of `collection_id` or `view_id` must be set. A drain reads from one container. - `headers` accepts at most 20 entries. - `exclude_fields` accepts at most 50 entries, each a top-level key of at most 256 characters. Dots, whitespace, wildcards and newlines are rejected. Entries are trimmed and duplicates removed. - `schedule_cron` accepts a five-field expression evaluated in UTC. Second-level precision and hashed fields are rejected; the shortest supported gap is one minute. # Update Drain ## Endpoint Update a drain's name, payload format, compression, or excluded fields. ```http POST /v1/projects/:project_id/drains/:drain_id ``` **Scope:** `drains:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`drain_id`** `string` -- **Required** Unique identifier of the drain. ## Request Body - **`name`** `string` Name shown for this drain. Optional. Minimum length: `2`. Maximum length: `128`. - **`body_format`** [`DrainBodyFormat`](/api/drains#drain-body-format) Shape of each delivered request body. Optional. - **`compression`** [`DrainCompression`](/api/drains#drain-compression) Compression applied to each delivered request body. Optional. - **`exclude_fields`** `string[]` Top-level field names stripped from every record before delivery, for destinations that reject fields they do not expect. Optional. - **`schedule_cron`** `string` Cron expression setting how often undelivered records are looked for, evaluated in UTC. Defaults to hourly. A drain that is behind keeps delivering without waiting for the next run, so this sets how quickly new records are picked up, not how fast a backlog clears. Optional. Minimum length: `1`. Maximum length: `128`. ## Response Drain updated ```ts { message: string; data: Drain; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - `destination_url`, `headers` and `backfill_enabled` cannot be changed. Changing the URL or headers would invalidate the proof of access established at verification, and backfill is decided once when the drain first activates. Delete the drain and create a new one instead. - At least one field must be provided. - Any field not listed here is rejected, including `destination_url`, `headers` and `backfill_enabled`, which cannot be changed after create. - `exclude_fields` accepts at most 50 entries, each a top-level key of at most 256 characters. Dots, whitespace, wildcards and newlines are rejected. Entries are trimmed and duplicates removed. - `schedule_cron` accepts a five-field expression evaluated in UTC. Second-level precision and hashed fields are rejected; the shortest supported gap is one minute. # Delete Drain ## Endpoint Delete a drain and stop all delivery to its destination. ```http DELETE /v1/projects/:project_id/drains/:drain_id ``` **Scope:** `drains:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`drain_id`** `string` -- **Required** Unique identifier of the drain. ## Response Drain deleted ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` # Verify Drain ## Endpoint Send a verification marker to the drain's destination and return the destination's response. ```http POST /v1/projects/:project_id/drains/:drain_id/verify ``` **Scope:** `drains:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`drain_id`** `string` -- **Required** Unique identifier of the drain. ## Response 200 (1) Drain auto-verified — destination is infrastructure you control. ```ts { message: string; data: Drain; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Response 200 (2) Verification marker sent ```ts { message: string; data: { drain: Drain; response: { status: number; status_text: string; ok: boolean; response_time_ms: number; body_preview: string; } }; status: 200; error: null; pagination: null; endpoint: string; } ``` ### Additional Response Fields - **`drain`** [`Drain`](/api/drains#model) -- **Required** The drain as it stands after the verification attempt. - **`response`** `{ status: number; status_text: string; ok: boolean; response_time_ms: number; body_preview: string; }` -- **Required** What the destination replied with, including a non-2xx status. ## Comments - Proving control of the destination takes two steps. This one delivers a marker token to the destination; read that token from what the destination received and send it back to `verify_confirm`. - The marker token is never included in this response. Reading it from the destination is what proves access, so echoing it here would defeat the check. - A destination that has since become trusted infrastructure is activated immediately and returns the drain with no marker sent. - The `response` field reports what the destination replied with, including non-2xx statuses, so a misconfigured endpoint can be diagnosed without reading logs. # Confirm Drain Verification ## Endpoint Confirm a drain by sending back the marker token the destination received. ```http POST /v1/projects/:project_id/drains/:drain_id/verify_confirm ``` **Scope:** `drains:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`drain_id`** `string` -- **Required** Unique identifier of the drain. ## Request Body - **`token`** `string` -- **Required** The marker token the destination received from the verify request. Minimum length: `1`. Maximum length: `128`. ## Response Drain verified ```ts { message: string; data: Drain; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Send the token that arrived at the destination from `verify`. A correct token activates the drain and it begins delivering records. # Pause Drain ## Endpoint Pause a drain so it stops delivering records without losing its verification. ```http POST /v1/projects/:project_id/drains/:drain_id/pause ``` **Scope:** `drains:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`drain_id`** `string` -- **Required** Unique identifier of the drain. ## Response Drain paused ```ts { message: string; data: Drain; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - A paused drain keeps its position, so resuming continues from where it stopped rather than re-sending or skipping records. # Resume Drain ## Endpoint Resume a paused drain and continue delivering records from where it stopped. ```http POST /v1/projects/:project_id/drains/:drain_id/resume ``` **Scope:** `drains:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`drain_id`** `string` -- **Required** Unique identifier of the drain. ## Response Drain resumed ```ts { message: string; data: Drain; status: 200; error: null; pagination: null; endpoint: string; } ``` # Send Drain Sample ## Endpoint Send a sample payload to the drain's destination and return the destination's response. ```http POST /v1/projects/:project_id/drains/:drain_id/sample ``` **Scope:** `drains:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`drain_id`** `string` -- **Required** Unique identifier of the drain. ## Response ```ts { message: string; data: { status: number; status_text: string; ok: boolean; response_time_ms: number; body_preview: string }; status: 200; error: null; pagination: null; endpoint: string; } ``` ### Additional Response Fields - **`status`** `number` -- **Required** The HTTP status the destination replied with. - **`status_text`** `string` -- **Required** The status text that came with it. - **`ok`** `boolean` -- **Required** Whether the destination accepted the request. - **`response_time_ms`** `number` -- **Required** How long the destination took to reply, in milliseconds. - **`body_preview`** `string` -- **Required** The start of the destination's response body, for diagnosing a rejection. ## Comments - Use this to check the destination accepts the payload shape before or after activating the drain. The sample is not part of the record stream and does not move the drain's position. - A non-2xx reply is returned rather than raised, so the status and body preview can be read directly from the response. ## Pulls # Pull Model ## Fields - **`object`** `"pull"` Always `"pull"`. - **`id`** `string` Unique identifier, prefixed with `pul_`. - **`project_id`** `string` The project this pull belongs to. - **`team_id`** `string` The team that owns the pull. - **`name`** `string` Display name for the pull. - **`source_id`** `string` The source fetched records are written to. - **`source_name`** `string | null` Display name of that source. - **`collection_slug`** `string | null` The collection within the source that records land in. Defaults to a slug of the pull name. - **`endpoint_url`** `string` The HTTPS URL that is fetched on each run. - **`method`** [`PullMethod`](/api/pulls#pull-method) The HTTP method used to fetch the endpoint. - **`headers_configured`** `string[]` Names of the headers sent with every fetch. The values are stored encrypted and are never returned, so this shows what was configured without revealing the secrets. - **`request_body`** `string | null` The request body sent when the method is `post`. Null for `get`. - **`json_records_path`** `string | null` Dot path to the array of records inside a JSON response, such as `data` or `data.result`. Null when the response is stored exactly as it arrives. - **`schedule_cron`** `string` Cron expression setting when the endpoint is fetched, evaluated in UTC. - **`status`** [`PullStatus`](/api/pulls#pull-status) The current state of the pull. - **`next_fetch_at`** [`ISODateString | null`](/api/pulls#iso-date-string) When the next fetch is due. Null when the pull is paused or disabled, because nothing is scheduled: a time here would promise a fetch that will not happen. - **`missed_slot_count`** `number` How many scheduled slots have elapsed without a fetch, since the pull was created or last resumed. Almost always because the project had no healthy server at the time. Missed slots are counted rather than fetched late. A pull records whatever its endpoint serves at the moment of the request, so a delayed fetch would return current data stamped with a time it does not describe. A rising count next to a healthy `last_success_at` means the schedule is finer than the project's capacity has been able to keep up with. - **`last_attempt_at`** [`ISODateString | null`](/api/pulls#iso-date-string) When the endpoint was last fetched, whether or not it succeeded. - **`last_success_at`** [`ISODateString | null`](/api/pulls#iso-date-string) When records were last fetched and accepted. - **`last_failure_at`** [`ISODateString | null`](/api/pulls#iso-date-string) When a fetch last failed. - **`consecutive_failure_count`** `number` How many fetches have failed in a row. Resets to zero on the next success. - **`last_error`** `string | null` The error from the most recent failed fetch. - **`last_error_stage`** [`PullErrorStage | null`](/api/pulls#pull-error-stage) Which step of the most recent failed fetch went wrong. - **`last_http_status`** `number | null` The HTTP status the endpoint returned on the most recent fetch. - **`last_response_time_ms`** `number | null` How long the most recent fetch took, in milliseconds. - **`last_record_count`** `number` How many records the most recent successful fetch produced. - **`records_pulled_hourly`** `PullHourlyRecords[]` The last 24 hours of fetch volume, oldest first. Always 24 entries, so an hour with no fetches reads as a zero rather than being absent, and a pull that has never run still returns a full window of zeros. Sum the counts for "records pulled in the last 24 hours". - **`created_at`** [`ISODateString`](/api/pulls#iso-date-string) When the pull was created. - **`updated_at`** [`ISODateString`](/api/pulls#iso-date-string) When the pull was last changed. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### PullMethod `"get" | "post"` ### PullStatus `"active" | "paused" | "disabled"` ### PullErrorStage `"request" | "response" | "parse" | "ingest"` # Pull Test Result ## Fields - **`ok`** `boolean` Whether the endpoint responded successfully and the response could be read as records. - **`status`** `number` The HTTP status the endpoint returned. Zero when no response was received at all. - **`status_text`** `string` The HTTP status text the endpoint returned. - **`response_time_ms`** `number` How long the fetch took, in milliseconds. - **`byte_length`** `number` How many bytes the endpoint returned. - **`record_count`** `number` How many records the response would produce. Zero when the test failed. - **`body_preview`** `string` The first 2 KB of the response body. - **`error_stage`** [`PullErrorStage | null`](/api/pulls#pull-error-stage) Which step went wrong. Null when the test succeeded. - **`error`** `string | null` What went wrong. Null when the test succeeded. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### PullErrorStage `"request" | "response" | "parse" | "ingest"` # List Pulls ## Endpoint Retrieve a list of pulls. ```http GET /v1/projects/:project_id/pulls ``` **Scope:** `pulls:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field the results are ordered by. Optional. Defaults to `"created_at"`. Allowed values: `"name"`, `"created_at"`, `"last_success_at"`. - **`status`** `string` Return only pulls in this state. Optional. Allowed values: `"active"`, `"paused"`, `"disabled"`. - **`source_id`** `string` Return only pulls that write to this source. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Pull[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Pull ## Endpoint Retrieve a single pull. ```http GET /v1/projects/:project_id/pulls/:pull_id ``` **Scope:** `pulls:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`pull_id`** `string` -- **Required** Unique identifier of the pull. ## Response Pull retrieved ```ts { message: string; data: Pull; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create Pull ## Endpoint Create a scheduled pull in a project. ```http POST /v1/projects/:project_id/pulls ``` **Scope:** `pulls:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** Name shown for this pull. Minimum length: `2`. Maximum length: `128`. - **`source_id`** `string` -- **Required** Source that fetched records are written to. Minimum length: `1`. - **`collection_slug`** `string | null` Collection within the source that records land in. Leave unset and it is derived from the pull name, so each pull gets its own stream. Optional. - **`endpoint_url`** `string` -- **Required** HTTPS URL fetched on every run. Must resolve to a public address. Minimum length: `1`. Maximum length: `2048`. - **`method`** `string` HTTP method used to fetch the endpoint. Optional. Defaults to `"get"`. Allowed values: `"get"`, `"post"`. - **`headers`** `object | null` Headers sent with every fetch, for authenticating to the endpoint. Stored encrypted and never returned; responses list only the header names, as `headers_configured`. Optional. - **`request_body`** `string | null` Body sent with every fetch. Only valid when `method` is `post`, for endpoints that answer queries over POST. Optional. - **`json_records_path`** `string | null` Dot path to the array of records inside a JSON response, for example `data` or `data.result`. Leave unset to store the response exactly as it arrives. Optional. - **`schedule_cron`** `string` Cron expression setting when the endpoint is fetched, evaluated in UTC. Defaults to every minute, which is also the shortest supported gap. Optional. Defaults to `"* * * * *"`. Minimum length: `1`. Maximum length: `128`. ## Response Pull created ```ts { message: string; data: Pull; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - Pull names are unique within a project. - The endpoint must be reachable over HTTPS at a public address. Addresses inside private or reserved ranges are rejected, and the check is repeated on every fetch, not just at create. - A pull is created `active` even if the project has no servers yet. It starts fetching as soon as a server exists; an empty fleet delays the first fetch rather than changing the status. - An endpoint answering with a Prometheus HTTP Service Discovery document is followed rather than stored. Each discovered target is fetched, its metrics parsed into records, and the target's labels merged onto them so targets stay distinguishable. This is what makes an endpoint that hands out short-lived signed URLs work on a schedule: the discovery response is re-read on every run, so the credentials are always current. - Discovered targets are fetched over HTTPS at public addresses only, checked with the same guard as the endpoint itself, so a discovery response cannot direct a pull at a private address. - A pull follows at most 50 discovered targets and fails if the document lists more, rather than fetching some and silently omitting the rest. Individual targets are retried; if some still fail, the run succeeds with the records it did collect and reports how many targets did not. - `request_body` is only accepted when `method` is `post`. Sending one with a `get` pull is rejected rather than ignored, so a half-configured pull fails at create time instead of quietly fetching the wrong thing. - `headers` accepts at most 20 entries. A header whose value is `null` is ignored here, since on create there is nothing yet for it to remove. Names are matched case-insensitively, so two spellings of one name are stored as a single header. - `schedule_cron` must be a valid cron expression. It is evaluated in UTC, and the finest granularity is one minute. - `collection_slug` must be lowercase, start with a letter or digit, and may otherwise contain digits, letters, hyphens and underscores. - `json_records_path` is for endpoints that wrap their rows in an envelope. An endpoint returning `{"data": [{...}, {...}]}` stores one record containing the whole response unless you set the path to `data`, which stores the two records instead. Nested keys are joined with dots (`data.result`). Object keys only: array indexes and wildcards are not supported. - `json_records_path` applies only to JSON responses. JSONL, CSV, TSV and Prometheus responses already produce one record per row, so leave it unset for those. - A fetch fails with a `parse` error when the path is missing from the response or does not resolve to a list or object, rather than falling back to storing the whole document. Use the test endpoint to check a path against a live response before saving. # Update Pull ## Endpoint Update a pull. ```http POST /v1/projects/:project_id/pulls/:pull_id ``` **Scope:** `pulls:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`pull_id`** `string` -- **Required** Unique identifier of the pull. ## Request Body - **`name`** `string` Name shown for this pull. Optional. Minimum length: `2`. Maximum length: `128`. - **`collection_slug`** `string | null` Collection within the source that records land in. Leave unset and it is derived from the pull name, so each pull gets its own stream. Optional. - **`endpoint_url`** `string` HTTPS URL fetched on every run. Must resolve to a public address. Optional. Minimum length: `1`. Maximum length: `2048`. - **`method`** `string` HTTP method used to fetch the endpoint. Optional. Allowed values: `"get"`, `"post"`. - **`headers`** `object | null` Headers sent with every fetch, for authenticating to the endpoint. Stored encrypted and never returned; responses list only the header names, as `headers_configured`. Optional. - **`request_body`** `string | null` Body sent with every fetch. Only valid when `method` is `post`, for endpoints that answer queries over POST. Optional. - **`json_records_path`** `string | null` Dot path to the array of records inside a JSON response, for example `data` or `data.result`. Leave unset to store the response exactly as it arrives. Optional. - **`schedule_cron`** `string` Cron expression setting when the endpoint is fetched, evaluated in UTC. Defaults to every minute, which is also the shortest supported gap. Optional. Minimum length: `1`. Maximum length: `128`. ## Response Pull updated ```ts { message: string; data: Pull; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Changes take effect on the next fetch; a fetch already in flight finishes under the old configuration. - A changed `schedule_cron` takes effect from the next fetch onward. - At least one field must be provided. - Any field not listed here is rejected, including `source_id`, which cannot be changed after create. Create a new pull to write into a different source. - Clearing `request_body` is required before changing `method` from `post` to `get`; a pull cannot keep a body it would never send. - `headers` is a patch, not a replacement, because the values are write-only and never returned. A name mapped to a string adds or replaces that header, a name mapped to `null` removes it, and a name you do not mention keeps its stored value. Omit the field to leave every header alone, or send `null` in place of the object to remove all of them. - `headers` names are matched case-insensitively, so patching `authorization` replaces a stored `Authorization` rather than adding a second header. The spelling you send is the one stored and sent. - `headers` accepts at most 20 entries, counted after the patch is applied. - `schedule_cron` must be a valid cron expression, evaluated in UTC. - Send `json_records_path` as `null` to stop unwrapping and store responses whole again. # Delete Pull ## Endpoint Delete a pull. ```http DELETE /v1/projects/:project_id/pulls/:pull_id ``` **Scope:** `pulls:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`pull_id`** `string` -- **Required** Unique identifier of the pull. ## Response Pull deleted ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Records the pull already wrote are not deleted. They belong to the source and stay queryable. # Pause Pull ## Endpoint Pause a pull so it stops fetching. ```http POST /v1/projects/:project_id/pulls/:pull_id/pause ``` **Scope:** `pulls:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`pull_id`** `string` -- **Required** Unique identifier of the pull. ## Response Pull paused ```ts { message: string; data: Pull; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Only an active pull can be paused. Pausing an already-paused pull succeeds and changes nothing. # Resume Pull ## Endpoint Resume a paused pull. ```http POST /v1/projects/:project_id/pulls/:pull_id/resume ``` **Scope:** `pulls:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`pull_id`** `string` -- **Required** Unique identifier of the pull. ## Response Pull resumed ```ts { message: string; data: Pull; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Resumes a pull you paused, and also re-enables one the system disabled after a long failure streak. Resuming clears the failure count, so it starts from a clean slate. # Test Pull ## Endpoint Fetch the endpoint once without storing anything. ```http POST /v1/projects/:project_id/pulls/:pull_id/test ``` **Scope:** `pulls:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`pull_id`** `string` -- **Required** Unique identifier of the pull. ## Response ```ts { message: string; data: PullTestResult; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Nothing is ingested and no health field or schedule is changed, so this is safe to run against a live pull. - The response reports the HTTP status, how long the fetch took, how many records the configured format would produce, and the first 2 KB of the body. ## Checks # Check Model ## Fields - **`object`** `"check"` - **`id`** `string` - **`project_id`** `string` - **`team_id`** `string` - **`name`** `string` - **`source_id`** `string` The source that observations are written to. Nothing else is stored. - **`source_name`** `string | null` - **`collection_slug`** `string` The collection within the source that observations land in. Give several checks the same slug to chart them together, one strip per check under a worst-of overall row. - **`endpoint_url`** `string` The HTTPS URL requested on every run. - **`method`** [`CheckMethod`](/api/checks#check-method) - **`headers_configured`** `string[]` Names of the headers sent with every request. The values are stored encrypted and are never returned, so this shows what was configured without revealing the secrets. - **`request_body`** `string | null` The request body sent when the method is `post`. Null for `get`. - **`schedule_cron`** `string` Cron expression setting when the endpoint is requested, evaluated in UTC. - **`check_retry_seconds`** `number | null` How long to wait before one confirming request settles a failed run. Null records the first result as it stands, which turns a single flake into a minute of recorded downtime. - **`status`** [`CheckStatus`](/api/checks#check-status) The current state. A check is only ever stopped by you pausing it or by the team falling out of good standing. A failing endpoint never stops it, because the outage is the thing it is there to record. - **`next_fetch_at`** [`ISODateString | null`](/api/checks#iso-date-string) When the next run is due. Null while the check is paused or disabled. - **`missed_slot_count`** `number` How many scheduled slots have elapsed without a run, since the check was created or last resumed. Almost always because the project had no healthy server at the time. Missed slots are counted rather than run late: a slot describes the endpoint at one moment, so a late request would report the wrong minute. These are gaps in the uptime record, not downtime. - **`last_up`** `boolean | null` Whether the most recent run found the endpoint up, meaning it answered with a 2xx. Null until the first run settles, and null again after a resume, which is what separates a check nothing has measured yet from one measured to be down. - **`results_hourly`** `CheckHourlyResults[]` The last 24 hours of results, oldest first. Always 24 entries, so an hour with no runs reads as zeros rather than being absent, and a check that has never run still returns a full window. `up / (up + down)` over the window is the uptime for that period. - **`last_checked_at`** [`ISODateString | null`](/api/checks#iso-date-string) When the endpoint was last requested, whether or not it answered. Cleared by a resume. - **`last_success_at`** [`ISODateString | null`](/api/checks#iso-date-string) When the endpoint last returned a 2xx. Survives a pause, so it dates an ongoing outage. - **`last_failure_at`** [`ISODateString | null`](/api/checks#iso-date-string) When the endpoint last failed to return a 2xx. Survives a pause. - **`consecutive_failure_count`** `number` How many runs have failed in a row. Resets on the next success. Reporting only: the count never stops the check, however high it climbs. - **`last_error`** `string | null` The error from the most recent failed run. - **`last_error_stage`** [`CheckErrorStage | null`](/api/checks#check-error-stage) Which step of the most recent failed run went wrong. - **`last_http_status`** `number | null` The HTTP status returned by the most recent run. Null when nothing answered. - **`last_response_time_ms`** `number | null` How long the most recent run took, in milliseconds. - **`created_at`** [`ISODateString`](/api/checks#iso-date-string) - **`updated_at`** [`ISODateString`](/api/checks#iso-date-string) ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### CheckMethod `"get" | "post"` Stored as plain strings rather than Postgres enums: nothing queries by either, so a database enum would only buy DDL on every added value. `CheckStatus` stays an enum because it IS queried, and backs the dispatch index. ### CheckStatus `"active" | "paused" | "disabled"` ### CheckErrorStage `"request" | "response"` # Check Test Result ## Fields - **`ok`** `boolean` Whether the endpoint answered with a 2xx. - **`status`** `number` The HTTP status the endpoint returned. Zero when no response was received at all. - **`status_text`** `string` - **`response_time_ms`** `number` How long the request took, in milliseconds. - **`byte_length`** `number` How many bytes the endpoint returned. - **`body_preview`** `string` The first 2 KB of the response body, for confirming you reached the endpoint you meant to. - **`error_stage`** [`CheckErrorStage | null`](/api/checks#check-error-stage) Which step went wrong. Null when the test succeeded. - **`error`** `string | null` What went wrong. Null when the test succeeded. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### CheckErrorStage `"request" | "response"` # List Checks ## Endpoint Retrieve a list of checks. ```http GET /v1/projects/:project_id/checks ``` **Scope:** `checks:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Query Parameters - **`order_by`** `string` Field the results are ordered by. Optional. Defaults to `"created_at"`. Allowed values: `"name"`, `"created_at"`. - **`status`** `string` Return only checks in this state. Optional. Allowed values: `"active"`, `"paused"`, `"disabled"`. - **`source_id`** `string` Return only checks that write their observations to this source. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Check[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - `after` and `before` are mutually exclusive. # Retrieve Check ## Endpoint Retrieve a single check. ```http GET /v1/projects/:project_id/checks/:check_id ``` **Scope:** `checks:read` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`check_id`** `string` -- **Required** Unique identifier of the check. ## Response Check retrieved ```ts { message: string; data: Check; status: 200; error: null; pagination: null; endpoint: string; } ``` # Create Check ## Endpoint Create a scheduled check in a project. ```http POST /v1/projects/:project_id/checks ``` **Scope:** `checks:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. ## Request Body - **`name`** `string` -- **Required** Name shown for this check. Minimum length: `2`. Maximum length: `128`. - **`source_id`** `string` -- **Required** Source that observations are written to. Nothing else about the response is stored. Minimum length: `1`. - **`collection_slug`** `string` -- **Required** Collection within the source that observations land in. Give several checks the same slug to chart them together, one strip per check under a worst-of overall row. Minimum length: `1`. Maximum length: `64`. - **`endpoint_url`** `string` -- **Required** HTTPS URL requested on every run. Must resolve to a public address. Minimum length: `1`. Maximum length: `2048`. - **`method`** `string` HTTP method used to request the endpoint. Optional. Defaults to `"get"`. Allowed values: `"get"`, `"post"`. - **`headers`** `object | null` Headers sent with every request, for authenticating to the endpoint. Stored encrypted and never returned; responses list only the header names, as `headers_configured`. Optional. - **`request_body`** `string | null` Body sent with every request. Only valid when `method` is `post`, for health endpoints that answer queries over POST. Optional. - **`schedule_cron`** `string` Cron expression setting when the endpoint is requested, evaluated in UTC. Defaults to every minute, which is also the shortest supported gap. Optional. Defaults to `"* * * * *"`. Minimum length: `1`. Maximum length: `128`. - **`check_retry_seconds`** `integer | null` Seconds to wait before one confirming request settles a failed run. Send `null` to record the first result as it stands. Optional. Defaults to `10`. ## Response Check created ```ts { message: string; data: Check; status: 201; error: null; pagination: null; endpoint: string; } ``` ## Comments - The endpoint must be reachable over HTTPS at a public address. Addresses inside private or reserved ranges are rejected, and the check is repeated on every run, not just at create. - A check is created `active` even if the project has no servers yet. It starts running as soon as a server exists; an empty fleet delays the first run rather than changing the status. - The response body is never stored or parsed. Each run writes one observation recording whether the endpoint answered, its status code and how long it took. - A failing endpoint never stops a check, however long the failure lasts. Only pausing it, or the team falling out of good standing, stops one. - `request_body` is only accepted when `method` is `post`. Sending one with a `get` check is rejected rather than ignored, so a half-configured check fails at create time instead of quietly measuring the wrong request. - `headers` accepts at most 20 entries. A header whose value is `null` is ignored here, since on create there is nothing yet for it to remove. Names are matched case-insensitively, so two spellings of one name are stored as a single header. - `schedule_cron` must be a valid cron expression. It is evaluated in UTC, and the finest granularity is one minute. - `collection_slug` is required, and must be lowercase, start with a letter or digit, and may otherwise contain digits, letters, hyphens and underscores. Naming it here is what lets several checks deliberately share one collection and chart together; renaming the check later never moves the series, because the slug is stored rather than derived. - `check_retry_seconds` is between 1 and 20, and defaults to 10. A failed run waits this long and requests once more before it is recorded, so a single flake does not become a recorded minute of downtime. Send `null` to record the first result as it stands. - Each run writes one observation to `collection_slug` carrying `check_id`, `check_name`, `checked_at`, `up`, `http_status`, `response_time_ms`, `error_stage`, `error_message` and `attempts`. `up` is 1 when the endpoint returned a 2xx and 0 when it did not answer or answered with an error status, so the average of `up` over a period is the uptime for that period. - `check_name` is the name the check carried when the run was recorded, so a chart grouped on `check_id` can label its series with something readable. Renaming the check does not rewrite observations already stored. - `checked_at` is the scheduled minute rather than the moment the observation was written, so a run delayed by a confirming request still lands in the minute it describes. - `name` must be unique within the project, so a check is identifiable in a list and in the strip it charts as. # Update Check ## Endpoint Update a check. ```http POST /v1/projects/:project_id/checks/:check_id ``` **Scope:** `checks:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`check_id`** `string` -- **Required** Unique identifier of the check. ## Request Body - **`name`** `string` Name shown for this check. Optional. Minimum length: `2`. Maximum length: `128`. - **`collection_slug`** `string | null` Collection within the source that observations land in. Give several checks the same slug to chart them together, one strip per check under a worst-of overall row. Optional. - **`endpoint_url`** `string` HTTPS URL requested on every run. Must resolve to a public address. Optional. Minimum length: `1`. Maximum length: `2048`. - **`method`** `string` HTTP method used to request the endpoint. Optional. Allowed values: `"get"`, `"post"`. - **`headers`** `object | null` Headers sent with every request, for authenticating to the endpoint. Stored encrypted and never returned; responses list only the header names, as `headers_configured`. Optional. - **`request_body`** `string | null` Body sent with every request. Only valid when `method` is `post`, for health endpoints that answer queries over POST. Optional. - **`schedule_cron`** `string` Cron expression setting when the endpoint is requested, evaluated in UTC. Defaults to every minute, which is also the shortest supported gap. Optional. Minimum length: `1`. Maximum length: `128`. - **`check_retry_seconds`** `integer | null` Seconds to wait before one confirming request settles a failed run. Send `null` to record the first result as it stands. Optional. ## Response Check updated ```ts { message: string; data: Check; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Changes take effect on the next run; a run already in flight finishes under the old configuration. - A changed `schedule_cron` takes effect from the next run onward. - At least one field must be provided. - Any field not listed here is rejected, including `source_id`, which cannot be changed after create. Create a new check to record into a different source. - Clearing `request_body` is required before changing `method` from `post` to `get`; a check cannot keep a body it would never send. - `headers` is a patch, not a replacement, because the values are write-only and never returned. A name mapped to a string adds or replaces that header, a name mapped to `null` removes it, and a name you do not mention keeps its stored value. Omit the field to leave every header alone, or send `null` in place of the object to remove all of them. - `headers` names are matched case-insensitively, so patching `authorization` replaces a stored `Authorization` rather than adding a second header. The spelling you send is the one stored and sent. - `headers` accepts at most 20 entries, counted after the patch is applied. - `schedule_cron` must be a valid cron expression, evaluated in UTC. Changing it restarts the missed-slot count from the edit, since slots before it belonged to a different schedule. - Send `check_retry_seconds` as `null` to stop confirming failures and record the first result as it stands. - Changing `collection_slug` starts a new series. Observations already written stay where they are, so a chart over the old collection stops at the edit. # Delete Check ## Endpoint Delete a check. ```http DELETE /v1/projects/:project_id/checks/:check_id ``` **Scope:** `checks:delete` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`check_id`** `string` -- **Required** Unique identifier of the check. ## Response Check deleted ```ts { message: string; data: null; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Observations the check already wrote are not deleted. They belong to the source and stay queryable, so a chart of past uptime keeps working. # Pause Check ## Endpoint Pause a check so it stops running. ```http POST /v1/projects/:project_id/checks/:check_id/pause ``` **Scope:** `checks:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`check_id`** `string` -- **Required** Unique identifier of the check. ## Response Check paused ```ts { message: string; data: Check; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Only an active check can be paused. Pausing an already-paused check succeeds and changes nothing. - A pause is a gap in the uptime record rather than downtime. Nothing is recorded for the minutes it covers. # Resume Check ## Endpoint Resume a paused check. ```http POST /v1/projects/:project_id/checks/:check_id/resume ``` **Scope:** `checks:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`check_id`** `string` -- **Required** Unique identifier of the check. ## Response Check resumed ```ts { message: string; data: Check; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Resumes a check you paused. The failure count starts again from zero. - A check the system stopped while the team was not in good standing is not resumable here and returns 400. It starts again on its own once the team is back in good standing. # Test Check ## Endpoint Request the endpoint once without recording anything. ```http POST /v1/projects/:project_id/checks/:check_id/test ``` **Scope:** `checks:write` ## Path Parameters - **`project_id`** `string` -- **Required** Unique identifier of the project. - **`check_id`** `string` -- **Required** Unique identifier of the check. ## Response ```ts { message: string; data: CheckTestResult; status: 200; error: null; pagination: null; endpoint: string; } ``` ## Comments - Nothing is recorded and no health field or schedule is changed, so this is safe to run against a live check. The result does not appear in the uptime history. - The response reports the HTTP status, how long the request took, and the first 2 KB of the body so you can confirm you reached the endpoint you meant to. - There is no confirming retry here, unlike a scheduled run: a test reports what happened rather than settling a verdict. ## Logs # Log Model ## Fields - **`object`** `"log"` - **`action`** `string` What happened, as a short code such as `sign_in` or `user.mfa_reset`. - **`success`** `boolean` Whether the attempted action succeeded. Failed attempts, like a bad sign-in, are recorded too. - **`message`** `string | null` - **`team_id`** `string | null` Null on sign-in entries that are not tied to a team. - **`actor_id`** `string | null` Who acted: the user id, or the API key id when a key acted. See `actor_type`. Null when Tailglow acted automatically. - **`actor_type`** `string | null` One of `AUTH_SUBJECTS`. Whether a user or an API key acted. - **`actor_name`** `string | null` Display name of the actor as it was WHEN THE ACTION HAPPENED, so a renamed or deleted actor still reads correctly. Reads `Tailglow Admin` on entries where a Tailglow operator acted, and `Tailglow` on entries Tailglow wrote automatically. - **`actor_context`** `string | null` `app` for a member or API key, `admin` when a Tailglow operator acted on this team, and `system` when Tailglow acted automatically, for example when a payment arrived. Decide who acted from this field, not from `actor_name`, which members choose themselves. - **`actor_role_id`** `string | null` Role the actor held at the time. Null on entries a customer reads about an operator. - **`actor_session_id`** `string | null` Session the action belongs to, so one actor's run of changes can be grouped. - **`resource_type`** `string | null` What the entry is about: the user who signed in, or the row that changed. - **`resource_id`** `string | null` Identifier of the resource named by `resource_type`. - **`ip_address`** `string | null` - **`device`** `string | null` Readable device summary parsed from the user agent, for example `Chrome 126 on Mac OS`. - **`user_agent`** `string | null` - **`created_at`** [`ISODateString`](/api/logs#iso-date-string) - **`type`** [`LogType`](/api/logs#log-type) Which kind of entry this is: `auth` for sign-in activity, `audit` for changes to resources, `billing` for changes to the team's billing. - **`details`** [`AuthLogDetails`](/api/logs#auth-details-model) | [`AuditLogDetails`](/api/logs#audit-details-model) | [`BillingLogDetails`](/api/logs#billing-details-model) Extra context whose shape follows `type`: `AuthLogDetails` for sign-ins, `AuditLogDetails` for changes, `BillingLogDetails` for billing. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### LogType `"auth" | "admin_auth" | "audit" | "billing"` ### BillingPlan `"pro_v1" | "enterprise_v1"` # Auth Log Details Model ## Fields - **`email`** `string` The email address the sign-in was attempted with. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Audit Log Details Model ## Fields - **`changed_fields`** `string[]` The fields the request changed, sorted and de-duplicated. - **`endpoint`** `string | null` The API endpoint the change came through. - **`request_client`** `string | null` Which surface made the request: the API directly, the dashboard, the admin portal, or the AI assistant. - **`client_version`** `string | null` Version of the client that made the request, when it reported one. - **`ai_chat_id`** `string | null` Set when the AI assistant made the change; identifies the chat it happened in. - **`[key: string]`** `unknown` Any additional key recorded with the entry. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. # Billing Log Details Model ## Fields - **`amount_cents`** `number` Amount in cents, such as an invoice total or a failed payment. - **`stripe_invoice_id`** `string` Stripe's id for the invoice, as shown on the invoice list. - **`period_start_at`** [`ISODateString`](/api/logs#iso-date-string) First moment of the billing month the entry is about. - **`plan_from`** [`BillingPlan`](/api/logs#billing-plan) - **`plan_to`** [`BillingPlan`](/api/logs#billing-plan) - **`payment_method_brand`** `string` - **`payment_method_last4`** `string` - **`discount_id`** `string` - **`discount_percent`** `number` - **`discount_amount_cents`** `number` - **`line_item_type`** `string` The invoice line a discount applies to, such as `compute` or `storage`. - **`available_ai_tokens_before`** `number` Tailglow AI tokens available to the team before the entry's change. - **`available_ai_tokens_after`** `number` Tailglow AI tokens available to the team after the entry's change. - **`trial_ends_at`** [`ISODateString`](/api/logs#iso-date-string) When the free trial ends after the entry's change. - **`days`** `number` Days the free trial was extended by. - **`server_hours`** `number` Server-hours of credit the entry added. - **`has_payment_method`** `boolean` For a trial that ended: whether a payment method was on file, so its servers kept running. - **`invoice_id`** `string` For a delinquency change: the invoice that caused it, or whose payment cleared it. ## Referenced Types ### ISODateString `ISODateString` An ISO 8601 date-time string returned at the JSON API boundary. ### BillingPlan `"pro_v1" | "enterprise_v1"` # List Logs ## Endpoint Retrieve activity logs available to the current authorization. ```http GET /v1/logs ``` ## Query Parameters - **`order_by`** `string` Field used to order the logs. Optional. Defaults to `"created_at"`. Allowed values: `"created_at"`. - **`start_at`** [`ISODateString`](/api/logs#iso-date-string) Earliest log date and time to return. Optional. - **`end_at`** [`ISODateString`](/api/logs#iso-date-string) Latest log date and time to return. Optional. - **`team_id`** `string` Filter by team ID. Optional. - **`user_id`** `string` Filter by user ID. Optional. - **`type`** [`LogType`](/api/logs#log-type) Filter by log type. Optional. - **`limit`** `number` Maximum number of items to return. Optional. Defaults to `25`. Minimum: `1`. Maximum: `200`. - **`after`** `string` Cursor from `pagination.next_cursor` of a previous response. Returns the resources after that page. Optional. - **`before`** `string` Cursor from `pagination.prev_cursor` of a previous response. Returns the resources before that page. Optional. - **`sort`** `string` Sort direction for the result set. Optional. Defaults to `"desc"`. Allowed values: `"asc"`, `"desc"`. ## Response ```ts { message: string; data: Log[]; status: 200; error: null; pagination: Pagination; endpoint: string; } ``` ## Comments - You can retrieve your own authentication logs without `logs:read`. Billing logs require `billing:read`; all other log reads require `logs:read`. - Without `type`, the list includes every type you can read. `admin_auth` logs exist only on Tailglow's own admin team. - `after` and `before` are mutually exclusive. --- # User Guides # Concepts ## Introduction Tailglow separates the ingest boundary from the data boundary. The core concepts are: - **Sources**: Authentication and ingest configuration for a project. - **Collections**: Logical streams of records within a source. Collections own schema versions, files, and raw records. - **Views**: Transformed data derived from a collection or produced by joining views. - **Metrics**: Aggregated measurements and charts built from views. ## Sources and collections A source is the place you configure ingest keys. Its **Ingest** tab displays the project's default endpoint after one has been provisioned and any available team ingest domains. If neither exists, the tab says **No ingest endpoints configured**. The project and team domains own those routing endpoints; the ingest key selects the source. A new source starts with no collections. Tailglow chooses one collection for each ingest request. A valid `?collection=charges` query parameter picks it, and a request without one goes to the source's `catchall` collection. Fields inside the records, including `type`, never choose the collection. Every record in a JSON array or JSONL request goes to that collection. A source supports up to 100 collections. New collection names route to `catchall` after the source reaches that guardrail. A burst of simultaneous requests can briefly create more than 100 collections. ## Records Records are the events you send to an ingest endpoint. Tailglow accepts JSON, JSONL, CSV, TSV, PSV, SSV, and plain text. Raw collection records can be sampled as soon as they arrive, whatever the state of their schema version. JSON records need no fixed wrapper. Tailglow normalizes tabular and text input into JSON records, renames unsafe property keys, adds delivery metadata, and replaces embedded image data with artifact references. ## Schema versions Every record that reaches a collection is read for its shape: the paths it carries and the type at each path, down to the collection's depth rule. The first time a shape is seen, the collection registers a schema version for it and stamps every file holding that shape with the version. A version's number is permanent. Its canonical shape can still refine in place: a path first seen blank learns its type, and the paths a wider record carries are added once that shape has come back or arrived in bulk, so a single stray key never changes a version. A rule change can merge two versions into one, and the merged version's files move to the survivor. A record that is not a JSON object, or an empty one, has no shape to register: it is stored and kept, but it never joins a schema version and no view reads it. A version is in one of three states: - **Candidate**: the shape has been seen once. Its records are stored and served immediately by any view mapping that already fits them, but no mapping is written for it yet. - **Settled**: the shape was seen again after the collection's recurrence gap, arrived in one batch with at least the bulk row count, or a person settled it. Only settled versions are offered to views for authoring. - **Stale**: a candidate that was not seen again within the stale window. Its rows stay stored but unclassified. A stale shape that returns settles. Each view decides separately whether an existing TGL script can read a version. Changes under fields a script never reads reuse the script at once. A change from `name: string` to `name: {first, last}` needs a new decision for a view that reads the name, while a view that only reads `run_id` continues. Nulls and empty values never make a new version: a version first seen with `user_id: null` refines in place once strings arrive. Absent keys follow the collection's optional keys switch. On automatic, a record whose keys are a subset of a version's keys joins that version. On manual, absence is structural, and a record missing a key is a distinct version. A mapping written while the path had no values is flagged on the view with the refined paths, and re-authoring it clears the notice. See [Schema settings](/guides/sources#schema-settings) for the rules and settings a collection carries. ## Views Views reshape data with [TGL](/guides/tgl). In the **Views** page, click **New View** and choose one of the available creation modes: - **Collection**: Choose a **Source Collection**, optionally define an output schema and a generation hint, then click **Create View**. Tailglow generates transforms for the collection's settled schema versions. - **View**: This is a join builder, not a simple parent-derived view. Choose a base view, add one or more lookup views, and select the fields that join them. The view's **Overview** shows how source versions flow through scripts into the output schema and linked metrics, drains, or views. Narrow panels use a connected vertical layout. More than two scripts become a counted group; open it for the script list, or open a source group to choose an individual version. Failed and processing scripts remain visible in the group's status. Counts describe the loaded data; **Version coverage** lets you load more versions. The saved **Generation hint** is shown directly below the diagram on desktop and mobile. Change it in the view's Settings. If none is saved, the diagram says **No generation hint added.** Users who can edit the view can click the **+** beside it to open Settings and add a hint. You can inspect transformed data on a view's **Records** tab. ## Metrics Metrics aggregate data from a view. Choose a timestamp field, optional grouping, filters, and value or unique-count fields. Use metrics to chart counts, numeric values, and grouped trends, then attach monitors when you need alerts. Events with overridden timestamps that land far in the past are held for review rather than charted silently; [Late data](/guides/metrics#late-data) explains the window. ## Summary Sources authenticate and configure ingest. Collections own the raw data and its schema versions. Views transform or join collection data one schema version at a time. Metrics aggregate view output for analysis and monitoring. # Authentication Tailglow supports email sign-in and passwords. Each browser keeps its own session, which you can review or revoke from your profile. ## Email sign-in Enter your email address and Tailglow emails you a sign-in link and an 8-character code. This passwordless option is the default for new accounts. - The link and the code only work in the browser where you asked for them. If you open the email on another device, such as your phone, type the code into the browser where you started. - Both expire after 10 minutes and work once. Requesting a new email replaces the previous link and code. - If you open the link in another tab of the same browser, the tab where you started shows that you are signed in, and you can close it. - You can request up to 5 sign-in emails in 15 minutes, and up to 20 in a day. ## Password Passwords are optional and must be at least 16 characters long. Use a password manager to generate and store yours. You must enable multi-factor authentication (MFA) before adding a password. To change your password, open your profile's **Security** tab and provide a valid MFA code. ## Browser sessions Signing in creates a separate session for that browser. Signing in somewhere new does not sign out your other browsers, and closing a browser does not end its session. Open **Profile** > **Security**, then find **Devices** to review active sessions and sign out a specific browser. You can have up to 25 active browser sessions. If you exceed that limit, Tailglow signs out the least recently active session. Clearing Tailglow site data signs out that browser locally. The session may remain listed in the **Devices** section until you revoke it. ## Multi-factor authentication Tailglow uses time-based one-time passwords (TOTP) for MFA. You will need an authenticator app that can scan a QR code and generate six-digit codes. ### Set up MFA 1. Open **Profile** and select **Security**. 2. In **Multi-factor Authentication**, open the actions menu and select **Enable MFA**. 3. Scan the QR code with your authenticator app. 4. Click **Confirm MFA**. 5. Enter the six-digit code from your authenticator app and click **Submit**. 6. Save the backup codes, then click **I've copied my backup codes**. Backup codes are shown only once. Store them somewhere secure, such as a password manager. Each code can be used once, and Tailglow emails you when a backup code is used to sign in. You can regenerate backup codes from **Profile** > **Security**. Regenerating them requires a valid MFA code and invalidates the previous set. ### Disable MFA You can disable MFA from **Profile** > **Security** with an authenticator code or backup code. If password sign-in is enabled, disabling MFA also disables password sign-in. You can continue using email sign-in. Disabling MFA also signs you out of every browser, including the one you are using. ### Team-required MFA Team owners can require MFA for all members. If a team requires MFA, Tailglow prompts members to set it up before they can access that team. MFA verification applies to one browser session at a time. ## Sign out and security activity Signing out normally ends only the current browser session. From **Profile** > **Security** you can: - Use the **Devices** section to sign out another browser or every browser. - Review authentication history, including the action, time, device, and IP address. ## Roles and permissions Your role in each team determines which features and actions you can access. Team owners can manage roles from **Team Settings** > **Roles**. See [Permissions](/guides/permissions) for how access levels and role presets work. Your selected team is specific to each browser, so another signed-in browser can remain on a different team. # Servers Servers receive and process data for a project. A source's **Ingest** tab shows the project's endpoint when one is available. ## Trial and paid servers The free trial starts one server in your team's first project and grants the team 72 server-hours of compute credit. A payment method is required to add more servers. Credits are shared across projects: two running servers use the same 72-hour balance in 36 hours. Manage Servers shows the monthly cost before you confirm a change. The three days start when the trial server first comes up. Without a payment method, the initial server pauses after those three days. Billable usage ends at the trial deadline, including when cleanup runs late. With a card, servers keep running and use any remaining credits before paid usage begins. Unused credits do not expire. Tailglow staff can extend a trial, which adds the matching server-hours and brings back a paused trial server. See [Billing](/guides/billing#free-server-trial) for month boundaries, resume rules, and the AI and storage allowances every team has. ## Manage server count 1. Open **Servers** in the project sidebar. 2. Click **Manage Servers**. 3. Set the desired server count. 4. Review the consequence and confirm it. Scaling up uses **Add server** or **Add servers** and starts provisioning after you confirm. Scaling down, including scaling to zero, requires a hold-to-confirm action. Scaling to zero stops ingestion, so events sent while no server is running are not stored or recoverable. ### Scaling during a platform update Tailglow updates every server to new platform versions one project at a time, reserving the capacity each update needs before it starts. While an update is in progress, a change to the server count is queued instead of applied: Manage Servers confirms the request, the Servers page shows the queued count, and the change starts automatically when the update finishes. Adding servers to a project that has not finished moving to the current platform version is queued the same way; removing servers is not. To cancel a queued change, select **Cancel queued change** on the Servers page, or set the count back to the number of servers the project runs. A newer request replaces an older one. A project with no servers yet is not held back; its first server starts right away. A paused trial server that resumes after you add a payment method also waits for the update to finish. ## Statuses A new server starts as **provisioning** and becomes **active** after setup. Scaling down changes it to **terminating** while Tailglow drains and removes it. Scaling up later creates a new server. ## Server analytics Server detail pages show resource usage for the selected server. **Project Ingest Pipeline** shows pending records, throughput, and errors across every server in the project, including temporary deployment servers. You can select a time range or brush across a chart to focus on a smaller window. The current queue counts valid spooled records awaiting write, including records being processed. It refreshes independently of the selected chart window. When queues change during the observation, Tailglow counts the durable records it can confirm and marks the pending count with **≈**. If a current server's queue cannot be read or a concurrent write's outcome is unknown, the queue is unavailable instead of showing an uncertain total. A stale reading means the last complete or estimated snapshot is too old to confirm the current queue. The single-line summary shows processed records from the last completed minute alongside the current pending count. The error button appears when the selected chart range contains recorded errors; errors count rejected requests and dropped frames. The summary shows a skeleton while its first request loads and keeps existing readings visible during refreshes. Delayed or unavailable measurements are labeled separately, so an available queue or processed count remains visible. A retry control appears after a failed refresh or when neither current reading is available. Historical pending values are average queue occupancy, so they can contain fractions. Older history recorded in request frames has gaps in the pending-record series. Throughput is counted in the minute each spool batch completes. Delayed sampling or shutdown uploads preserve that minute, even when resource measurements for it are unavailable. This does not reconstruct missing historical measurements. Missing measurements appear as gaps, including when a server's contribution cannot be read. Pending, throughput, and errors can be available independently. Live polling pauses in background tabs. The analytics API supports windows up to 48 hours with minute buckets or 30 days with hour buckets. Future end times are limited to the current time. Measured values in the current chart bucket show **(so far)** until the bucket ends. For example, at 9:35 an hourly bucket starting at 9:00 is still in progress. # Ingest Key ## Getting Your Key Your ingest key is located in your source settings. Select a project, open **Settings**, choose the **Sources** tab, and click the edit button for a source. In the source drawer, select the **Ingest** tab. The **Ingest Keys** section lets you view and manage the source's keys. Each source can have multiple ingest keys. ## Prefix Your ingest key always begins with the prefix `tg_ingest_`. ## Usage ### Query Parameter (Recommended) The simplest way to authenticate is by including your ingest key as a `key` query parameter in the URL. This works across all platforms -- browsers, backends, and mobile apps. ```bash curl -X POST "https://us11.ingest.tailglow.io/prj_xxx?key=tg_ingest_123" \ -H "Content-Type: text/plain" \ -d '{"records": []}' # Your records here ``` Replace the URL with your project's ingest endpoint, found in your source settings. Even though the payload is JSON, setting `Content-Type: text/plain` is safe because the ingest server auto-detects the format. For browser-based clients, this is especially important: `text/plain` is a [simple content type](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), so browsers skip the CORS preflight OPTIONS request entirely, sending one request instead of two. This method also works with `navigator.sendBeacon`, which does not support custom headers: ```javascript navigator.sendBeacon( "https://us11.ingest.tailglow.io/prj_xxx?key=tg_ingest_123", JSON.stringify({ event: "page_view", path: "/home" }) ); ``` ### Authorization Header You can also include your ingest key in the `Authorization` header using the `Bearer` or `Key` prefix: ```bash curl -X POST https://us11.ingest.tailglow.io/prj_xxx \ -H "Content-Type: application/json" \ -H "Authorization: Key tg_ingest_123" \ -d '{"records": []}' # Your records here ``` Note that from browsers, using a custom `Authorization` header with `Content-Type: application/json` will trigger a CORS preflight request, doubling the number of requests. ## Security Your ingest key has write-only access to your ingest server. While it's important to keep this key private, it's acceptable to include it in frontend code if you're using the ingest server for frontend metrics and analytics. ## Managing Your Keys Each source can have multiple ingest keys. You can create new keys and delete old ones as needed from your source settings. When you need to rotate a key, simply create a new one, update your services to use it, and then delete the old key. ## Key and Team Status An ingest key works only when its team status also permits ingestion: - **Active team**: An active key on an active team works normally. - **Delinquent team**: For a non-Enterprise team, an uncollectible or later-unpaid invoice can make the team delinquent. Active ingest keys are then disabled until the payment issue is resolved. A single failed payment attempt does not by itself apply this state. - **Restricted team**: The team is read-only and ingestion is disabled until the restriction is resolved. - **Blocked team**: The team cannot be accessed and ingestion is disabled. Contact support to resolve this. An ingest request is accepted only when both the key and its team are active. If the team becomes `delinquent`, `restricted`, or `blocked`, the key stops accepting data. Update your payment information or contact support as appropriate to restore access. # Sending Data Send records to the full ingest endpoint copied from a source's **Ingest** tab: ```text https://{region}.ingest.tailglow.io/{project_id} ``` Include an ingest key as the endpoint requires. Do not substitute a generic ingest hostname for your project endpoint. ## Formats Tailglow accepts JSON objects or arrays, JSONL, CSV, TSV, PSV, SSV, and plain text. JSON needs no wrapper. Input is normalized before it is stored, so tabular and text payloads become records and dangerous keys or embedded images may be transformed. ```bash curl -X POST "https://{region}.ingest.tailglow.io/{project_id}?key={ingest_key}" \ -H "Content-Type: text/plain" \ -d '{"method":"POST","path":"/v1/users","status":200}' ``` ## Response and delivery A successful request returns `202 Accepted`. Tailglow then processes the records in the background. Wait for that response, use the SDK queue, or otherwise record delivery failures. You do not need to wait for downstream processing, but a request can be lost if the caller exits before delivery completes. The maximum request body is 20 MiB (20,971,520 bytes). A larger body is rejected with `413 Payload Too Large`; split it into smaller requests. ## Errors and retries A `202 Accepted` response means the data is durably accepted: it is queued on your server and retried internally until it lands. Accepted data is never dropped. Any error response means nothing was recorded from that request. The data is still yours to resend. Retry on any `5xx` response and on network failures such as a dropped connection; the official SDKs do this automatically with backoff. A `4xx` response means the request itself must change, so fix the key, payload, or size before resending. Refused requests appear on the server page's Ingest Pipeline chart, grouped by reason. The error drawer marks each group as retryable or needing a change to the request. The full reason list is on the [Enums](/api/enums#ingest-pipeline-error-reasons) page. # JavaScript SDK Tailglow's JavaScript SDK reports **events**, **errors**, and **logs** to your project from anywhere JavaScript runs: a browser app, a Node or Bun backend, an edge function, Electron, or React Native. A shared core handles queueing, batching, retry attempts, redaction, and sampling. A thin per-runtime package adds the auto-collection and lifecycle wiring that platform needs. The mental model is small: you `track()` events and `identify()` users, and the SDK routes every record into one of a few **collections** (`events`, `errors`, `logs`), stamping each with a `type` that says what it is. Batching, retries, redaction, and delivery attempts are handled for you on every runtime; browser and React Native apps also collect page views, errors, and more automatically. New here? The **[Quickstart](/guides/quickstart)** gets a web app reporting in about two minutes. This page is the full reference. ## Runtimes | Runtime | Package | Automatic out of the box | | ------------------------------------ | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Browser** (web apps, static sites) | `@tailglow/browser` | Page views, tagged-section activity, declarative and outbound clicks, uncaught errors, performance signals, device snapshot, plus best-effort exit flush via `sendBeacon` | | **Backend** (Node, Bun, edge) | `@tailglow/core` | Nothing automatic: you `track()` explicitly and flush before the process or request ends | | **Electron** | renderer uses `@tailglow/browser`, main uses `@tailglow/core` | Renderer behaves like a browser after allowing `file://`; main behaves like a backend | | **React Native / Expo** | `@tailglow/react-native` | JS errors and supported rejection hooks, console, and device once modules are injected; screen views after `attachNavigation()`; best-effort persistence and flush with AppState and storage | Every package exposes the same core API: `track`, `captureException`, `identify`, `setContext`, `flush`, and friends. What changes per runtime is which events are collected for you and how exit or shutdown flushing is wired. ESM only, no CJS bundle. Runtime floors: Node `>=22`, Bun any, React Native `>=0.74`, evergreen browsers (Chrome and Firefox 90+, Safari 14+, Edge 90+), and recent edge runtimes. ## Installation ```bash bun add @tailglow/browser # or npm install @tailglow/browser ``` ## Drop-in ` ``` Optionally, add a pre-load stub before the loader so calls made before the SDK finishes loading are queued and replayed on init: ```html ``` Override the default collection routing via additional data-attrs (rare; defaults are `events` / `errors` / `logs`): ```html ``` Set all three to the same slug to merge everything into one timeline collection. ### Declarative event tracking `data-tglow-event=""` fires `tg.track("", props)` on click and routes to the configured `events` collection with `type: ""`. Other `data-tglow-*` attributes become props on the record. ```html See pricing ``` ## Initializing The full browser walkthrough is in the [Quickstart](/guides/quickstart). Below is the minimal init per runtime. ### Browser ```javascript import { Tailglow } from "@tailglow/browser"; const tg = new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key" }); // Auto-collection starts immediately: page views, section visibility, // errors, performance signals, and device info. tg.track("signup", { plan: "pro" }); tg.identify("user_123"); ``` ### Node / Bun (via `@tailglow/core`) ```javascript import { TailglowCore } from "@tailglow/core"; const tg = new TailglowCore({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key" }); tg.track("job_completed", { job_id: "abc" }); process.on("SIGTERM", async () => { await tg.flush(); await tg.destroy(); }); ``` ### React Native (`@tailglow/react-native`) ```javascript // App.tsx import AsyncStorage from "@react-native-async-storage/async-storage"; import { NavigationContainer, useNavigationContainerRef } from "@react-navigation/native"; import { createAsyncStorageAdapter, Tailglow } from "@tailglow/react-native"; import { useEffect } from "react"; import { AppState, Dimensions, NativeModules, Platform } from "react-native"; const tg = new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key", appState: AppState, platform: Platform, dimensions: Dimensions.get("window"), nativeConstants: NativeModules.PlatformConstants, storageAdapter: createAsyncStorageAdapter(AsyncStorage) }); export default function App() { const navigationRef = useNavigationContainerRef(); useEffect(() => { tg.attachNavigation(navigationRef); // → automatic page_view on every screen change }, []); return {/* screens */}; } ``` With the modules wired above, JS errors, console activity, a one-time `device` record, and persist-and-flush on `AppState` background are automatic. Unhandled rejection capture is best-effort because it depends on the rejection hooks exposed by the current Hermes, JSC, and bundler combination. The AsyncStorage adapter restores up to the newest 1,000 persisted records after a cold start, but duplicate delivery is possible if a record was sent before its persisted snapshot was cleared. The one wire-up the SDK cannot infer is your navigation library, hence `attachNavigation(navigationRef)`: React Native has no universal navigation primitive. Expo Router uses React Navigation underneath, so the same call covers both (pass the ref from `useNavigationContainerRef()`). This package captures JS-layer behavior only. Native crashes (iOS Swift, Android Kotlin) are out of scope, and even fatal JS crashes are best-effort since the runtime may die before the AsyncStorage write finishes. Screen-view records land in the `events` collection as `type: "page_view"` like the browser, but with `from_screen` / `to_screen` / `params` instead of `from_path` / `to_path` / `url`; query both platforms together and expect both field sets. ## Identity model Browser identity is **ephemeral by default**. The SDK stores no `device_id`, `user_id`, or session identifier in cookies or browser storage. A `user_id` is stable across loads only when your app calls `identify()` again from its own authenticated session. | Layer | Source | | ------------ | -------------------------------------------------------------------------------------------------- | | `session_id` | In-memory, regenerated after `sessionTimeout` of inactivity | | `user_id` | `identify(user_id)`. Same-session records can be backfilled until their request body is serialized | | `device_id` | `setDeviceId(id)`. Opt-in, customer-supplied (mobile/desktop) | Sticky sampling resolves in cascade: `user_id` → `device_id` → `session_id`. Without an identifier above session, sampling resets per session (the privacy-preserving default). ## Public API ### Collections model The SDK manages three collections (configurable; defaults shown): | Collection | What lands here | | ---------- | --------------------------------------------------------------------------------------------------------------- | | `events` | Every `track()` call and every auto-collected event (page views, clicks, vitals, device snapshots, navigation). | | `errors` | `captureException`, `captureMessage`, and `console.error`. | | `logs` | Non-error console levels selected by `autoConsole`. By default only `console.warn` emits here. | Records carry a `type` field that discriminates within the collection (page_view, click, vital, signup, purchase, or whatever you pass to `track()`). The collection is the routing destination; the `type` is the event kind. ```javascript tg.track("signup", { plan: "pro" }); // → POST ?collection=events with { type: "signup", plan: "pro", session_id: ... } tg.track("purchase", { amount: 99 }); // → POST ?collection=events with { type: "purchase", amount: 99, session_id: ... } ``` Override per call when you need a separate collection (rare, but useful for separating high-volume telemetry or audit records from the default event schema). The override uses the **object form** of `track()`: ```javascript tg.track({ type: "audit_event", collection: "audit_log", actor: "user_42" }); // → POST ?collection=audit_log with { type: "audit_event", actor: "user_42", ... } ``` The string form `track(name, props)` is the 99% case; the object form is reserved for the per-call routing override. There's no third positional argument; pass everything (type, collection, props) in one object. Configure the destinations at construction time: ```javascript new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key", collections: { events: "events", // default; override to namespace per app on a shared source errors: "errors", logs: "logs" } }); ``` Set all three to the same slug to merge everything into one timeline collection: ```javascript new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key", collections: { events: "timeline", errors: "timeline", logs: "timeline" } }); ``` ### Sending events `track(name, props?)` (string form) The `name` parameter is the **event type**, stamped as the `type` field on the record. Routes to the configured `collections.events` destination (default: `events`). `track({ type, collection?, ...props })` (object form) Use this when you need to route a single record to a different collection. `type` is required; `collection` overrides the default routing; everything else becomes record props. ```javascript tg.track("signup", { plan: "pro" }); tg.track("purchase", { amount: 99, currency: "USD" }); ``` Customer-supplied `props.type` wins on collision: pass `type: "..."` explicitly in props to override the SDK's stamp. ### Errors and exceptions `captureException(err, props?)` Capture an exception. Routes to the configured `collections.errors` destination (default: `errors`). The SDK parses the stack into structured frames, computes a stable fingerprint for the client burst limiter and your own filtering, snapshots the breadcrumb buffer, and stamps mechanism metadata. The record's top-level `type` field is the JS error class name (e.g. `"TypeError"`); within errors, `type` discriminates error kinds the same way it discriminates event kinds within events. ```javascript try { riskyOperation(); } catch (err) { tg.captureException(err, { user_step: "checkout" }); } ``` `level` defaults to `"error"`. Override via props: ```javascript tg.captureException(err, { level: "fatal", user_step: "checkout" }); ``` `fingerprint` is a stable string included in the record and used by the client burst limiter. The SDK computes it from the frame signature; pass an explicit string in props to control which errors share a burst budget or to provide your own downstream grouping key: ```javascript tg.captureException(err, { fingerprint: "payment-flow" }); ``` `captureMessage(message, props?)` Capture a message-style event (no Error to attach). Same destination as `captureException` (the configured `errors` collection); use this for assertion failures, recoverable warnings, or business invariants. Default `level` is `"info"`. The record's `type` is `"Message"`. ```javascript tg.captureMessage("payment validator returned null", { level: "warning" }); ``` `addBreadcrumb(entry)` Push a breadcrumb manually. Auto-collectors do this for you (console activity, page and screen navigations, section and outbound clicks), but you can leave your own context markers. ```javascript tg.addBreadcrumb({ category: "navigation", message: "/home → /checkout", timestamp: Date.now() }); ``` #### Auto-captured errors and rejections When `autoErrors` is enabled (default), the browser SDK installs `window.addEventListener("error")` and `unhandledrejection` listeners that route through `captureException` automatically. Same record shape as a manual call; `mechanism.type` differs (`"uncaught"` / `"unhandled_rejection"` vs. `"manual"`). #### Auto-captured console activity When `autoConsole` uses its default value of `["error", "warn"]`, all supported `console.*` calls are wrapped for breadcrumbs, but only warnings and errors emit records: | Console method | Default effect | Record destination | `type` | | --------------------------- | ------------------------------------------------ | ------------------- | ---------------- | | `console.log` | breadcrumb only | none | n/a | | `console.warn` | record + breadcrumb | `logs` collection | `"warn"` | | `console.info` | breadcrumb only | none | n/a | | `console.debug` | breadcrumb only | none | n/a | | `console.error(err: Error)` | `captureException` + breadcrumb | `errors` collection | error class name | | `console.error(string)` | `captureMessage` (level: `"error"`) + breadcrumb | `errors` collection | `"Message"` | The wrapper preserves the original console output: DevTools still shows everything as before. The only loss is DevTools' "source" column shows the wrapper's file/line instead of the actual caller. This is the standard tradeoff every error tracker makes. When a non-error level is included in `autoConsole`, its record follows these argument-shape rules: ```javascript console.log("user clicked save"); // → { type: "log", message: "user clicked save" } console.log({ user_id: 42, action: "save" }); // → { type: "log", user_id: 42, action: "save", message: "{...}" } (object flattened) console.log("user clicked", { id: 42, name: "Alice" }); // → { type: "log", message: "user clicked {...}", id: 42, name: "Alice" } ``` #### Burst protection To catch runaway loops (the same error firing thousands of times per second), the SDK rate-limits per fingerprint. After 10 events of the same fingerprint within 1 second, the next event triggers a 2-minute cooldown and is dropped. The first event emitted after cooldown carries `burst_suppressed: N` only when additional events were dropped during that cooldown. `N` counts those additional cooldown drops and does not include the event that triggered cooldown. Configurable via: ```javascript new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key", errorBurst: { threshold: 10, window_ms: 1000, cooldown_ms: 120_000 } }); ``` The fingerprint counter map is LRU-evicted at 1000 entries to bound memory in long-running sessions. Underneath the per-fingerprint limiter is a global token-bucket limiter that caps the total record rate across every type (`track()`, auto-collectors, errors, logs). It protects the client from a runaway emit loop, but it does not guarantee that the ingest server will accept every request. Invalid credentials, malformed or oversized payloads, unavailable capacity, and other server failures can still reject a request. The limiter runs after sticky sampling and before stamping, redaction, size checks, `onBeforeSend`, and queueing. The bucket holds 200 tokens and refills 120 per minute by default; every admitted record spends one token, and when the bucket empties records are dropped. Drops surface as a collapsed `tglow_rate_limited` self-event carrying `limited_count` (records dropped since the last notice) and `window_ms`, emitted at most once per 60 seconds. Tune it with the `rateLimit` option (`burst` must be a finite number at least 1, `perMinute` a finite number at least 0, where `perMinute: 0` means drain-only with no refill), or pass `rateLimit: false` to disable it. Any out-of-range value (including `burst: 0`) falls back to that field's default and logs one `[tglow]` warning, so a bad config can never silently disable the brake or drop everything. #### `errors` collection record shape ```json { "type": "TypeError", "message": "Cannot read 'x' of null", "stack_raw": "TypeError: Cannot...", "frames": [ { "filename": "https://cdn.example.com/app.min.js", "function": "calculateTotal", "lineno": 1, "colno": 48201, "in_app": true } ], "fingerprint": "9c3f8a1b", "mechanism": { "type": "uncaught", "handled": false }, "level": "error", "cause": { "type": "Error", "message": "...", "frames": [] }, "breadcrumbs": [ { "category": "console", "level": "log", "message": "...", "timestamp": 1700000000000 } ], "sdk": { "name": "tailglow.browser", "version": "x.y.z" } } ``` #### `logs` collection record shape ```json { "type": "log", "message": "user clicked save", "session_id": "sess_...", "event_id": "...", "event_time": "...", "sdk": { "name": "tailglow.browser", "version": "x.y.z" } } ``` ### Identity & context `identify(user_id)`: set the user ID. Pre-identify records from the same session are backfilled while they remain buffered or in an in-flight SDK batch that has not yet been serialized. A request body already serialized for `fetch` cannot be changed and remains anonymous. `unidentify()`: clear the current user ID. Equivalent to `identify("")` but explicit. `setDeviceId(id)`: set a customer-supplied device ID for subsequent records. The SDK does not persist it; mobile or desktop apps are responsible for supplying the same stable identifier again on a later launch. Browsers should normally leave this unset. `rotateSession()`: force a new session ID at an explicit boundary (workflow finished, end-of-flow). Returns the new ID. `setContext(ctx)`: merge sticky context. Every key here is stamped on every subsequent record (only if the record doesn't already have that key). Values must be JSON-serializable (functions and `undefined` are dropped). The context bag is capped at 64 top-level keys and 8192 serialized bytes. A non-object value or array is ignored without a warning. An object patch that cannot be serialized, resolves to a non-object through `toJSON`, or would exceed either cap is rejected as a whole, leaving the existing bag unchanged, and the SDK logs one `[tglow]` warning for that violation kind. Common conventions are `release`, `environment`, `dist`, `region`, `plan`, but the SDK doesn't reserve any of them; they're just sticky fields. `clearContext()`: drop everything previously added via `setContext`. ```javascript tg.identify("usr_123"); tg.setContext({ release: "v2.1.0", environment: "production", email: "alice@example.com", plan: "pro", region: "us-west", subscription: { tier: "pro", seats: 12 } }); ``` Tailglow doesn't impose a specific shape on your context: flat or nested, whatever queries naturally for your data model. Mid-session updates (e.g. CodePush bumps `release`, an Electron auto-update flips `dist`, a UI toggle changes `environment`) are just `setContext({...})` calls. There are no special-case setters. #### Sticky-sample identity transition Sampling key cascades `user_id` → `device_id` → `session_id`. An anonymous user (sampled by `session_id`) who later calls `identify()` shifts to `user_id`-keyed sampling, and the verdict can flip in or out mid-session. Identify before any tracking when you need the sampling verdict to stay keyed to the user for the whole session. #### Identity changes (logout / login / org switch) There is no `reset()` method. The pattern is flush, destroy, reconstruct: ```javascript await tg.flush(); // attempt to drain pending records under the old identity await tg.destroy(); // remove listeners, stop the queue interval tg = new Tailglow({ ...sdkConfig }); ``` ### Opt-out and privacy The default browser SDK path is cookieless and uses no persistent browser storage. Whether you need consent or a banner still depends on what you collect, how you use it, and the laws that apply to you. Disclose collection in your privacy policy and honor Do Not Track / Global Privacy Control (the browser SDK does by default, configurable). To let a user turn analytics off: `optOut()`: clear buffered records and make the core drop new records until `optIn()`. It does not cancel a request body already handed to `fetch`, and browser collectors remain installed. Some collectors can retain observations while opted out and emit them after a later `optIn()`. Call `await tg.flush()` first only if you intentionally want to attempt delivery of buffered records before opting out. `optIn()` / `isOptedOut()`: resume tracking / check status. ```javascript tg.optOut(); // drop buffered records and stop accepting new records in the core tg.optIn(); // resume ``` For consent gating, construct the SDK only after the user accepts. On revocation, call `optOut()` first to clear buffered records, then call `destroy()` to remove collectors and listeners. Neither call can cancel a request body already handed to `fetch`. Create a new SDK instance if the user later grants consent again. ```javascript if (userAccepted) tg = new Tailglow({ ...config }); // later, to revoke: tg.optOut(); await tg.destroy(); ``` ### Lifecycle `flush()`: async; attempt to flush all queued records and wait for the current flush cycle. Retryable failures that exhaust their transport attempts remain queued. `destroy()`: async; attempt one final queue flush, remove platform listeners, and stop the interval. It does not guarantee delivery after a permanent or exhausted transient failure. `getStats()`: `{queueCount, queueBytes, sentCount, lastSendAt, lastSendOk}` for production debugging. Queue count and bytes cover the buffered queue, not records currently in an in-flight batch. #### Exit-time delivery Browser tab-hide delivery via `navigator.sendBeacon` is best-effort. `@tailglow/core` does not install Node process listeners, so wire your own shutdown handler and await `flush()` and `destroy()` while the runtime can still perform network work. Those calls wait for the SDK's delivery attempts, but they cannot guarantee delivery when the network or ingest service keeps failing. ## Configuration All options have sensible defaults. Only `url` is required, and it may already carry the key. ### Core options (all packages) | Option | Type | Default | Description | | -------------------------- | --------------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `url` | `string` | required | Full project ingest endpoint, such as `https://{region}.ingest.tailglow.io/{project_id}`. Copy it from the source's Ingest tab, where it already carries `?key=`. | | `key` | `string` | optional | Ingest key (starts with `tg_ingest_`). Omit it when `url` carries one; supplying it overrides the carried key. | | `enabled` | `boolean` | `true` | Environment gate. When `false`, normal capture, identity, context, lifecycle, and diagnostic methods are inert or return neutral values. No timers, network, queue, or collectors are created. With `debug: true`, construction logs one disabled diagnostic. Do not call core-only transport or queue escape hatches such as `getTransport()` or `drainQueue()` on a disabled `TailglowCore`. | | `collections` | `{ events?, errors?, logs? }` | `{ events: "events", errors: "errors", logs: "logs" }` | Routing destinations. `events` = `track()` + event auto-collectors; `errors` = `captureException`/`captureMessage`/uncaught errors/`console.error`; `logs` = the other enabled console wrappers. Set all three to the same slug to merge into one timeline collection. | | `context` | `Record` | - | Initial sticky context (JSON-serializable values only). Every key is stamped on every record unless the record already has that key. Mergeable later via `setContext()`. Capped at 64 top-level keys and 8192 serialized bytes. A non-object value or array is ignored silently; an object that cannot serialize to an in-cap JSON object is rejected whole and logs one warning for that violation kind. | | `flushInterval` | `number` | `30000` | Auto-flush interval in ms | | `flushSize` | `number` | `100` | Auto-flush at this record count | | `maxBatchBytes` | `number` | `15000000` | Approximate serialized-byte target used to split queued records into outgoing batches. A single record can exceed it when `maxRecordBytes` is configured higher. | | `maxQueueSize` | `number` | `10000` | Maximum records in the buffered queue. In-flight batches are tracked separately, so this is not a strict process-wide record or memory cap. The oldest buffered record is dropped when the buffer is full. | | `maxRecordBytes` | `number` | `1000000` (1MB) | Drop records larger than this (serialized JSON). Emits a collapsed `tglow_record_dropped` self-event, at most one per drop reason (size or unserializable) per 60s. `dropped_count` spans every collection dropped for that reason in the window, and the other `dropped_*` fields reflect the most recent drop. Pass `Infinity` to disable. | | `sessionTimeout` | `number` | `1800000` | Session timeout (30 min) | | `onSessionRotate` | `(info) => void` | - | Fires after the session ID rotates (timeout or `rotateSession()`), with a snapshot of the ended session: `previous_session_id`, `reason`, `started_at`, `last_activity_at`. | | `maxRetries` | `number` | `3` | Retry attempts after network errors and 5xx, 408, or 429 responses. Honors `Retry-After`. | | `retryDelay` | `number` | `1000` | Initial retry delay (doubles each attempt) | | `sampleRate` | `number` | `1.0` | Sticky sampling rate (0 to 1) | | `deviceId` | `string` | - | Customer-supplied device ID for this SDK instance. The caller owns persistence across launches. | | `userId` | `string` | - | Initial user ID | | `storageAdapter` | `StorageAdapter` | - | Async storage adapter for non-browser persistence | | `onBeforeSend` | `(record) => record \| null` | - | Filter/enrich records, return null to drop | | `onTransportError` | `(error, batch) => void` | - | Fires for a collection group rejected by a non-retryable 4xx and for unexpected exceptions in the SDK send path, with the affected records. Exhausted retryable network, 408, 429, and 5xx failures are requeued without calling this hook. | | `redact.enabled` | `boolean` | `true` | Master redaction switch | | `redact.redactEmails` | `boolean` | `true` | Redact email-shaped strings | | `redact.redactFields` | `string[]` | - | Drop these top-level fields | | `redact.allowFields` | `string[]` | - | Restrict top-level fields to an allowlist. Internal `__tg_*` routing plus `event_id`, `event_time`, `session_id`, `user_id`, `device_id`, and `sdk` pass automatically. Include `type` in the allowlist if you want to preserve it. | | `redact.stripQueryStrings` | `boolean` | `false` | Strip the query string and hash from the top-level `url`, `referrer`, and `href` fields (rewrites to origin plus pathname). Only `http` and `https` URLs are rewritten; other schemes (`ftp:`, `data:`, `blob:`, etc.) and unparseable values pass through unchanged. Opt in. Leaves nested values and breadcrumbs untouched. | | `errorBurst` | `object` | see above | Per-fingerprint client-side rate limit. Keys: `threshold` (default 10), `window_ms` (1000), `cooldown_ms` (120000), `max_entries` (1000). | | `rateLimit` | `{ burst?, perMinute? } \| false` | `{ burst: 200, perMinute: 120 }` | Global token-bucket rate limit across every record type, enforced after sticky sampling and before stamping or queueing. Each admitted record spends one token; when the bucket empties records are dropped and a collapsed `tglow_rate_limited` self-event reports the count (at most once per 60s). `burst` must be a finite number at least 1 and `perMinute` a finite number at least 0 (`perMinute: 0` is drain-only); invalid values fall back to defaults with one warning. Pass `false` to disable. | | `breadcrumbBuffer` | `number` | `100` | Ring buffer size for breadcrumbs. | | `debug` | `boolean` | `false` | Console logging | **Environment gating.** Set `enabled: false` for environments where you don't want to report, such as unprovisioned previews, CI, or local development. A disabled instance starts no timers, opens no network connections, queues nothing, and installs no auto-collectors. Normal public wrapper methods remain safe and diagnostic getters return neutral values. `debug: true` deliberately logs one disabled diagnostic, while the default `debug: false` path stays silent even when `url` and `key` are empty. The recommended pattern is `enabled: env === "production" && Boolean(key)`. ### Browser-only options (`@tailglow/browser`) | Option | Type | Default | Description | | ----------------------- | ------------------------------------------------ | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `autoPageViews` | `boolean` | `true` | SPA navigation tracking | | `autoSections` | `boolean` | `true` | `data-telemetry` element visibility + clicks | | `autoErrors` | `boolean` | `true` | Uncaught errors and unhandled rejections | | `autoVitals` | `boolean` | `true` | Lightweight browser performance signals named LCP, CLS, INP, FCP, and TTFB. These are SDK approximations, not standards-compliant Core Web Vitals calculations. | | `autoDevice` | `boolean` | `true` | Send device info on init | | `autoSessionSummary` | `boolean` | `true` | Emit `session_summary` records (engaged time, pages viewed, entry/exit paths) on tab hide/unload and session rotation. Requires `autoPageViews`. Each emission carries cumulative totals for its `session_id`: read the last record per session. | | `autoConsole` | `Array<"log"\|"warn"\|"info"\|"debug"\|"error">` | `["error","warn"]` | Console levels that emit records on the wire. Levels not listed still feed breadcrumbs. `[]` disables wrapping entirely. | | `spaMode` | `"auto" \| "history" \| "hash" \| "off"` | `"auto"` | SPA navigation strategy | | `routeContext` | `() => object \| null` | - | Called at every page_view emission; returned fields (route template, params) merge into the record. Auto-collected fields win on collision. Use it to stamp a stable router route ID for downstream views and metrics. | | `sectionAttribute` | `string` | `"data-telemetry"` | Attribute name for section tracking | | `intersectionThreshold` | `number` | `0.5` | Visibility ratio for "seen" | | `honorDnt` | `boolean` | `true` | Honor `navigator.doNotTrack` | | `honorGpc` | `boolean` | `true` | Honor `navigator.globalPrivacyControl` | | `excludeLocalhost` | `boolean` | `true` | Skip tracking on localhost / file:// | | `respectDevOptOut` | `boolean` | `false` | Read `tglow_ignore` localStorage flag | ## Privacy defaults The browser SDK is designed to operate without persistent client storage: | Default | Behavior | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Honor DNT | If `navigator.doNotTrack === "1"`, the SDK is fully disabled. | | Honor GPC | If `navigator.globalPrivacyControl === true`, the SDK is fully disabled. | | Skip localhost | The SDK does not track on `localhost`, `127.0.0.1`, `0.0.0.0`, or `file://`. | | No browser storage | The default browser path does **not** read or write cookies, localStorage, sessionStorage, or IndexedDB. | | Redaction | URL token patterns and email-shaped strings are redacted before send, recursively through at most eight container levels. Strings longer than 4,096 characters are not scanned. | The `tglow_ignore` developer escape hatch (set `localStorage.setItem("tglow_ignore", "true")` in your browser) is opt-in via `respectDevOptOut: true`. Useful for staging/dev builds. ### Console capture Default `autoConsole: ["error", "warn"]`: only severity-flagged console calls become records on the wire. `log` / `info` / `debug` are still wrapped (so they feed the breadcrumb buffer that attaches to the next captured error), but don't emit records by themselves. This matches Sentry-style "errors with context" behavior out of the box, while leaving the data-lake firehose one config away. To broaden capture, list more levels. To disable entirely, pass `[]`. ```js // Default: errors and warnings as records, all levels in breadcrumbs new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key" }); // Errors only on the wire, breadcrumbs still capture from log/warn/info/debug new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key", autoConsole: ["error"] }); // Capture everything (data-lake mode) new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key", autoConsole: ["log", "warn", "info", "debug", "error"] }); // Disable entirely: no wrapping, no breadcrumbs from console new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key", autoConsole: [] }); ``` Routing per level when emitted: - `log` / `warn` / `info` / `debug` → configured `logs` collection with `type: ""` - `error(Error)` → `captureException` → configured `errors` collection with `type` = error class name - `error(string)` → `captureMessage` (level: `"error"`) → configured `errors` collection with `type: "Message"` **PII**: whatever your code logs can be sent. Automatic URL-token and email redaction scans strings up to 4,096 characters and traverses at most eight container levels, including typical breadcrumb messages, frame filenames, and nested objects within those limits. `redact.redactFields` and `redact.allowFields` apply only to top-level fields. For stricter guarantees, remove sensitive data at the source or in `onBeforeSend` instead of relying only on automatic redaction. **Opt-out**: breadcrumbs are dropped while the SDK is opted out (`tg.optOut()`). Pre-opt-out activity does not leak into post-opt-in captures. ## Testing on localhost By default the SDK skips tracking on `localhost`, `127.0.0.1`, `0.0.0.0`, and `file://` so your local dev runs don't pollute production analytics. To verify the integration end-to-end during development, opt back in with `excludeLocalhost: false`. ### ESM ```javascript import { Tailglow } from "@tailglow/browser"; const tg = new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_your_key", excludeLocalhost: false, // enable on localhost context: { environment: "development" }, // tag dev events so they're filterable debug: true // log SDK activity to the console }); ``` ### Drop-in script ```html ``` (`data-release`, `data-environment`, and `data-dist` flow into `context` automatically. For richer context, call `tglow("setContext", {...})` after the script loads.) ### Recommended: tag dev events with a distinct `environment` When you enable localhost tracking, the events flow into the same ingest as production. Set `context: { environment: "development" }` (or `"staging"`, `"local"`, whatever you want) so you can filter dev events out of production dashboards or build a separate "Dev events" view. Without this, your local records show up next to real customer events and skew metrics. A common pattern is to drive it from the build environment. This example uses Vite's `import.meta.env`; adapt the environment API for your bundler: ```javascript const environment = import.meta.env.MODE; new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_...", excludeLocalhost: import.meta.env.PROD, context: { environment } }); ``` ### Want to disable in dev too? Use `tglow_ignore` The `tglow_ignore` localStorage flag is a per-browser kill-switch. Useful when you're running an env where the SDK is enabled but you specifically don't want your own events captured (QA accounts, automated tests, your own dev session). The SDK only reads it when configured with `respectDevOptOut: true`: ```javascript new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_...", respectDevOptOut: true }); ``` Then in the browser console: `localStorage.setItem("tglow_ignore", "true")`. SDK will be disabled on next load. ## Auto-collected events (browser) Browser event auto-collectors route page views, clicks, vitals, device snapshots, and similar records to the configured `events` collection with a `type` discriminator. Uncaught errors route to `errors`; enabled console wrappers route warnings and other non-error console records to `logs`, while `console.error` routes to `errors`. Use the `type` field when building views, metrics, or facet-filtered records API requests to distinguish `page_view`, `click`, `vital`, and other record kinds. ### Page views: `type = "page_view"` ```json { "type": "page_view", "from_path": "/", "to_path": "/pricing", "duration_ms": 4500, "nav_type": "push", "url": "https://example.com/pricing" } ``` The URL field uses `` if present, otherwise `window.location.href`. ### Section visibility & clicks `type = "section_view"` | `"click"` | `"outbound_click"` | `"scroll_depth"`. ```html
...
``` ```json // section_view { "type": "section_view", "section": "hero", "path": "/", "duration_ms": 8200 } // click { "type": "click", "section": "pricing", "path": "/", "tag": "button", "text": "Sign up" } // outbound_click { "type": "outbound_click", "href": "https://github.com/...", "text": "View on GitHub", "path": "/" } // scroll_depth { "type": "scroll_depth", "depth_percent": 85, "path": "/" } ``` ### Errors: `errors` collection ```json { "type": "TypeError", "message": "Cannot read 'x' of null", "stack_raw": "TypeError: Cannot read 'x' of null\n at ...", "frames": [ { "filename": "https://cdn.example.com/app.min.js", "function": "calculateTotal", "lineno": 1, "colno": 48201, "in_app": true } ], "fingerprint": "9c3f8a1b", "mechanism": { "type": "uncaught", "handled": false }, "level": "error", "breadcrumbs": [ { "category": "console", "level": "log", "message": "...", "timestamp": 1700000000000 } ] } ``` `type` here is the JS error class name. Same shape from manual capture (`captureException`), the auto-collector (`window.addEventListener("error", ...)` / `unhandledrejection`), and the console wrapper (`console.error(err)`); only `mechanism.type` differs (`"manual"` / `"uncaught"` / `"unhandled_rejection"` / `"console"`). ### Performance signals: `type = "vital"` ```json { "type": "vital", "vital_name": "LCP", "vital_value": 1200, "path": "/" } { "type": "vital", "vital_name": "CLS", "vital_value": 0.05, "path": "/" } ``` These are lightweight performance measurements, not standards-compliant Core Web Vitals. LCP uses the latest observed largest-contentful-paint start time. CLS sums layout-shift values without recent input across the page lifetime, rather than applying the standard session-window algorithm. INP is the maximum observed event duration, rather than the standard interaction percentile calculation. FCP and TTFB come directly from paint and navigation performance entries. ### Device: `type = "device"` Sent once on init. Includes browser, OS, device type, screen, viewport, language, timezone, connection (effectiveType / downlink / rtt), referrer source, and UTM parameters. ### Session summary: `type = "session_summary"` ```json { "type": "session_summary", "session_id": "sess_Abc123", "engaged_ms": 145200, "pages_viewed": 7, "entry_path": "/", "exit_path": "/pricing", "reason": "hide" } ``` Emitted on tab hide/unload (`reason: "hide"` / `"unload"`), on session rotation (`"rotate"`), and on `destroy()` (`"destroy"`). Each emission carries **cumulative** totals for its `session_id`: totals only grow within a session, so read the last record per session (for example, a metric grouped by `session_id` with the last-value chart mode). `engaged_ms` counts only active, visible time, matching the page_view `duration_ms` semantics. Disable with `autoSessionSummary: false`. ## Record metadata The SDK stamps this metadata when it is available, but **only if the customer hasn't already set the field**. Customer-explicit values always win on collision. | Field | Description | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event_id` | Unique 16-character correlation ID. The client uses it to avoid some repeat sends within one live SDK instance, but the ingest service does not deduplicate by this field. Duplicate records remain possible, and overriding it does not provide server-side idempotency. | | `session_id` | SDK's session ID, renews after `sessionTimeout`. Customer can override. | | `event_time` | ISO 8601 timestamp of when the SDK queued the record. Customer can override (occurred-at). Overridden times older than the project's late data window are held for a manual re-backfill instead of charting automatically; see [Late data](/guides/metrics#late-data). | | `user_id` | Included after `identify()` or `userId` is set. Customer can override per-record (B2B/CRM use cases). | | `device_id` | Included after `setDeviceId()` or `deviceId` is set. Customer can override. | | `type` | Event kind within the collection (e.g. `"page_view"`, `"signup"`, `"TypeError"`). Stamped from `track(name, ...)`'s `name` argument or by auto-collectors. Customer can override per-record. | | `sdk` | SDK package name and version. Included unless the customer provides an `sdk` field. | Plus any sticky fields from `context` (constructor) or `setContext()`: those also follow the customer-wins rule (only stamp if the record doesn't already have that key). The collection (routing destination) is **not** a field on the record. It's the URL slug in `?collection=`. The record's `type` field discriminates the kind of thing within that collection. ### Reserved field names These names are reserved for SDK metadata. You can still use them as your own fields and your value will appear on the wire instead of the SDK's. But by convention, treat them as SDK-controlled and use distinct names if you mean something different (e.g. `subject_id` instead of `user_id` to track a CRM contact distinct from the authenticated app user). ``` event_id, event_time, session_id, user_id, device_id, type, sdk ``` ## Transport All requests go to `POST {url}?key={key}&collection={slug}` with `Content-Type: text/plain`. There is no `Authorization` header and no custom request headers; this is a CORS "simple request" with no preflight, so cross-origin installs have no `OPTIONS` round-trip. Failed requests retry on 5xx, 408, and 429. With the default `maxRetries: 3` and `retryDelay: 1000`, the three retry waits are 1s, 2s, and 4s. Raising `maxRetries` adds later waits such as 8s, capped at 30s. The transport honors the `Retry-After` response header and drops a collection group on other 4xx responses. On page hide, the browser SDK attempts best-effort delivery with `navigator.sendBeacon`. A `true` return means the browser accepted the data for transfer, not that the ingest service received it. If the browser rejects a buffered beacon and the page remains alive, the SDK requeues those records for a later fetch attempt. ## Hooks `onBeforeSend` intercepts records before they are queued. Return the record (optionally modified) to keep it, or `null` to drop it. The internal `__tg_collection` field carries the collection routing; read it to filter by collection. ```javascript const tg = new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_...", onBeforeSend: (record) => { if ( record.__tg_collection === "errors" && record.frames?.some((f) => f.filename?.includes("third-party")) ) { return null; } record.app_build = "abc123"; return record; } }); ``` ## Pipeline order The common path for records accepted by `track()` or `capture()` is: ``` session touch → sticky sampling → rateLimit gate → stamp → redact → maxRecordBytes check → onBeforeSend → queue → flush → transport ``` - Error and message capture first packages the error, computes its fingerprint, snapshots breadcrumbs, and applies the per-fingerprint `errorBurst` gate. Records that pass then enter the common path above. - Sticky sampling runs before the global `rateLimit` bucket. A record either gate drops is never stamped, redacted, size-checked, passed to `onBeforeSend`, or queued. Rate-limit drops surface as a collapsed `tglow_rate_limited` self-event. - `onBeforeSend` sees the post-redaction record. Set `redact.enabled: false` if your hook needs raw payloads. - `maxRecordBytes` runs before `onBeforeSend`; oversized records never reach the hook. - `onTransportError` fires for immediate non-retryable 4xx rejections and unexpected exceptions in the send path. Exhausted retryable failures are requeued without calling the hook. ## Lifecycle without auto-collectors If you want browser-side queueing + visibility flush + sendBeacon delivery but **not** the auto-collectors (Electron renderer, embedded WebView, etc.), disable them all and use `track` manually: ```javascript const tg = new Tailglow({ url: "https://{region}.ingest.tailglow.io/{project_id}", key: "tg_ingest_...", autoPageViews: false, autoSections: false, autoErrors: false, autoVitals: false, autoDevice: false, autoConsole: [], excludeLocalhost: false }); // Visibility/beforeunload flush via sendBeacon stays active. ``` `excludeLocalhost: false` is required for Electron renderer pages loaded from `file://`, which the browser package excludes by default. ## Typed event schemas Augment `@tailglow/core`'s `TailglowEventTypes` interface. This is the canonical location whether you use the browser package, the React Native package, or core directly. Event types not in the schema fall through with `Record`. The augmented keys describe the `type` field of records sent to the configured `events` collection, not a separate collection per key. ```ts declare module "@tailglow/core" { interface TailglowEventTypes { signup: { plan: "free" | "pro" }; purchase: { amount: number; currency: string }; } } tg.track("signup", { plan: "pro" }); // ✓ typed tg.track("signup", { plan: "wrong" }); // ✗ TS error tg.track("anything_else", { whatever: true }); // ✓ falls back to Record ``` ## Platform support | Platform | Auto-collection | Lifecycle | Storage | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Browser (`@tailglow/browser`) | Page views, tagged sections and clicks, declarative and outbound clicks, JS errors, console breadcrumbs plus error/warn records, performance signals, device | Best-effort `visibilitychange` / `beforeunload` delivery through `sendBeacon` | In-memory by default | | Node / Bun / edge (`@tailglow/core`) | None. Call `track()` and capture methods explicitly | No automatic process or request hook. The caller must await lifecycle methods when needed | In-memory unless a `storageAdapter` is provided | | React Native (`@tailglow/react-native`) | JS errors, best-effort rejection hooks, console breadcrumbs plus error/warn records; screen views after `attachNavigation()`; device when modules are provided | Injected `AppState` starts best-effort persist, then flush, when leaving active | Optional `createAsyncStorageAdapter(AsyncStorage)`, newest 1,000 records | | Electron renderer | Use `@tailglow/browser`; set `excludeLocalhost: false` for `file://` | Same best-effort lifecycle as browser | In-memory by default | | Electron main | Use `@tailglow/core` | Customer owns the quit lifecycle and must keep the process alive for awaited delivery attempts | In-memory unless a customer adapter is provided | # Teams ## Overview A team is the topmost level of organization in Tailglow. You can have multiple projects within a team, and you can add different users to each team. ## Creating a Team A new account starts without a team. After profile setup, the **Set up your team & project** onboarding form creates the first team and project when you click **Create Team & Project**. To create another team later, open the team switcher in the top toolbar, select **Create New Team**, and complete the same form. ## Team Settings To access your team settings, click your team name in the top toolbar. This opens the team overview, where you can view all projects. Select the settings icon next to **Add New**. ### General In the **General** settings, you can: - Change your team name. - View your team's status. - Update your team's logo. - Delete your team. If you delete your team, it will not be removed immediately. Instead, every signed-in member is signed out, every ingest key is revoked, every API key is deleted, the team's servers are scaled to zero, and permanent removal is scheduled for forty days later. Nothing is billed while a team is archived. If an Owner selects the archived team before then, Tailglow restores the team itself. Its projects remain scheduled for deletion, so restore each project from its **Settings** page. Scheduling deletion revokes every active ingest key across those projects. Restoring the team and its projects does not reactivate those keys, so add active ingest keys to their sources before sending data again. If you need the team deleted immediately, contact support. Only an Owner can do this. In the **Delete Team** card, click **Schedule For Deletion**, then confirm by typing your team's name and the phrase **Schedule To Delete**. Both fields ignore case and surrounding spaces. Everyone is signed out as soon as you confirm, so the confirmation is deliberately heavier than the one on other resources. ### Statuses There are four statuses for your team: - **Active**: Your team is active and can be accessed by all team members. - **Delinquent**: Tailglow emails your billing contact after a failed payment. A non-Enterprise team can become delinquent if an invoice becomes uncollectible or remains unpaid into a later billing cycle. Ingestion is paused until the issue is resolved. - **Restricted**: Your team is read-only and ingest keys are disabled. Billing updates remain available so an Owner can address billing. An Owner cannot delete a restricted team through the application and must contact support. - **Blocked**: Your account has been blocked, typically due to a violation of our terms of service. You will no longer be able to access the account. ### Users In the **Users** settings, you can manage everyone who has access to your team. All users will have access to all projects within the team. ### Security In the **Security** settings, you can: - **Require MFA**: Turn on **Require Multi-factor authentication** to require every team member to enable MFA before accessing the team. Only the Owner can change this setting, and the Owner must have verified MFA first. ### Billing In the **Billing** settings, you can: - **Billing Email**: Set a billing-specific email address for invoices and payment notifications. - **Billing Plan**: View and manage your current billing plan. - **Billing Address**: Set your team's billing address for invoices. ### Roles In the **Roles** settings, you can create roles for your team members. By default, there are two roles: **Owner** and **Member**. The built-in **Owner** role cannot be created, updated, or deleted, and there must always be at least one owner. The **Quick fill** actions are **Common**, **Full access**, and **Clear**. You can adjust the permissions before saving. **Clear** removes optional access while retaining the project read access required for team members. # Users ## Overview Users are individuals who have access to a specific team within Tailglow. Each user has one role in that team, which determines their permissions. By managing users effectively, you can ensure proper access control for your projects. ## Adding Users To add a new user to your team: 1. Click your team name in the top toolbar, then click **Team Settings** on the team overview. 2. Go to the **Users** tab. 3. Click the plus button in the **Users** card. 4. Enter the user's name, email address, and assign a role. 5. Click **Add User**. Tailglow adds the user to the team immediately and emails them. Someone new to Tailglow gets a button that opens the sign-in page with their email filled in. Someone who already uses Tailglow gets a link to the app. ## Managing Users In the **Users** tab of your team settings, you can: - **View all users**: See a list of all users currently in your team. - **Review activity**: See `Recently active` when a user used Tailglow within the last five minutes, or the relative time of their last activity otherwise. Activity is global and may have occurred in another team. - **Edit roles**: Change the role of a user by selecting from the predefined roles or custom roles you've created. If you change a user's role, they will be notified via email and signed out. - **Remove users**: Click the user's edit button, then hold the trash button labeled **Hold to remove user** until the action confirms. ## Updating Your Profile To update your own profile, click on your image in the top right corner and select **Profile**. Here, you can update your name, preferences, and profile image. ## Roles and Permissions Users' access and capabilities within the team are determined by their assigned roles. Each role has specific permissions. By default, Tailglow includes two roles: - **Owner**: Full access to all features, including team and project management. - **Member**: Can view data but has limited permissions for modifying settings or projects. You can also create custom roles under the **Roles** tab in the settings to provide more tailored permissions. Use **Common**, **Full access**, or **Clear** as a starting point when creating a custom role, then adjust its permissions before saving. See [Permissions](/guides/permissions) for details. ## Notification Preferences Each user can configure their notification preferences from **Profile** > **Notifications**: - **Auto-subscribe to new monitors**: Automatically subscribe to notifications for newly created monitors. - **Product Updates**: Choose whether to receive noteworthy product and feature announcements. # Projects ## Overview A project in Tailglow represents a container for your sources, metrics, and pages. Projects are used to organize data for specific purposes, such as a product, application, or environment. Each project has its own settings, while a member's team role scopes govern access across the team's projects. ## Creating a Project To create a new project: 1. Navigate to your **Team Overview** by selecting your team name in the top toolbar. 2. Click the **"Add New"** button in the top-right corner. 3. Enter the project name and click "Create Project". 4. Once created, the project will appear in your **Team Overview**. ## Project Settings To access a project's settings: 1. Select a project from the sidebar. 2. Navigate to the **Settings** tab. ### General Settings In the general settings, you can: - Rename your project. - Update the project start date, which Tailglow uses as the starting point for displayed charts. - Set the late data window, which controls how far back an event with an overridden timestamp can reach and still enter charts automatically. See [Late data](/guides/metrics#late-data). - Delete the project. **Note**: Deleting a project schedules it for permanent removal seven days later. You can restore the project from the settings page any time before that date. Ingest keeps running for the whole window, so a restored project carries on with nothing missing. ### Sources Sources own ingest configuration and ingest keys. Collections under a source own the records, files, and schemas. You can manage sources and their ingest keys from **Settings** > **Sources** in your project. ### Views In this section, you can: - Create, edit, and delete views that use TGL to transform collection or view inputs and join data when configured. ## Sending Data to a Project Each ingest key authenticates a source. Tailglow routes an accepted request to a collection under that source using the request's collection selection or the source's default routing. To send data: - Send data to your project's ingest endpoint (found in your source settings), e.g. `https://us11.ingest.tailglow.io/prj_xxx`. - Include a source's ingest key in the `key` query parameter, or use the `Authorization` header. Refer to the [Ingest Key](/guides/ingest-key) documentation for detailed steps on sending data. ## Deleting a Project If a project is no longer needed and its data is no longer relevant, you can delete it. Deleting a project will: - Schedule permanent removal of all data, settings, and configurations for seven days later. - Allow you to restore the project any time before that removal date. - Offer a **Delete Permanently** option in project settings, if you would rather not wait out the window. That one cannot be undone. - Keep accepting data until the removal date, so restoring the project loses nothing. To schedule a project for deletion: 1. Open the project's **Settings** tab and select **General**. 2. In the **Delete Project** card, press and hold **Hold to Schedule Deletion** until it completes. The project settings page then shows a red banner counting down to the removal date. Click **Restore Project** there at any point before it to cancel. To remove the project immediately instead: 1. Click **Delete Permanently** in that banner. 2. Type the project name, then type **Delete permanently**. 3. Click **Delete permanently**. This cannot be undone. ## Best Practices - **Use separate projects for different environments**: For example, create distinct projects for production, staging, and development environments. - **Organize projects by product or feature**: If you have multiple products, consider creating one project per product for better data separation and management. - **Monitor project activity**: Regularly check activity logs and metrics to ensure the project is running as expected. # Sources Sources organize the data sent to a project. Each source has its own ingest keys and settings, and contains collections of related records. ## Create and configure a source 1. Open project **Settings** and select **Sources**. 2. Click the plus button. 3. Enter a name and click **Create Source**. 4. In the source drawer, open **Ingest** to copy an ingest endpoint or manage keys. Creating a source does not guarantee that a key was created. Use **Add Key** in the Ingest tab if you need one. ## Collections and schema detection Sources begin with no collections. Tailglow chooses one collection for each ingest request: the `?collection=` value when it is valid, otherwise the source's `catchall` collection. Fields inside the records, including `type`, never choose the collection. All records in a JSON array or JSONL request use that collection. Collection names are normalized before they are matched, so `?collection=Charges`, `?collection=CHARGES`, and `?collection=charges` all resolve to the same `charges` collection. Normalizing trims the value, lowercases it, replaces every character outside `a-z`, `0-9`, `_`, and `-` with a hyphen, collapses repeated hyphens, and truncates to 64 characters. A value with no letters or digits left after that is ignored rather than rejected, and the request goes to `catchall`. The collection's `name` field carries its display casing. A source supports up to 100 collections. New collection names route to `catchall` after the source reaches that guardrail. A burst of simultaneous requests can briefly create more than 100 collections. Each collection detail page lists schema versions with their state (candidate, settled, or stale), rows, files, and last-seen time. Use the eye button to inspect a version's fields and types. **Version details** shows why it settled and its dates; the drawer also shows whether a field has appeared as null, empty, or absent. Choose **Settle version** in the drawer when you trust a candidate or stale shape and do not want to wait for it to recur. Settling is one way: a settled version never goes back to candidate. [Concepts](/guides/concepts#schema-versions) explains the states. The aggregate **Schema Tree** remains on the collection page to compare fields across versions. With **Automatic** detection, Tailglow groups changing keys when existing mappings can keep working. It leaves a proposal unchanged when a mapping reads inside that path, or when a mapping's reads cannot be determined. There is no approval task in Automatic mode. With **Manual** detection, the **Schema proposals** card shows suggested groups. Its eye button opens the proposed changes, including the remaining shapes and tracked child paths. Choose **Group these keys** to apply it or **Leave unchanged** to close it. The drawer warns when an existing mapping may need updating. These changes require `sources:write` access. ## Schema settings The collection's **Overview** includes a **Schema recognition** summary. Its edit button, or the gear in the page header, opens the settings drawer. **Recognition**, **Settlement**, and **Limits** group the options; choose **Save changes** to apply edits. Closing the drawer discards unsaved edits. Rules and settings are separate on purpose. Changing a rule re-keys the collection: every version and unclassified shape is re-signed under the new rules, and shapes that now match are merged into one version, which keeps its files and mappings. Before a rule change lands, a confirmation shows how many shapes the collection holds now and how many it would hold under the new rules. Changing a setting re-keys nothing. Rules: - **Grouped paths** keep arbitrary children out of schema identity while every raw value is still stored. Enter one path per line, such as `/metadata`. Escape a literal slash in a key as `~1` and a literal tilde as `~0`. - **Tracked child paths** restore tracking for selected children of an opaque path, such as `/metadata/customer_id`. - **Maximum depth** sets how many levels of nesting take part in identity. The default is 5. A mapping can read five levels deep, so raising this past 5 records deeper shapes without making them readable. - **Nulls and absent values**, **Optional keys**, and **Detection** are each **Automatic** or **Manual**. Automatic accepts null and absent values at any path a mapping reads, lets a record whose keys are a subset of a version's keys join that version, and applies a safe opaque-path proposal from the detector on its own. Manual waits for a person at each of those points. Settings: - **Recurrence gap**: how long after first sight a shape must be seen again before its version settles. The default is 60 minutes. - **Bulk rows**: a single batch carrying at least this many rows of a shape settles its version at once. The default is 100, and 0 turns the bulk path off. - **Stale after**: how long a candidate waits to be seen again before it goes stale. The default is 24 hours. - **Settled versions limit**, **Candidate pool**, and **Alias pool** bound how many settled versions, candidate and stale versions, and cached signatures a collection may hold. Past a bound, new shapes stay unclassified with their signatures kept. - **Files per batch**: how many collection files one ingest batch may open at once for this collection. A batch with more versions than that is written in more than one pass, so every shape with a version still lands in a file of its own version. Shapes past the candidate pool get the same number of files per batch, the shapes with the most rows first, so they can be linked to a version once the pool has room; the rows of shapes past that budget are kept in the batch's unclassified file and cannot be linked to a version later. - **Unclassified retention**: how many days the files of shapes that never settled are kept before they are deleted. That covers unclassified files and the files of stale versions, and a stale version with nothing left under it is deleted with them, together with the pairings views held on it. Leave it empty to keep them forever. For a version a view cannot map automatically, you can supply a hint, provide a script, or exclude that version from a particular view with a recorded reason. An ingest key's recent-use time indicates that requests reached the source. It does not mean every view and chart has finished processing them. ## Deleting a source Use the hold-to-delete control in the source drawer to schedule deletion. The source remains visible with a line-through name and a **Deleting** chip. Hover the chip or open the source drawer to see how long remains before permanent removal. Tailglow schedules removal for seven days later. Before that date, open the source drawer and click **Restore Source** to cancel deletion. The source keeps accepting data for the whole window, so a restored source carries on with nothing missing. The same drawer offers **Delete Permanently** if you would rather not wait. It asks you to type the source name, destroys every collection and record under it immediately, and cannot be undone. Permanent removal deletes the source, its collections and data, and any views built from those collections. Existing results from joins that used one of those views remain. If the removed view was the join's main input, the join stops receiving new records; if it was a lookup, new records are no longer enriched by it. Reconfigure or remove affected joins before permanent removal. # Views Views reshape data from a collection or combine existing views. Use them to prepare data for analysis, charts, and monitors. See [Sources](/guides/sources) for how incoming data is organized into collections. ## Create a view 1. Open **Views** and click **New View**. 2. In the **Collection** tab, select a **Source Collection**. 3. Enter a **View Name**. You can also add an **Output Schema** or **Generation Hint**. 4. Click **Create View**. To combine existing views instead, use the **View** tab and choose a base view with one or more lookup views. ## Inspect a view Open a view and select **Records** to inspect its transformed output. ## View status The status chip can show **Empty**, **Preparing**, **Indexing**, **Needs TGL**, **Active**, or **Error**. **Preparing** and **Indexing** mean Tailglow is building the view. **Needs TGL** means the view needs a transform script for a schema version. **Error** means generation or indexing needs attention. # Metrics & Monitors Metrics aggregate a view's data into charts. A metric needs a name, view, and timestamp field. Grouping and filters are optional. ## Create a metric 1. Open **Metrics** and click **New Metric**. 2. Choose a view and timestamp field. The UI selects the first eligible date or string output field by default. 3. Optionally choose **Group By**, a numeric value field, a unique-count field, and filters. 4. Click **Create Metric**. Tailglow backfills existing view data, then updates the metric from new data. The status indicates whether it is initializing, waiting for transforms, backfilling, active, in error, or cancelled. ## Partial results and waiting shapes Charts show available results with a compact coverage control in the header. Open it to see whether records need mapping or recovery work, or completeness is simply unverified. Unverified historical or time coverage can remain even when the source view has no pending shapes and its scripts are live. An amber region on Cartesian charts marks incomplete results with known mapping, recovery, or exclusion reasons; empty ranges show a no-data state. Trends and forecasts use verified complete buckets; they are unavailable when coverage is unknown or too little complete data remains. Monitors and storage sealing continue to use the verified boundary. Use **Inspect view**, then **Inspect** on a waiting shape, to see missing fields, changed types, possible substitutions, and the fields each candidate TGL reads. The drawer lists the shape's fields and types, using full paths for nested fields. **Activity details** shows its state, dates, source, stored rows, and schema observations. Pending shapes also show the next automatic check or requested hint. A small deferral-evidence count is not the total number of ingested records. Excluding a version records a decision for that view and version, including future matching records. It does not erase existing materialized output. Charts retain an exclusion notice; other views make independent decisions. Waiting for a schema mapping does not create a new late-data decision. Catch-up preserves original admission. Sealed history is rebuilt by re-backfilling the metric: a change to its data feed, or the re-backfill action, wipes its rollups and rebuilds them from the retained rows. Adding rows to the hot tier is not enough. ## Metric settings Metric settings are organized into four tabs. **Display** covers display value, time range, chart type, value unit, empty-interval handling, the maximum series shown, Compact Values, which rounds tooltip readings to compact notation such as 321.3M and is on by default, and Y Axis Min and Max, which pin either end of the y axis on line, area, and bar charts. Leave a bound empty and that side keeps fitting the data. **Analysis** covers trend lines, forecasting, and alert markers. **Colors** covers how series are pinned and painted. The metric's name is edited in the settings header. Tailglow chooses the interval from the selected time range. The **Query** tab lets you change the view, timestamp field, grouping, values, and filters. Changing it rebuilds the metric. Tailglow supports line, area, bar, pie, scatter, radar, stat, gauge, calendar, and uptime charts. Trend lines and forecasts are available for line, area, and bar charts. Alert markers are available for line, area, bar, pie, radar, and calendar charts. With trend lines on, the tooltip reports each bucket's distance from the trend, green above and red below, and a single-series chart adds the overall growth per period. A line whose direction the data does not support carries a small warning triangle instead. Calendar and uptime charts render time itself, so they read best over day-sized buckets. A calendar shades one cell per day (per hour when the range is a week or less) by value, and a metric with several series sums them into one calendar. An uptime strip colors one cell per bucket using the value rules from the **Colors** tab; a metric with several series draws one strip per series plus an Overall row carrying the worst value of any series in each bucket. An uptime chart in By Value mode with no rules yet offers a one-click preset: 99.9 and above green, 99 and above amber, anything lower red. Click any cell on either chart to zoom into that period. ## Forecasting A forecast extends a metric's best fit line past your latest data, so the chart shows where the metric is heading. Turn it on from the **Analysis** tab of the metric's settings with **Show Forecast**. **Default Horizon** sets how far ahead the chart looks: Next 7 days, Next 30 days, Next 90 days, End of quarter, End of year, or Next year. Relative horizons resolve when the chart is viewed, so a metric set to Next 30 days always looks 30 days past the day you open it. **Model** sets the shape of the projection. Auto follows whichever model fits the current data best, or you can pin Linear, Exponential, Logarithmic, Logistic, or Sinusoidal. Either way, the list marks the model that currently fits your data best. Every line, area, and bar chart in the app carries a forecast control in its header, whether or not the metric has forecasting saved. Use it to change the horizon or the model for your own view. The metric's saved settings do not change, and neither does what anyone else sees. **Use metric default** returns you to the saved settings, and your choice lasts only for the current visit. The projected part of the chart is drawn dashed, with a shaded band around it covering the range of likely values. The band is always shown with a forecast. In the tooltip, projected buckets add labeled columns: the estimate appears as a small chip on a track, with the bucket's bounds beside it. A bucket that is still filling in shows the value recorded so far under Now, with Est. and Max for the projected landing and ceiling; a fully projected bucket shows Min and Max around the estimate. Buckets that are fully measured keep the plain tooltip. When a fitted model explains little of a series' history, or its first projection leaps far from recent values, that series carries a small warning triangle in the tooltip: the forecast still draws, but read it as low confidence. Forecasts need a line, area, or bar chart. On a stacked bar chart every visible series gets its own fit, and the projected buckets draw as hatched ghost bars stacked in the same order as the bars. The tooltip reports each series' projection plus a Total row. On a stacked line or area chart the forecast projects the stack's total. ## Late data Most data arrives in order and charts simply fill forward. Data sent live is never late: an event without a timestamp of its own is stamped on arrival and always charts automatically. Only events with an overridden timestamp, such as the SDK's `event_time` field, can land in the past. This is normal when importing history, replaying a queue, or batching in an integration. How far back such an event may reach and still enter charts automatically is your project's late data window. ### The late data window Open project **Settings**, then find the **Late Data** card under General. The window is a number of minutes, counted back from the newest data already in your charts: - **Within the window**, a late event folds into charts automatically. Nothing to do. - **Beyond the window**, the event is stored and counted, but stays out of charts until you fold it in with a re-backfill. The default is 120 minutes, which covers most integrations. Set it to 0 to hold everything that arrives behind your charts: each such event is surfaced instead of charted. The maximum is 129,600 minutes (90 days). The window is a promise about charts, not about storage. Late events are kept in your views either way; only their aggregation waits. Records, exports, and drains are unaffected. Changing the window applies to events that arrive after the change. Events already held under the old window stay in **Late Data Waiting** until you re-backfill them. ### Re-backfilling late data When events are held out of charts, a **Late Data Waiting** card appears in the project's general settings. Each row is one batch: the view it belongs to, how many events were held, and the event-time range they span. Click **Re-backfill** to fold a batch in. The row shows **Queued**, and the events appear in charts as the fold completes, back to the earliest event in the batch. Very large batches can appear in this list even when their events are inside the window. Folding a batch that touches many hours of history is expensive on a busy metric, so a batch beyond roughly a hundred thousand events, or one spread across more than 48 distinct hours, waits for the same one-click confirmation instead of folding silently. The window itself never changes on its own: only you decide what enters charts automatically. ### Choosing a window The default suits the common pattern of backfilling history first and then running live. If your integrations regularly submit data that is hours or days old, widen the window so those events chart without manual steps. If you report on recent data and want it locked quickly, narrow the window or set it to 0 and treat **Late Data Waiting** as your review queue. ## Monitors Open a metric and use its monitor control to manage monitors. Click the add icon to create one. A metric can have up to 15 monitors. The drawer lets you choose threshold, sustained, existence, or no-data conditions, along with the evaluation window, frequency, alert length, occurrence threshold, expiry, series filters, and preview. A spanning alert remains open until it clears; an instant alert opens and ends at once. **Existence** fires when the selected metric value is greater than zero. To detect that a feed has stopped, choose **No data**, then set an evaluation window such as **10 minutes**. This condition counts observations across the whole window, even if the chart displays missing values as gaps. A measured value of zero still counts as data. Evaluation waits until the window is complete; a processing delay or unknown completeness does not itself mean data is missing. Use **Total** when the whole feed must go quiet, **Any series** when any known series going quiet should open one alert, or **Each series** for a separate alert per quiet series. Series filters narrow the observations being watched. A metric with no known series can trigger a total no-data alert; per-series scopes need a known series to watch. Evaluation windows have presets and a **Custom** duration in whole minutes. **All time** looks back to the metric's creation and is unavailable for no-data conditions. The frequency controls how often the rule is checked; it is separate from the window. The no-data preview checks the current window with the same rules as the evaluator. If the window is incomplete it reports that no verdict is available. It does not simulate scheduling or occurrence thresholds. A blinking red indicator means an alert is currently open. Ended alerts remain shaded on the chart as history, with their original condition and end time, but do not keep the indicator blinking. # Pages ## Overview Pages are customizable dashboards that display one or more metrics in a single view. They refresh automatically while you are viewing a live time range and can be shared publicly or served through a custom domain. ## Creating a Page To create a new page: 1. Navigate to the **Pages** section in the sidebar. 2. Click the **"New Page"** button. 3. Configure the following fields: - **Name**: Enter a descriptive name for your page, like "Quarterly Dashboard" or "Performance". - **Time Range**: This synchronizes the time range of all metrics on the page. - **Data Interval**: Choose the interval used to group the data. It defaults to **Day**. Preset time ranges disable intervals that are too small or too large; custom ranges allow any interval. 4. Click **Add Page** to save and generate your new dashboard. ## Time ranges and live updates Use the range picker to choose **Last hour**, **Last 24 hours**, **Past 7 days**, **Past 14 days**, **All time**, or a custom selection. A page can also have a different saved default range. Relative ranges, including All time, follow the present. Charts refresh at the interval they display: minute buckets refresh each minute and hourly buckets each hour. If you brush into history or choose fixed custom dates, that selection stays still and automatic refresh pauses. Choose a relative range again to follow new data. The status page created during onboarding starts with Last hour and one-minute intervals. Its first charts may take a few minutes to prepare. The page is initially private: **Open your status page** opens the internal page, and **Publish page** takes you to Sharing settings. Turn on **Publish page** and save when you want others to see it. Recent intervals can still be processing. Uptime and calendar cells show those intervals in gray; hover them to see **Processing**. Line, area, and bar charts shade the unfinished edge. Older gaps remain **No data**. Pie and radar timelines show completed snapshots, and refresh pauses while you scrub through older snapshots. Stats and gauges keep completed values visible while the next results are processing. ## Adding Metrics Once your page is created: 1. Click the **Settings** button on your page. 2. Navigate to the **Layout** tab. 3. Click the **Add Metric** button. You'll see a dropdown of all of your available metrics. 4. Select the metrics you want to display on the page. Each metric keeps its own chart settings on the page, including the trend lines and forecast saved on its **Analysis** tab. When forecasts are enabled on both the page and the metric, public line, area, and bar charts show a forecast button. Visitors can change the horizon and model, hide the forecast, or return to the metric default. These choices affect only their current view; they do not change the saved settings. ## Layout & Sizing You can customize the layout of your page by rearranging and resizing metric cards: - **Drag and Drop**: Drag metrics to rearrange their order on the page. - **Card Sizing**: Toggle each metric between full-width and half-width. Use full-width for metrics that need more space (like detailed line charts) and half-width to display two metrics side by side. ## Visibility & Sharing Pages can be shared publicly so that anyone with the link can view them, without requiring authentication. - **Public**: Toggle public visibility from the page settings. When enabled, the page is accessible via a public URL. - **Access Code**: Optionally require a shared access code. Visitors enter it once per browser. Changing or clearing the code requires visitors to enter it again. - **Show Trend Lines On Public Page**: Show or hide trend lines across the public page. Enabled by default; each metric must also have trend lines enabled. - **Show Forecasts On Public Page**: Show or hide forecasts and their controls across the public page. Enabled by default; each metric must also have forecasting enabled. - **Show Alerts On Public Page**: Enable this setting to show monitor alert markers on the public page. Alerts are hidden by default and must also be enabled on the underlying metric. - **Custom Domain**: You can serve pages through your own branded hostname (e.g., `status.yourcompany.com`). Configure a Page domain once in the **Domains** section of team settings. Every public page owned by the team is available from that hostname at its permanent generated slug. You can also give a page a readable path such as `/weekly-health` independently on each custom domain, or set that path to `/` so the page opens at the hostname root. ## Best Practices - **Use pages to monitor key metrics**: Pages are a great way to keep an eye on the most important metrics for your team or project. - **Share pages with stakeholders**: Public pages let stakeholders stay informed without needing a Tailglow account. - **Customize pages for different teams**: Create different pages for different teams to focus on the metrics that matter most to them. - **Use card sizing strategically**: Put high-level summary metrics (stat, gauge) at half-width and detailed time-series charts (line, area) at full-width for the best readability. # Custom Domains ## Overview Custom domains allow you to serve your Tailglow pages and ingest data through your own branded domain instead of the default Tailglow URLs. For example, instead of using `pages.tailglow.io/your-page`, you can use `analytics.yourdomain.com/your-page`. You can use custom domains for: - **Custom Pages**: Serve your public status pages and dashboards from your own domain. - **Custom Ingest**: Send analytics data through your own domain for first-party tracking. Custom domains are available on the Enterprise plan. A team can have up to 10 custom domains in total across Ingest and Page domains. Each hostname has one traffic purpose. You can configure several Ingest domains and several Page domains for the same team. ## Adding a Custom Domain To add a custom domain to your team: 1. Navigate to your **Team Settings** page. 2. Click the **"Domains"** tab. 3. In either the **Ingest domains** or **Page domains** table, click the add button. 4. Enter your custom domain (e.g., `analytics.yourdomain.com`). 5. Click **Add Ingest Domain** or **Add Page Domain**, matching the table you chose. The table you add the hostname from determines its purpose. After adding it, verify domain ownership and configure routing through a two-step DNS process. ## DNS Verification Setting up a custom domain is a two-step process: first verify ownership, then configure traffic routing. ### Step 1: Ownership Verification (TXT Record) Before your domain can be used, you must verify that you own it by adding a TXT record: 1. Go to your DNS provider's management console. 2. Add a TXT record: - **Name/Host**: The full name shown in Tailglow. For `analytics.yourdomain.com`, it is `_tailglow-verify.analytics.yourdomain.com`. - **Value**: The verification token shown in your domain settings 3. Wait for DNS propagation. Timing depends on your provider and the record's TTL. 4. Click **Check DNS** in the drawer, or **Check Now** beside the domain status, to check the TXT record. ### Step 2: Routing Setup Once ownership is verified, configure routing so traffic reaches Tailglow: **CNAME Record** A domain that serves traffic has to be a subdomain such as `analytics.yourdomain.com`. A root domain like `yourdomain.com` cannot hold a CNAME, so it can be verified but not used for ingest or pages. 1. Go to your DNS provider's management console. 2. Add a CNAME record: - **Name/Host**: The name shown in your domain settings. Your provider may display the same host relative to the DNS zone, such as `analytics`. - **Value/Target**: The CNAME target shown in your domain settings. 3. Wait for DNS propagation. 4. Click **Check DNS** to check the routing configuration. If your DNS provider offers proxying, use **DNS only** while setting up the domain. The hostname must point directly to the target shown in Tailglow so its certificate can be provisioned and renewed. A proxied record can leave certificate provisioning stuck or failed. ### Ongoing Checks Tailglow re-checks every record hourly, not just during setup. Both records have to keep resolving for the domain to keep working. If a record stops resolving, the domain keeps serving while you fix it: - **Ownership (TXT)**: 24 hours - **Routing (CNAME)**: 7 days Put the record back within that window and nothing is interrupted. Past it, Tailglow stops serving the domain until the record resolves again. Adding it back and clicking **Check DNS** restores service on the next successful check. A check that cannot reach your DNS provider at all does not count against these windows. Only a lookup that completes and finds the record missing or pointing somewhere else starts the clock. ## SSL Certificate Provisioning Once your domain is verified and routing is configured, Tailglow requests an SSL certificate. The certificate status can report: - **None**: No certificate has been requested yet (pre-verification). - **Provisioning**: Certificate provisioning is in progress after routing verification. - **Active**: The certificate is provisioned and your domain is ready for HTTPS traffic. - **Failed**: Certificate provisioning failed. Check the error message in your domain settings for details. Certificate provisioning often takes a few minutes, but it can take longer. Certificates renew automatically while the required DNS records continue to point directly to Tailglow. ## Traffic Purpose The table used to create a domain assigns its traffic purpose, and one hostname can serve only one purpose at a time. In **Domain Details**, the **Used for** chip shows the active purpose. An Ingest domain can be used as a first-party endpoint for sending analytics data. It keeps the ingest hostname under your domain and may reduce blocking by tools that specifically target known third-party analytics hosts. A Page domain serves every public page owned by the team. Each Page's permanent generated slug works on the Tailglow hostname and every custom hostname. A Page can also be given a readable path on one specific domain, such as `status.yourcompany.com/weekly-health`, and another Page domain can choose a different path for the same Page. Set that path to `/` to serve the Page at the hostname's root, so `status.yourcompany.com` opens it directly. Only one Page can hold a given path on a domain, including the root. Paths are a single segment: `/weekly-health` is valid, `/team/weekly-health` is not. Pages served from your own hostname remove Tailglow branding and use your team logo as the browser tab icon (favicon). You can update the logo in your team settings. To remove the active purpose without deleting the hostname, open **Domain Details** and click **Stop using for Ingest** or **Stop using for Pages**. Tailglow explains what the change affects and asks you to hold the confirm button, because the teardown cannot be cancelled once it starts. The change can take time to finish. ## Troubleshooting ### DNS Verification Failed If verification fails: - **Check DNS propagation**: Use a tool like [whatsmydns.net](https://www.whatsmydns.net) to verify your records have propagated. - **Verify record values**: Ensure the CNAME target exactly matches what Tailglow shows. - **Check for conflicting records**: Remove any conflicting A or AAAA records if using CNAME. - **Wait and retry**: Propagation time depends on your DNS provider and the record's TTL. ### Certificate Provisioning Stuck If certificate status shows "provisioning" for more than 24 hours: - **Verify DNS is correct**: Certificate provisioning requires DNS to be properly configured. - **Check for CAA records**: If you have CAA records, ensure they allow certificate issuance. - **Contact support**: If issues persist, reach out to support@tailglow.io. ### Domain Shows "Failed" If certificate provisioning failed: - Check the error message in your domain settings. - Verify DNS configuration is still correct. - Try removing and re-adding the domain. ## Removing a Custom Domain To remove a custom domain: 1. Navigate to **Team Settings** > **Domains**. 2. Click the edit button for the domain you want to remove. 3. Hold the trash button labeled **Hold to remove domain** until the action confirms. Removal can take time, and the row remains visible with a pending state until it finishes. Public Pages stop using the hostname as soon as removal begins, while other services may take longer. Do not rely on the hostname after starting removal. Adding it again later requires new ownership verification. ## Best Practices - **Use dedicated subdomains**: Hostnames such as `ingest.yourdomain.com` and `status.yourdomain.com` make each traffic purpose explicit. Page domains require a subdomain. - **Keep DNS records**: Don't remove DNS records after verification. They are re-checked hourly, and removing one eventually takes the domain out of service. See [Ongoing Checks](#ongoing-checks). - **Monitor certificate status**: Check your domain status periodically to ensure certificates remain active. - **Plan for propagation**: When adding new domains, allow time for DNS propagation before relying on them in production. # API Keys ## Overview API keys allow you to authenticate with the Tailglow API programmatically, without a user session. They are useful for backend integrations, CI/CD pipelines, and scripts that need to interact with Tailglow on behalf of your team. API keys are separate from **ingest keys**. Ingest keys are used to send data to your ingest servers, while API keys are used to interact with the Tailglow management API (e.g., creating projects, managing views, querying metrics). ## Creating an API Key To create a new API key: 1. Navigate to your **Team Settings**. 2. Select the **API Keys** tab. 3. Click the plus button labeled **Create an API key**. 4. Configure the following fields: - **Name**: A descriptive name for the key (2-60 characters). - **Quick fill**: Optionally start with **Common** or **Full access**, or click **Clear** to remove all selected scopes. - **Scopes**: Choose which permissions the key should have. You can only assign permissions that you yourself have. 5. Click **Create API Key**. The API key will be displayed once after creation. Copy and store it securely -- you will not be able to see it again. ## Using an API Key Include the API key in the `Authorization` header of your requests: ```bash curl -X GET "https://api.tailglow.io/v1/projects" \ -H "Authorization: Bearer tg_api_your_api_key" ``` ## Key Properties - **last4**: The last 4 characters of the key, for identification. - **scopes**: The permissions assigned to the key. ## Managing API Keys From the **API Keys** tab in your team settings, you can: - **View all keys**: See a list of all API keys with their names and last 4 characters. - **Update a key**: Change the name or scopes of an existing key. - **Delete a key**: Permanently revoke a key. This takes effect immediately. ## Security - API keys inherit the scopes you assign to them. Follow the principle of least privilege -- only grant the permissions the key needs. - Quick-fill choices only preselect scopes in the creation form. Review them before saving and remove any permission the integration does not need. - The available quick-fill choices are **Common** and **Full access**. **Clear** removes all scopes. - Unlike human roles, API keys do not require `projects:read`. A key may be limited to one narrow operation. - Rotate keys periodically by creating a new key, updating your integrations, and deleting the old one. - Never commit API keys to version control. Use environment variables or a secrets manager. # Billing ## Overview Billing in Tailglow is managed at the team level. Each team has a billing plan, payment methods, and access to invoices and credit notes. Billing settings are accessible from the **Team Settings** page under the **Billing** tab. ## Free server trial An eligible new account can start one server in its team's first project without a payment method. The three-day trial starts when that server first comes up, so time spent waiting for it to start does not count against the trial. Creating another project or team does not renew your account's trial. The trial grants the team **72 server-hours** of credit: one running server uses one server-hour each hour. Two servers share the same balance and use two server-hours each hour. Server-hours are shared across all projects on the team and stay available until spent. Tailglow staff can extend a trial; an extension adds the matching server-hours and brings back a trial server that was paused. ## Included allowances Every team has these allowances, whether or not it ran a trial: - **Tailglow AI tokens:** a new team starts with 10 million tokens for the Tailglow-provided model. Input, output and cached tokens count; reasoning tokens are included in output tokens, not counted twice. The balance resets each month once your latest invoice is paid, as described below. Your own provider keys are billed by that provider and do not use these tokens. - **5 GB-months of storage every month:** each monthly invoice includes the first 5 GB-months of storage on every plan. This is a usage allowance, not a 5 GB capacity limit: holding 5 GB for a full month uses 5 GB-months. Included storage that goes unused does not carry over. The **Free this month** card on the billing page shows how much of your included storage and Tailglow AI allowance you have used, including usage not yet invoiced. Reading it spends nothing: allowances are deducted when usage is invoiced, and the current estimate already includes them. Tailglow staff can refill your AI tokens to your plan's monthly allowance. ### Trial deadline and payment methods Without a payment method, the initial server pauses when the three-day trial ends. Billable server time stops at that deadline, even if infrastructure cleanup runs later. Adding a card after the deadline does not make that cleanup gap billable. You have seven more days to add a payment method and resume the paused server; after that, the server is removed. With a payment method, servers can keep running after the trial deadline and you can add capacity in any project. All running servers draw from the shared server-hour credit. Once it is spent, usage is charged at your team's normal rate. Manage Servers shows the selected monthly cost. If you have permission to read billing, it also estimates how much longer the team's available server credit will last at the selected server count. The server deadline and the credit balances are separate. The deadline controls when a cardless server pauses; it does not expire unused AI or server credits. For the Tailglow-provided model, Pro teams without a payment method need remaining AI credits before each model call. Calls already in progress may finish as credits run out; any excess is covered by Tailglow and will not appear as a later charge. Teams with a payment method, and Enterprise teams, keep using the model after their balance runs out: remaining credits are deducted when invoicing and further usage is billed on the next invoice. Your own provider key bypasses this allowance check entirely. ### Credits across billing months All server runtime is metered, and eligible promotional units are deducted centrally when the invoice is created. A trial crossing a month boundary shares one 72-server-hour balance across both months. Each month's credited hours use that month's prorated server rate. Estimates do not spend credits, and retrying an invoice does not spend them again. Included storage comes off first, then promotional credits, then other billing discounts. The invoice shows full metered usage, **Included storage**, a separate **Promotional credit**, any negotiated **Discount**, and the amount due. When your team's latest monthly invoice is paid, **Enterprise teams receive a reset to 100 million Tailglow AI tokens**, including teams that pay by invoice without a saved payment method. **Pro teams with a payment method receive a reset to 10 million tokens**. This is included, not a prepaid purchase or an additional charge. Unused AI credits, including higher balances, are replaced by the monthly allowance. Usage since the end of the invoiced month counts against it, so paying late never makes usage free. Paying an older invoice after a newer one is issued does not reset the balance, and paying the same invoice again does not reset it twice. Pro teams without a payment method keep their remaining tokens but receive no monthly reset. Select **Tailglow** in Chat to use these tokens. The information drawer in Agents settings shows current rates, including the 15% service fee. All teams share one saved Tailglow rate for each billing month. Customer price changes take effect in the next month, even if provider costs or the underlying model change sooner; invoices use the saved rate for the month of usage. Ordinary input, cached input, cache writes, and output are billed separately; reasoning is already included in output. Automatic managed conversation compaction is covered by Tailglow. ## Billing Settings To access billing: 1. Click your team name in the top toolbar. 2. Click the settings icon in the top-right corner. 3. Navigate to the **Billing** tab. From here you can manage: - **Billing Email**: Set a billing-specific email address for invoices and payment notifications. - **Billing Plan**: View your current billing plan. - **Billing Address**: Set your team's billing address for invoices. ## Estimated Invoice A card named for the current period lists each billable line with the usage behind it, and an **Estimated Total** row that sums them and shows the date the period is invoiced. Each amount reads as `$2.60 (Est $43.35)`. The first figure is what the line has accrued so far. The figure in brackets is what it becomes by the time the invoice is issued, assuming the month carries on as it has been: - **Storage** keeps the data you are holding now and keeps growing at the rate measured over the last two weeks. A line with no recent growth is carried forward flat, and deleting data never projects the bill downward. - **Compute** keeps the servers that are running today running for the rest of the period. Scaling up or down moves this figure immediately. - **AI tokens** continue at the rate used so far this period. In the first day of a period there is not enough usage to project from, so the line reports what it has. - **Subscription** shows a single figure. It is committed for the whole period, so there is nothing to project. Three things to know when reading it: - The bracketed figure is a forecast, not a measurement. It assumes today's usage continues, so it moves whenever your storage or servers change. The figure on the left is the only one that is a fact. - Usage is measured from the hours it was actually held, which is why storage is billed in GB-months rather than the gigabytes you are storing right now. Two days of storage in a thirty day month bills for two days. - Both figures are shown before tax. Any applicable tax is calculated when the invoice is issued, so a team in a taxable jurisdiction pays more than the estimate shows. ### Billing through the API `GET /v1/teams/:team_id/billing` returns the current billing period, accrued and projected charges, server usage, the server-hour and AI credit balances, and your included storage. Every response has the same fields. It requires `billing:read` and credentials scoped to that team. The response has `object: "billing"`. Its totals show accrued charges. `projected_line_items`, `projected_subtotal_cents`, `projected_discount_cents`, and `projected_total_cents` estimate this period's invoice. The `promo_*` fields report the stored balances after the last invoice. The `available_promo_*` fields subtract accrued, uninvoiced usage. Use the available balances when showing how much credit is left to use. `included_storage_gb_months` is your plan's monthly storage allowance and `available_included_storage_gb_months` is what this month has not used yet. `calculated_at` identifies the snapshot time; `uninvoiced_server_hours` can include the preceding month until its invoice is saved. Reading the summary never creates an invoice or deducts credits. ## Payment Methods You can add and manage payment methods from the billing settings. ### Adding a Payment Method 1. Click the plus button in the **Payment Methods** card. 2. In **Add New Payment Method**, enter the cardholder name, card details, and billing address. 3. Click **Add Payment Method**. The first payment method added becomes the default. You can change the default at any time. ### Managing Payment Methods - **Set as default**: Open the payment method's actions menu and select **Set As Default**. - **Delete**: Open the actions menu and select **Delete Payment Method**. You cannot delete the last payment method on a team, regardless of its plan. ## Invoices The **Invoices** card shows each invoice's number, period end date, total, and status. Use the link button to open an available hosted invoice in a new tab. ## Credit Notes Credits are granted by Tailglow staff and applied automatically when an invoice is paid, so no action is needed to redeem one. They are not deducted from the estimate, which reports usage rather than what is left to pay. Contact support to check a balance. ## Discounts Active discounts are applied automatically when each invoice is calculated. ## Billing Activity The **Billing activity** card lists what changed your team's billing over the last 90 days: invoices being issued, paid, failing or voided, payment methods being added, changed or removed, plan changes, the free trial starting, being extended, pausing and ending, Tailglow AI resets and refills, discounts, and ingestion being paused or resumed for an unpaid invoice. Each entry shows who made the change. **Tailglow** marks changes made automatically, such as a payment arriving from your card, and **Tailglow Admin** marks changes made by Tailglow staff. It appears once there is activity to show. Anyone with billing read access can see this list, and it is available through `GET /v1/logs?type=billing`. Your invoices and receipts remain the permanent record of what you paid. ## Account Status and Billing Your team's billing status directly affects your account: - **Active**: Everything is working normally. - **Delinquent**: Tailglow emails your billing contact after a failed payment. A non-Enterprise team can become delinquent if an invoice becomes uncollectible or remains unpaid into a later billing cycle. Ingestion is paused until every unpaid invoice is paid or voided, and then resumes automatically. - **Restricted**: Project and team resources are read-only, and ingestion is paused. Billing and payment-method updates remain available so an Owner can resolve the issue, but payment methods cannot be deleted while the team is restricted. See the [Teams](/guides/teams) guide for more details on team statuses. # Chat ## Overview Chat is an AI assistant built into Tailglow. Ask questions about your metrics, views, collections, and records in natural language, across any project on your team. Chat uses your account's permissions for supported Tailglow actions, so it can only see and change what you can. ## Getting started **Tailglow** uses AI managed by Tailglow. When several models are available, use the model picker to choose one. Click the model and effort label to change your selection. When only one model is available, this opens its effort choices directly. Free tokens are shared across your team and its projects. They apply first, then usage is billed to the team if it has a payment method or is on the Enterprise plan. To use your own provider account, add an Anthropic or OpenAI key in **Team Settings > Agents**, then select that provider's model in Chat. Adding or deleting a key does not switch an existing conversation's payer. If its selected model becomes unavailable, choose another model explicitly. A new chat opens on your saved model when it's available; otherwise it opens on Tailglow or another model you can use, and your saved choice returns once it's available again. The **Tailglow** name stays the same when the underlying model changes. Open the information drawer in Agents settings, or click the free-token balance beside the chat picker, to see the current provider, model, supported token rates, and balance. The displayed rates include a 15% service fee; no additional service fee is added afterward. Every new team starts with 10 million Tailglow AI tokens. When your team's latest monthly invoice is paid, **Enterprise teams receive a reset to 100 million tokens**, including teams that pay by invoice without a saved payment method. **Pro teams with a payment method receive a reset to 10 million tokens**. This is included, not a prepaid purchase or an additional charge. Unused AI credits, including higher balances, are replaced by the monthly allowance. Usage since the end of the invoiced month counts against it. Pro teams without a payment method keep their remaining tokens but receive no monthly reset. Chat history remains accessible when sending needs action. Without a model, or without enough credits on a Pro team with no payment method, the composer explains what to change. Your draft is kept. Provider-key models do not spend Tailglow credits. Teams with a payment method, and Enterprise teams, can continue after their free balance reaches zero; that usage is billed. ## Using Chat Open Chat with **Command + /** or the chat icon. It is available on every page: inside a project, and on team pages such as billing, users, and roles. 1. Open Chat. 2. Type a question and press Enter. Chat reads the page you are on, so a question about "this view" or "this metric" means the one in front of you. If you move to a different project mid-conversation, Chat notices and keeps going. When that makes a request ambiguous, it asks rather than guessing. Responses stream as they are generated. You can attach images to a message. ### Example questions - "What are the top 5 endpoints by error rate this week?" - "Show me the trend of page views over the last 30 days." - "Why did latency spike yesterday at 3pm?" - "Create the same metric in my sandbox project." - "Which roles can delete metrics?" ## Chat history Open the chat panel and switch to the chat list to revisit previous conversations. Your chats follow you between projects, so the list is the same wherever you open it. The assistant keeps useful notes as it works. For long managed conversations, it also summarizes older work near a 250,000-token context target. Recent exchanges, complete tool calls and results, and your current request remain available alongside that summary. The full transcript remains in your chat history. Compaction runs between model calls. If a summary fails, the assistant retains the original context and uses additional headroom toward a 400,000-token operating limit, subject to the provider's capacity. It tries to reduce older context before asking you to shorten an unusually large request. Automatic managed compaction is covered by Tailglow and does not spend your free tokens. Token billing uses the provider's reported usage for every generation, including tool continuations. Input, cached input, cache writes, and output are separate categories; reasoning is already included in output. An estimate used to fit context is never used to calculate your bill. Stopping a response can leave a provider generation finishing in the background; its reported usage still counts. If usage cannot be recovered, the unknown remainder is covered by Tailglow, while the answer already received remains available. ## Managing chats Deleting a chat removes it from your chat list. Its messages may be retained for billing records. Chats are scoped to your user account within a team. Other team members cannot see them. ## Permissions Chat access is controlled by the **Chats** permission in your role. Read access opens chat history, write access sends messages, and delete access removes chats. # Checks A check fetches an endpoint on a schedule and records whether it answered. It is the fastest thing in Tailglow to set up, and the only one that needs nothing else to exist first: give it a URL and you have real data within a minute, without instrumenting anything or sending us a single event. Use a check when you want to know that something is up. Use a [pull](/guides/pulls) when you want what the endpoint returns. ## Set up a check Pick a source for the results to land in, name the check, and give it the HTTPS URL to watch. Everything else has a working default. **Schedule** decides how often it runs, down to once a minute. **Collection** decides where the results land inside the source, and you name it yourself, because which collection a check writes to is the thing that decides what it charts alongside. Point several checks at the same collection and they chart together: one strip per check, with an overall row above them taking the worst result of any check in each bucket. That is a status page. Give each check its own collection to keep them apart. **Test check** on the Activity tab fetches the endpoint once, right now, and tells you what came back. It stores nothing, so use it freely while you get the configuration right. ## What gets recorded Every run writes exactly one row, whether it succeeded or not: | Field | Meaning | | ------------------ | -------------------------------------------------------------------- | | `check_id` | Which check ran | | `checked_at` | The scheduled time of the run, not the moment the row was written | | `up` | `1` when the endpoint answered with a 2xx, `0` when it did not | | `http_status` | The status it answered with, or `0` when nothing answered | | `response_time_ms` | How long the request took | | `error_stage` | `request` when nothing answered, `response` when it answered wrongly | | `error_message` | What went wrong | | `attempts` | `2` when a failure was confirmed by a second check | Because `up` is a number, the average of `up` across a period is the uptime for that period, as a fraction between 0 and 1. A view that multiplies it by 100 first reads as a percentage instead, which is the form thresholds are written in: the Colors tab's uptime preset expects `99` and `99.9`, not `0.99` and `0.999`. Views built by setup carry that field already, as `uptime_percent`. A run that was never dispatched writes no row at all. Tailglow did not ask the endpoint anything, so it makes no claim about whether it was up, and the gap renders as no data rather than as downtime. ## Confirming failures **Confirm failures after** waits the given number of seconds and checks once more before recording a failure. A single refused connection is a flake as often as an outage, and without this one blip becomes a red cell on your chart. When the second attempt succeeds, the run is recorded as up. ## Charting uptime 1. Create a view over the checks collection. 2. Create a metric on that view: display value **Average**, over the `up` field. Group by `check_id` if several checks share the collection. 3. Set the chart type to **Uptime**, colour mode **By value**, and use the uptime preset in the Colors tab. Rules are read worst-first, so red comes before amber before green. 4. Add a monitor with a **sustained** condition if you want an alert. The chart shows every bucket; the monitor decides what counts as an outage worth waking someone for. ## A check never stops itself This is the difference between a check and a pull. A pull that has been failing for 72 hours is switched off, because a collector with nothing to collect is only wasting requests. A check keeps going for as long as the outage lasts, because documenting that outage is the entire job. Your chart stays honest through the worst week you have. A check stops only when you pause it. ## Limits Each request times out after 20 seconds, and a confirmation attempt after 10. A POST request body is capped at 4 KB. ## Security Endpoints must be public HTTPS addresses. Tailglow re-validates the address on every single run, not just when you save the check, and rejects private, loopback and link-local targets. That re-validation is what stops a hostname that resolved publicly at save time from being repointed at an internal address later. Headers are stored encrypted and never returned. Responses list only the header names you configured. # CLI `tglow` is the Tailglow command line. Every endpoint in the [API reference](/api) is a command, because both are generated from the same source: the API's own routes and validations. A new endpoint becomes a new command with no separate release, and the CLI cannot describe an API that does not exist. It is built for two readers at once. In a terminal it prints tables and asks before deleting. Piped, redirected, or run by an agent, it emits JSON and never prompts. ## Installation ```bash npm install -g @tailglow/cli ``` Node 18.3 or newer. `bun add -g @tailglow/cli` and `pnpm add -g @tailglow/cli` work the same way. Verify it: ```bash tglow --version ``` Prefer a shorter name? Alias it rather than installing over one, since `tg` belongs to other tools on many systems: ```bash alias tg=tglow ``` ## Authenticating Authentication is an API key. Create one in the dashboard under **Team settings**, then store it once: ```bash tglow config set api_key tg_api_... ``` That writes `~/.tailglow/config.json`, readable only by you. A stored key is never printed back. Three ways to supply it, in the order they win: | Source | Use it for | | -------------------------- | -------------------------------------------- | | `--api-key ` | A single call. Visible in your shell history | | `TAILGLOW_API_KEY` | CI, containers, and anything scripted | | `tglow config set api_key` | Your own machine | In CI, prefer the environment variable. A key passed as a flag appears in the process list. ## Getting around The shape is always the same: ```bash tglow [flags] ``` Three levels of help, and between them they are the whole manual: ```bash tglow # every resource, and the flags that apply everywhere tglow drains # every command on drains tglow drains create --help # every flag, its type, and its accepted values ``` Command help is generated from the same validations the API enforces, so a required field is required here for the same reason it is required there. ## Working with a project Most commands act on a project. Set it once instead of repeating it: ```bash tglow config set project prj_... tglow metrics list ``` `--project` overrides the stored default for a single call. Every other id has to be named explicitly: only `project` and `team` fall back to configuration, so nothing in your environment can quietly become the target of a delete. ## Flags Field names are snake_case in the API and kebab-case on the command line: `time_window_minutes` becomes `--time-window-minutes`. Path parameters are flags too, never positional. ```bash tglow sources create --project prj_x --name "Web events" # a string tglow pages create --project prj_x --name Status --is-public # true tglow pages create --project prj_x --name Status --is-public=false tglow metrics create --project prj_x --group-by user_id,country # a list tglow views create-join --project prj_x --joins '[{"view_id":"view_b","on":"user_id"}]' ``` A boolean is passed alone for true, or written attached for false. Anything typed `object`, `object[]`, or `Scopes` takes JSON as a single argument. ## Output A terminal gets a table. Everything else gets JSON, so `| jq` needs no flag: ```bash tglow projects list | jq -r '.data[].name' ``` JSON is the API's response as it was sent, envelope included: read `.data` for results and `.pagination.next_cursor` to continue. `--json` forces it when you want JSON in a terminal. Failures go to stderr and follow the same mode, so a pipeline reading stdout never has to tell a result apart from an explanation of why there is none. ## Long lists List commands paginate. `--all` follows the cursor until the results run out or `--max` is reached: ```bash tglow metrics list --project prj_x --all --max 500 ``` The cap defaults to 10,000 and exists because records and collection documents are unbounded. A run that stops early prints the exact command to continue with. Under `--json`, `--all` returns `{ data, truncated, next_cursor }` instead, so a caller can resume on its own with `--after`. `--all` owns paging, so it does not combine with `--limit` or `--before`. Use `--limit` on its own to size a single page. ## Deleting In a terminal, a delete asks first. `--yes` skips the question. **Without a terminal, a delete runs immediately and is never confirmed.** That is deliberate, so scripts and agents are not blocked on a question they cannot answer, but it means a delete in CI happens the moment it is called. Most resources delete softly: the response tells you when permanent removal happens. ## Scripting it The CLI is designed to be driven by other programs, including AI agents: ```bash export TAILGLOW_API_KEY=tg_api_... tglow metrics create --help --json # the full contract for one command, as data ``` `--help --json` returns the command's flags, types, requiredness, accepted values, and the syntax for each one. An agent can read that and construct a valid call without any other documentation. # Webhook drains A drain sends collection or view records to an external HTTPS endpoint. You can choose the body format, compression, headers, and whether to include existing records. A project can have up to 10 drains. ## Set up a drain 1. Open project **Settings**, then **Drains**. 2. Click the plus button. The drawer is titled **New drain**. 3. Select a collection or view, then provide a name, destination URL, optional headers, body format, compression, delivery schedule, and whether to backfill historical data. 4. Create the drain. 5. In **Details**, click **Send verification**. Find the `tailglow_verify` value at your endpoint and paste it back. 6. The verified drain is paused. Use **Send sample** on its Activity tab if useful, then click **Resume** to begin delivery. A sample sends the latest five eligible records with `X-Tailglow-Test: true`. It does not advance the drain cursor. ## Schedule Choose how often the drain looks for new records: every minute, every 5 or 15 minutes, hourly, daily, or a custom cron expression. Schedules are evaluated in UTC, and new drains default to hourly. You can change the schedule at any time. The schedule sets how quickly new records are picked up, not how fast a backlog clears. A drain that has fallen behind keeps sending until it catches up instead of waiting for its next run, so a large backfill is never limited by the schedule you choose. A run that finds nothing to send makes no request, so a fast schedule adds no traffic to a quiet endpoint. It does change the shape of steady traffic: a drain receiving around 10 records a minute sends roughly 1,440 small requests a day on a per-minute schedule, against 24 larger ones on an hourly schedule. Choose whichever suits your destination. ## Batches and retries Each delivery contains at most 5,000 records and at most 5 MiB of uncompressed serialized data, except that a single oversize record is sent on its own. `X-Tailglow-Batch-Id` is stable for retries of the same batch, so receivers should use it as an idempotency key. The cursor advances only after a successful 2xx response. Tailglow retries failures, warns team owners after six hours of continuous failure, and disables the drain after 72 hours. Resume it yourself once the destination is reachable again. ## Backfill With **Backfill historical data** off, the drain starts from records arriving after its first activation. With it on, the drain catches up existing records before continuing with new ones. This choice cannot be changed after creation. ## Draining to Tailglow Point a drain at the destination project's copied ingest endpoint and provide a destination ingest key. A trusted destination in the same project can skip marker verification, but two projects owned by the same team do not automatically verify each other. For a non-trusted destination, find the verification marker in the destination collection's **Records** tab and confirm it in the drain drawer. ## Security Destinations must be public HTTPS addresses. Tailglow revalidates outbound addresses, rejects private and loopback targets, and times out each request after 30 seconds. # Notifications Tailglow emails subscribed users when monitor alerts open. For spanning alerts, it also sends a notification when the alert recovers. ## Manage subscriptions Open **Profile** then **Notifications**. The **Auto-subscribe to new monitors** switch subscribes you to monitors created in teams where you are a member. Use the activity button to open **Update Monitor Subscriptions** and choose individual monitors across your teams. The switch next to a monitor in its metric's monitor drawer changes whether the monitor is active for everyone. Manage your own email subscriptions from **Profile** > **Notifications**. ## Alert behavior When a monitor condition becomes true, Tailglow opens an alert and emails subscribed users. A spanning alert stays open until the condition clears and then sends a recovery notification. An instant alert opens and ends in the same evaluation. # Pulls A pull fetches an HTTPS endpoint on a schedule and stores what comes back in a source. It is the inbound counterpart to a drain: instead of you sending records to Tailglow, Tailglow goes and gets them. Use it for anything that already exposes its data over HTTP, such as a status endpoint, a JSON API, or a Prometheus metrics endpoint. ## Set up a pull 1. Open project **Settings**, then **Pulls**. 2. Click the plus button and pick the source the records land in. 3. Give the pull a name and the endpoint URL. The URL must be HTTPS and resolve to a public address. 4. Choose the method. **GET** suits most endpoints; **POST** is for endpoints that answer queries, such as GraphQL, and lets you supply a request body. 5. Add any headers the endpoint needs to authenticate you. 6. Choose a schedule. 7. Create the pull. It starts fetching straight away. There is no verification handshake. A pull only reads from an endpoint you name, so there is nothing to prove to the far side. ## Headers Header values are write-only. Tailglow encrypts them and never returns them, so the drawer lists the names you configured and shows the values as dots. To change one, add it again with the same name and the new value replaces it. To remove one, delete the row and save. A pull sends at most 20 headers. Headers Tailglow sets itself, such as `Content-Type`, cannot be overridden. ## Schedule Choose how often the endpoint is fetched: every minute, every 5 or 15 minutes, hourly, daily, or a custom cron expression. Schedules are evaluated in UTC and new pulls default to every minute, which is also the shortest supported gap. Each run collects whatever the endpoint returns at that moment. A run that is missed, because the endpoint was slow or the schedule was paused, is not replayed later: the sample would carry the time it was collected rather than the time it was meant for, which would be worse than the gap. ## What gets stored By default the whole response body becomes one record. If the endpoint wraps its rows in a key, set **Records path** to that key and each element becomes its own record. `data` reads the top-level `data` array, and `data.result` walks two levels down. This is the difference between one record an hour containing five hundred rows, and five hundred records you can query. Records land in a collection inside the source. Leave **Collection** empty and Tailglow names one after the pull. ## Watching an endpoint's availability A pull tells you nothing about the runs that failed, because a failed run has nothing to store. It also stops after 72 hours of continuous failure: a collector that has been failing for three days has nothing left to collect. That makes a pull the wrong tool for uptime. Create a [check](/guides/checks) instead. A check needs nothing but a URL, records one row per run whether the endpoint answered or not, and never stops itself because the endpoint is down, which is exactly the window you want a record of. If you want both the data and the availability, create both against the same URL. ## Prometheus endpoints Pulls understand both Prometheus formats, and detect which one they received rather than asking you to declare it. **Metrics endpoints.** A response in Prometheus text exposition format is parsed into one record per sample, with the metric name, labels, value and timestamp broken out as fields. You do not need a records path. **Service discovery.** If the endpoint returns an HTTP service discovery document, the pull treats it as a list of other endpoints and fetches each of them. One scheduled run becomes one request to the discovery endpoint plus one request per target it names, and every sample is stored with the labels the discovery document attached to its target. Two limits apply to discovery. A pull follows at most 1,000 targets, and the discovery document itself must be under 8 MB. Both refuse rather than truncate: a pull that quietly followed the first 1,000 of 4,000 targets would leave you with a metric that looks complete and is not. If you hit either, narrow what the discovery endpoint returns. Your headers are sent to the discovery endpoint and to targets on the same origin. Targets on a different origin are fetched without them, so a token meant for one host is never handed to another. ## Testing and activity **Test pull** on the Activity tab fetches the endpoint once, right now, and reports what happened: how many records came back, how long it took, and where it failed if it did. It does not store anything, so you can use it freely while you get the configuration right. A test that meets a discovery document follows at most five targets, enough to prove the shape without waiting for the full fan-out. When a run fails, the pull records which step it failed at: | Step | Meaning | | ---------- | ----------------------------------------------------------------------- | | `request` | The endpoint could not be reached, refused the connection, or timed out | | `response` | It answered with an error status, or a body too large to accept | | `parse` | The body arrived but could not be read as JSON or Prometheus text | | `ingest` | The records were read but could not be stored | The Activity tab also shows the last 24 hours of volume, the most recent error, and how many runs have failed in a row. ## When something goes wrong A failing pull keeps retrying on its schedule. Tailglow disables it after 72 hours of continuous failure and emails the team owners. Fix the endpoint and click **Resume**. Pausing is yours and disabling is ours. A pull you paused stays paused until you resume it, and Tailglow never restarts it on your behalf. A pull Tailglow disabled says so, and resuming it is a deliberate act once the cause is fixed. ## Limits Each request times out after 20 seconds. A response must fit the ingest payload limit, and a POST request body is capped at 4 KB. A pull follows at most 1,000 discovery targets, and a discovery document must be under 8 MB. ## Security Endpoints must be public HTTPS addresses. Tailglow re-validates the address on every single fetch, not just when you save the pull, and rejects private, loopback and link-local targets. That re-validation is what stops a hostname that resolved publicly at save time from being repointed at an internal address later. # Quickstart Get a web app sending data to Tailglow. This is the typical setup: a browser app that auto-collects page views, marked-section engagement and clicks, outbound clicks, uncaught errors, and performance measurements, with your own custom events on top. You need one value: the **ingest URL** from the source's **Ingest** tab, which already carries its key (for example `https://us11.ingest.tailglow.io/prj_xxx?key=tg_ingest_your_key`). The [Ingest Key](/guides/ingest-key) guide shows how to reach it. Copying the key on its own and passing it separately still works, and a key passed that way overrides one carried in the URL. ## Add the SDK Choose one. Both do exactly the same thing; use the drop-in tag if you do not have a build step. ### Drop-in script Paste one tag into your ``. It self-initializes and starts collecting immediately, no build step: ```html ``` ### npm ```bash bun add @tailglow/browser # or: npm install @tailglow/browser ``` ```javascript import { Tailglow } from "@tailglow/browser"; const tg = new Tailglow({ url: "https://us11.ingest.tailglow.io/prj_xxx?key=tg_ingest_your_key" }); ``` Either way, auto-collection starts the moment the SDK loads: page views, engagement and clicks inside elements marked with `data-telemetry`, outbound-link clicks, uncaught errors, performance measurements, and a one-time device snapshot. The default path is cookieless and does not read or write persistent browser storage. Assess consent and disclosure requirements for the data you collect and the jurisdictions where you operate. ## Track your own events Send anything meaningful in your product. The first argument is the event name, the second is any properties you want to attach: ```javascript tg.track("signup", { plan: "pro" }); tg.track("purchase", { amount: 99, currency: "USD" }); ``` With the drop-in tag, call the global `tglow` the same way: ```javascript tglow("track", "signup", { plan: "pro" }); ``` Or track clicks straight from your markup, no JavaScript: ```html ``` ## Identify the signed-in user When your app knows who the user is (from your own auth), attach their ID. Events already queued earlier in the session are backfilled with it: ```javascript tg.identify("user_123"); ``` ## See it on localhost By default the SDK skips `localhost` so dev traffic does not pollute your analytics. To watch events flow while developing, opt in and tag them as dev so you can filter them out later: ```javascript const tg = new Tailglow({ url: "https://us11.ingest.tailglow.io/prj_xxx", key: "tg_ingest_your_key", excludeLocalhost: false, context: { environment: "development" } }); ``` Trigger a page view or a `track()` call, then confirm the records land in your project. ## Next steps - **[JavaScript SDK](/guides/sdk)**: the full reference, covering error capture, identity, context, configuration, and record shapes. - **Backend, Electron, and React Native**: the same core runs server-side and in native apps. See [Runtimes](/guides/sdk#runtimes) in the SDK guide. # Secrets Secrets store sensitive credentials for Tailglow features that need them. Each secret belongs to you within the selected team, so teammates cannot view or use it. ## Add an AI provider key 1. Open **Team Settings**. 2. Select **Agents**. 3. Choose **OpenAI** or **Anthropic** and add your API key. 4. Save the key. After saving, Tailglow hides the full value and shows only its last four characters for identification. ## Manage secrets From **Team Settings** > **Agents**, you can view a key's label, provider, and last four characters, change its label, or delete it. Chat uses your saved key when you select that provider's model. Selecting **Tailglow** uses managed access and the team's credits even when your own key is connected. Deleting a key does not silently switch billing to Tailglow; choose another available model to continue. ## Keep secrets safe Secret values are encrypted before storage and are never returned after creation. If a credential may have been exposed, delete the secret, rotate the credential with its provider, and add the new value. # TGL: Overview ## What is TGL? TGL (Tailglow Query Language) is the small scripting language used inside views to transform data one record at a time. A view can read records from a collection or from another view. For each input record, the TGL script reads fields from `$row`, builds an output object in `$out`, and either emits one record or drops the input. You don't have to write TGL by hand. When you create a view, Tailglow generates a script for you using the output schema (and any optional hint you provide). But once it's generated, you can edit it, and a lot of useful patterns like filtering rows, computing totals, and deriving fields only need a few lines of TGL. ## Hello world ```tgl $out.id = $row.id $out.name = upperCase($row.name) ``` That's a complete, valid TGL script. For each input record, it copies the `id` field through and uppercases the `name`. The view this powers will have one record out for every valid input record. ## How a TGL script runs Every input record follows the same steps: 1. Make the input available as `$row`. 2. Run the TGL script and build `$out`. 3. If the script sets `$out = null`, drop the input record. 4. Otherwise, add `$out` to the view. A successful input produces at most one output record. Invalid rows and rows that exceed a safety limit are skipped; a structurally invalid output can fail the transform. See [Recipes](/guides/tgl/recipes) for error handling and limits. ## What's on each page This guide is split into focused sections. Read in order if you're new, or jump to whatever you need: - **[Syntax](/guides/tgl/syntax)**: variables, statements, comments, what `$row`, `$meta`, and `$out` mean. - **[Control flow](/guides/tgl/control-flow)**: filtering rows, conditionals (`#if`/`#elseif`/`#else`/`/if`), loops (`#each`). - **[Operators](/guides/tgl/operators)**: comparison, logical, nullish coalescing, plus type semantics and null propagation. - **[Functions](/guides/tgl/functions)**: every built-in function (math, string, array, type, date) with examples and null-handling notes. - **[Recipes](/guides/tgl/recipes)**: common patterns, plus the limits, validation, and error model. ## Where else TGL shows up - **[Views](/guides/records)** for how transforms fit into the view pipeline. - **API reference**: - Create View Transform - Update View Transform - Generate TGL with AI # TGL: Control flow TGL has three control-flow primitives: filtering a row out of the output, branching with `#if`, and looping with `#each`. All use Svelte-style directives (no curly braces). ## Filtering: drop a row from the output If you assign `null` to `$out` (the whole thing, not a field), the row is dropped from the output entirely: ```tgl // drop test users #if startsWith($row.user_id, "internal_") $out = null /if $out.user_id = $row.user_id $out.event = $row.event ``` When a row is dropped, no output record is emitted. The view simply has fewer records than the source. This is the only way to filter rows. Everything else (writing to `$out` fields conditionally, etc.) still emits a record, just with different content. A few notes on the rule: - The skip is **sticky**: once `$out = null` runs, later writes have no effect. Use `#if`/`#else` if you want to choose between drop and emit. - Expressions that evaluate to `null` also drop. So `$out = $row.payload` drops the row whenever `payload` is `null` (and merges the payload into `$out` otherwise). - Other primitive assignments (`$out = ""`, `$out = 42`, `$out = false`) are no-ops, **not** drops. They leave `$out` unchanged. - `$out.field = null` writes a `null` field. It doesn't drop the row. ## Conditionals `#if` / `#elseif` / `#else` / `/if`: ```tgl #if $row.score > 90 $out.grade = "A" #elseif $row.score > 75 $out.grade = "B" #elseif $row.score > 60 $out.grade = "C" #else $out.grade = "F" /if ``` The condition can be any expression. TGL uses standard truthiness: `null`, `undefined`, `0`, `""`, `false`, and `NaN` are falsy; everything else is truthy. Conditionals can be nested freely: ```tgl #if $row.user #if !isEmpty($row.user.email) $out.email = lowerCase($row.user.email) /if /if ``` There's no inline ternary (`a ? b : c`). Use `#if`/`#else` for branching values, or `??` for null-coalescing defaults (covered in [Operators](/guides/tgl/operators)). ## Loops `#each ... as $item / /each`: ```tgl $out.total = 0 #each $row.line_items as $item $out.total = add($out.total, multiply($item.price, $item.qty)) /each ``` Note the accumulator pattern: the script initializes `$out.total` to `0`, then the loop builds up the sum. `add` also treats a missing or `null` operand as `0`, so `$out.total = add($out.total, value)` works even without the explicit initialization. You can also bind an index: ```tgl #each $row.tags as $tag, $idx $out.tags = push($out.tags, lowerCase($tag)) /each ``` `$tag` is each element; `$idx` is the 0-based position. If the collection isn't an array (it's `null`, an object, or a string), the loop body is silently skipped. That loop expression does not throw merely because it resolves to a different type. There's a hard cap on total loop iterations per record (the default is 1,000,000) to prevent runaway scripts. Hit it and the row produces an error and is skipped; the rest of the records continue processing normally. ## What's next - **[Operators](/guides/tgl/operators)**: comparison, logical, `??`, type semantics. - **[Functions](/guides/tgl/functions)**: every built-in. - **[Recipes](/guides/tgl/recipes)**: real-world patterns combining filtering, branching, and looping. # TGL: Functions Built-in functions are the only callable functions in TGL. They do not mutate your input or output. Most return `null` for a wrong type or a missing value, while predicates such as `isEmpty` and `isValidDate` return a boolean and `typeOf` always returns a type name. `now()` is intentionally time-dependent, so it returns a different value as time advances. There are five categories: math, string, array, type, and date. ## Math | Function | Returns | | --------------------- | ----------------------------------------- | | `add(a, b, ...)` | sum of all arguments (variadic) | | `subtract(a, b)` | a minus b | | `multiply(a, b, ...)` | product of all arguments (variadic) | | `divide(a, b)` | a divided by b (returns `null` if b is 0) | | `mod(a, b)` | a modulo b (returns `null` if b is 0) | | `abs(n)` | absolute value | | `round(n, decimals?)` | rounds to N decimals (default 0) | | `floor(n)` | rounds down | | `ceil(n)` | rounds up | | `min(a, b, ...)` | smallest argument (variadic) | | `max(a, b, ...)` | largest argument (variadic) | ```tgl $out.tax = round(multiply($row.subtotal, 0.0825), 2) $out.bucket = floor(divide($row.age, 10)) $out.peak = max($row.q1, $row.q2, $row.q3, $row.q4) ``` ### Null handling in math `add` and `subtract` treat `null` as `0` so accumulator patterns work: ```tgl $out.sum = 0 #each $row.values as $v $out.sum = add($out.sum, $v) // null v contributes 0, doesn't break the chain /each ``` `multiply`, `divide`, `mod` short-circuit on `null`. If any argument is `null`, the result is `null`. This catches "missing field" cases loudly instead of silently making everything zero. ## String | Function | Returns | | ------------------------------------ | ------------------------------------------ | | `lowerCase(s)` | lowercased string | | `upperCase(s)` | uppercased string | | `trim(s)` | whitespace stripped from both ends | | `trimStart(s)` | leading whitespace stripped | | `trimEnd(s)` | trailing whitespace stripped | | `concat(...)` | joins arguments into one string (variadic) | | `length(s_or_array)` | character or element count | | `contains(s, search)` | true if `s` contains `search` | | `startsWith(s, prefix)` | true if `s` starts with `prefix` | | `endsWith(s, suffix)` | true if `s` ends with `suffix` | | `substring(s, start, end?)` | slice (negative indices count from end) | | `split(s, delimiter, limit?)` | array of pieces | | `replace(s, search, replacement)` | replaces first occurrence | | `replaceAll(s, search, replacement)` | replaces every occurrence | ```tgl $out.email = lowerCase(trim($row.email)) $out.full_name = concat($row.first, " ", $row.last) $out.domain = split($row.email, "@")[1] $out.is_gmail = endsWith($row.email, "@gmail.com") ``` `concat` is variadic and converts numbers/booleans to their string form: `concat("Hello, ", $row.name, "! You have ", $row.count, " messages")` works directly. If any argument is `null`, the whole result is `null`. Handle missing values with `??` first. `length` is grapheme-aware on strings: `length("👋")` is `1`, not `2`. It also works on arrays. ## Array | Function | Returns | | ------------------------ | ---------------------------------------- | | `includes(array, value)` | true if array contains value | | `push(array, value)` | new array with value appended | | `prepend(array, value)` | new array with value prepended | | `merge(arr1, arr2, ...)` | concatenates arrays | | `flat(array, depth?)` | flattens nested arrays (default depth 1) | | `unique(array)` | removes duplicate primitives | | `join(array, separator)` | joins into a string | Arrays in TGL are immutable from the script's perspective. `push` doesn't mutate the source, it returns a new array. That means the accumulator pattern looks like: ```tgl $out.tags = null #each $row.raw_tags as $t $out.tags = push($out.tags, lowerCase($t)) /each ``` `push(null, x)` returns `[x]`, so the loop builds up an array starting from null without needing a separate initialization. There are no array literals (`[1, 2, 3]`). Build arrays via `push`/`prepend` or read them off `$row`. ## Type | Function | Returns | | ---------------- | -------------------------------------------------------------------------- | | `int(value)` | parsed integer (truncates), `null` if not parseable | | `float(value)` | parsed float, `null` if not parseable | | `string(value)` | string form of a primitive, `null` for objects/arrays | | `bool(value)` | true / false / null (only for explicit boolean-like values) | | `typeOf(value)` | "string" / "number" / "boolean" / "null" / "array" / "object" | | `isEmpty(value)` | true if value is `null`, `undefined`, `""`, whitespace-only, `[]`, or `{}` | The most common use is **numeric coercion** for CSV-ingested data, where everything arrives as a string: ```tgl $out.total = add(int($row["Quantity"]), int($row["Bonus"])) $out.price = float($row["Price"]) ``` `add(string, number)` returns `null` because `add` is strict about types. `int($row["Quantity"])` parses `"42"` into `42`, then `add` works. `bool` is strict: it accepts `true`/`false`, `1`/`0`, and `"true"`/`"false"` (case-insensitive). It does NOT treat truthiness loosely: `bool(2)` is `null`, `bool("yes")` is `null`, `bool("")` is `null`. Use `!!$row.value` if you want truthiness; use `bool` when the source is a real boolean encoded in another type. `isEmpty` is the platform's shared definition of "missing"; useful for branching on optional fields. Unlike `??`, which only catches `null` and `undefined`, `isEmpty` also treats empty strings, whitespace-only strings, empty arrays, and empty objects as missing. Real values like `0`, `false`, and `"0"` are NOT empty: ```tgl // normalize missing-shaped values to null in view output #if isEmpty($row.secondary_type) $out.secondary_type = null #else $out.secondary_type = $row.secondary_type /if ``` ## Date Date functions emit **milliseconds since epoch** as plain integers. They accept several input forms, including ISO strings, Unix seconds or milliseconds, and timestamp objects with seconds and nanoseconds. | Function | Returns | | ------------------------------------------------------------ | -------------------------------------- | | `now()` | current UTC time in ms | | `date(input)` | parses any common date format into ms | | `isValidDate(input)` | true if input parses | | `addTime(ms, amount, unit)` | shifted timestamp | | `startOf(ms, unit)` | start of day/hour/etc. | | `endOf(ms, unit)` | end of day/hour/etc. | | `year(ms)` / `month(ms)` / `day(ms)` | components (UTC) | | `weekday(ms)` / `weekdayName(ms)` | 1=Mon..7=Sun, name string | | `hour(ms)` / `minute(ms)` / `second(ms)` / `millisecond(ms)` | components | | `formatDate(ms, format)` | formatted string (Luxon tokens) | | `toISO(ms)` | ISO 8601 string | | `toDateString(ms)` | YYYY-MM-DD | | `toTimeString(ms)` | HH:mm:ss | | `toMillis(input)` / `toSeconds(input)` | parsed date as ms / whole Unix seconds | | `dateDiff(a, b, unit)` | difference in unit (days, hours, etc.) | | `isWeekend(ms)` / `isWeekday(ms)` | true/false | | `isBefore(a, b)` / `isAfter(a, b)` | comparison | Units accepted by `addTime` / `startOf` / `endOf` / `dateDiff`: `year`, `month`, `week`, `day`, `hour`, `minute`, `second`, `millisecond` (with or without a trailing `s`). ```tgl // Bucket by week $out.week_start = startOf(date($row.created_at), "week") // Days since signup $out.tenure_days = dateDiff(now(), date($row.signup_at), "days") // Pretty-print $out.label = formatDate(date($row.created_at), "yyyy-MM-dd HH:mm") ``` If the input doesn't parse, `date()` returns `null`. Date functions that produce a value or formatted string return `null` for invalid input; date predicates such as `isValidDate`, `isWeekend`, and `isBefore` return `false`. Numeric date input below 10 billion is interpreted as Unix seconds; larger numeric input is interpreted as milliseconds. Both `toMillis` and `toSeconds` apply that parsing rule before converting to their requested unit. ## What's next - **[Recipes](/guides/tgl/recipes)**: common patterns combining these functions. - **[Operators](/guides/tgl/operators)**: comparison, logical, nullish coalescing. # TGL: Operators TGL has comparison, logical, and nullish-coalescing operators. It deliberately doesn't have arithmetic operators. This page also covers TGL's strict-typing semantics, which interact with operators in ways worth knowing about. ## Comparison ```tgl $out.is_admin = $row.role == "admin" $out.is_recent = $row.age < 30 $out.has_orders = $row.order_count >= 1 $out.eligible = $row.status != "banned" ``` Available: `==`, `!=`, `<`, `>`, `<=`, `>=`. `==` does strict equality (no type coercion, so `"5" == 5` is `false`). ## Logical ```tgl $out.flagged = $row.suspicious && $row.score < 0.5 $out.notify = $row.subscribed || $row.opted_in $out.is_invalid = !$row.is_valid ``` `&&` and `||` short-circuit. `!` negates. Truthiness is standard: `null`, `undefined`, `0`, `""`, `false`, and `NaN` are falsy; everything else is truthy. ## Nullish coalescing: `??` ```tgl $out.label = $row.label ?? "untitled" $out.country = $row.address.country ?? $row.user.country ?? "US" ``` `a ?? b` returns `a` unless `a` is `null` or `undefined`, in which case it returns `b`. Critically, `??` does NOT treat `0`, `""`, or `false` as missing. Only `null`/`undefined` triggers the fallback. Use this when you want a default for "really missing," not for "falsy." ```tgl $out.count = $row.count ?? 0 // 0 if count is null $out.checked = $row.opted_in ?? false // false if opted_in is null ``` ## What's not here: arithmetic There are no `+`, `-`, `*`, `/`, `%` operators. Use the [math functions](/guides/tgl/functions) instead: ```tgl $out.total = multiply($row.price, $row.qty) $out.with_tax = add($out.total, multiply($out.total, $row.tax_rate)) $out.average = divide($out.total, $row.count) ``` The reason: arithmetic operators in JS-like languages have surprising coercions (`"5" + 3` is `"53"`, `null + 1` is `1`, `[] + {}` is `"[object Object]"`). TGL's function-call form makes the type intent explicit. `add` accepts numbers and treats `null` as `0`; other types return `null`. There is no silent string-numeric mixing. ## Type semantics ### Strict typing Functions don't coerce silently. If `add` gets a string, you get `null`: ```tgl $out.total = add($row.x, $row.y) // row.x = 5, row.y = 3 returns 8 // row.x = "5", row.y = 3 returns null (string isn't a number) // row.x = null, row.y = 3 returns 3 (null treated as 0 in add) // row.x = 5, row.y = "abc" returns null (still null, abc isn't a number) ``` This is intentional. Silent type coercion can create subtle data bugs. TGL surfaces a math type mismatch as `null`. If your math involves a numeric string, add an `int(...)` or `float(...)` conversion. ### Null propagation Most functions return `null` when given `null` (or any wrong type). This propagates: `lowerCase(trim($row.email))` returns `null` cleanly when `email` is missing, instead of throwing. The exceptions are documented per-function. Most notably `add` and `subtract`, which treat `null` as `0` to make accumulators ergonomic. ## What's next - **[Functions](/guides/tgl/functions)**: every built-in by category. - **[Recipes](/guides/tgl/recipes)**: real-world patterns. # TGL: Recipes Real-world patterns. Each recipe is small, copy-pasteable, and combines features from the rest of the guide. ## Filter test users ```tgl #if startsWith($row.user_id, "internal_") $out = null /if $out = $row ``` ## Drop incomplete records ```tgl #if isEmpty($row.email) $out = null /if $out.email = lowerCase($row.email) $out.name = $row.name ``` `isEmpty` catches `null`, `""`, whitespace-only strings, `[]`, and `{}` in one shot, so a customer with `" "` (a single space) for their email is filtered out the same as one with `null`. ## Empty string to null ```tgl #if isEmpty($row["Type 2"]) $out.secondary_type = null #else $out.secondary_type = $row["Type 2"] /if ``` When a source field might be `""` (especially with CSV ingestion, where empty cells parse as empty strings), use `isEmpty` to coerce blanks to `null`. Rollups treat `null` and `""` as the same series, but downstream consumers (charts, exports, monitoring rules) read cleaner data when blanks are normalized at the transform layer. ## Numeric coercion (CSV to math) ```tgl $out.line_total = multiply(float($row["Price"]), int($row["Quantity"])) ``` ## Default values ```tgl $out.country = $row.address.country ?? "US" $out.label = $row.label ?? "untitled" $out.is_active = $row.is_active ?? true ``` ## Sum line items ```tgl $out.total = 0 #each $row.line_items as $item $out.total = add($out.total, multiply($item.price, $item.qty)) /each ``` ## Build a tag array ```tgl $out.tags = null #each $row.raw_tags as $tag #if !isEmpty($tag) $out.tags = push($out.tags, lowerCase(trim($tag))) /if /each ``` ## Conditional output shape ```tgl $out.id = $row.id $out.created_at = $row.timestamp #if $row.type == "purchase" $out.amount_cents = round(multiply($row.amount, 100)) $out.currency = $row.currency #elseif $row.type == "refund" $out.amount_cents = round(multiply(subtract(0, $row.amount), 100)) $out.refund_reason = $row.reason #else $out = null /if ``` ## Bucket by week ```tgl $out.week_start = toDateString(startOf(date($row.timestamp), "week")) $out.event = $row.event $out.user_id = $row.user_id ``` ## Normalize an email ```tgl $out.email = lowerCase(trim($row.email)) $out.email_domain = split($out.email, "@")[1] ``` ## Limits TGL enforces hard limits to bound compilation and each record execution. Compile limits apply to the script as a whole. Runtime limits reset for every input record. | Limit | Default | What happens when exceeded | | ---------------------------------- | ---------------------------- | ------------------------------------------------------------------- | | Transform script request | 65,536 UTF-16 code units | Request validation error; the script is not compiled or stored | | Statement count | 10,000 | Compile error; script rejected at storage time | | Expression or control-flow depth | 200 levels | Parse or compile error; script rejected at storage time | | Output path nesting | 50 levels | Compile error; script rejected at storage time | | String length for one value | 10,485,760 UTF-16 code units | That value becomes `null` | | Loop iterations per record | 1,000,000 | The record fails; processing continues with the next record | | Output writes per record | 10,000 | The record fails; processing continues with the next record | | Output array length | 10,000 | Oversized values become `null`; an out-of-range indexed write fails | | Values and containers copied out | 100,000 | The record fails; processing continues with the next record | | Cumulative output string/key bytes | 64 MiB | The record fails; processing continues with the next record | Tailglow rejects a transform request longer than 65,536 code units. Other compile limits reject the script before it is saved. Runtime string and array limits can turn an individual value into `null`; iteration, write, and cumulative output limits skip the affected record. ## Errors and validation ### Storage-time validation When you create or update a transform, Tailglow validates the script before saving it as `active`. Scripts that fail compilation or output-field validation are not stored. The output-field check compares the script's statically known top-level writes with the view's output schema. It is skipped for the exact mirror script `$out = $row` and for scripts with a dynamic top-level key such as `$out[$row.key]`, because their field sets cannot be known at compile time. Other scripts are not stored until they pass both compilation and output-field validation. ### Runtime errors An invalid input record or a row that reaches a runtime safety limit is skipped while processing continues with the remaining records. A structural output error, such as assigning an array to the root with `$out = arrayValue`, can mark a live transform as `error` or cause a backfill to fail after retries. Fix and save the script from the transform drawer. ### Per-record skip `$out = null` is not an error. It's a normal filter signal. The record is dropped silently and the view continues. # TGL: Syntax This page covers the basic shape of a TGL script: how to read input, build output, declare scratch variables, and lay out statements. ## `$row`: the input record `$row` is the record you're transforming. It's a plain JSON object: nested fields, arrays, strings, numbers, booleans, nulls. Read fields with dot or bracket notation: ```tgl $out.email = $row.email $out.full_name = $row["First Name"] // brackets when the key has spaces $out.first_tag = $row.tags[0] $out.deep = $row.user.profile.email ``` Reading a missing field returns `null`. TGL doesn't throw on undefined access. Same for chains where a parent is null: ```tgl $out.x = $row.does.not.exist // returns null, no error ``` `$row` is read-only. You can't write to it: `$row.x = 1` is a parse error. ## `$meta`: platform metadata `$meta` is a read-only object of platform metadata about the record, kept separate from the record's own fields on `$row`. It's how a transform reaches values Tailglow attaches when it ingests the data, rather than values that came in the payload. One field is available today: - `$meta.ingested_at` (string): the platform source time for the record, as an ISO 8601 timestamp. For collection rows, this is the server ingest time unless the request overrode it with a `?ts=` parameter. For transforms sourced from a ViewFile, including joins, it is that source file's creation time. Reach for it when your data has no timestamp of its own, or when you want Tailglow's time for the current transform stage. ```tgl $out.id = $row.id $out.ingested_at = $meta.ingested_at ``` `$meta` is read-only, the same as `$row`: writing to it (`$meta.x = 1`) is a parse error. Unlike `$row`, reading a field that isn't part of the contract (anything other than `$meta.ingested_at` today) is a compile error that lists the fields you can use, so a typo fails fast instead of quietly returning null. ## `$out`: your output `$out` starts as `{}` (an empty object) on every record. Build it up: ```tgl $out.id = $row.id $out.name = lowerCase($row.name) $out.created_at = $row.timestamp ``` Whatever's in `$out` when the script ends is the output record. You can also assign wholesale, copying every field: ```tgl $out = $row // mirror the entire input $out = $row.payload // promote a nested object to top-level ``` Wholesale assignment is filtered. Dangerous keys like `__proto__` are stripped automatically. You don't have to worry about prototype pollution from untrusted source data. ## `$varname`: scratch variables For intermediate values you don't want in the output: ```tgl $first = upperCase($row.first_name) $last = upperCase($row.last_name) $out.display = concat($first, " ", $last) ``` Variable names must start with a letter or underscore, followed by letters, digits, or underscores. A few names are reserved, including names with a `__` prefix, `constructor`, and `prototype`. Variables are scoped to the script. There's no global state across records. ## Statements Each statement goes on its own line. Newlines are the separator; semicolons aren't a thing. ```tgl $out.a = 1 $out.b = 2 ``` Comments use `//`: ```tgl // strip the protocol prefix $out.host = replace($row.url, "https://", "") ``` There's no block syntax for grouping statements. Control flow is done with directives. See [Control flow](/guides/tgl/control-flow) for `#if`/`#each`. ## Data types TGL works on the JSON-shaped data stored by Tailglow: strings, finite numbers, booleans, null, arrays, and objects. Date functions can parse ISO strings, Unix seconds or milliseconds, and timestamp objects with seconds and nanoseconds. There are no: - Object literals like `{ a: 1 }`. Build outputs by writing to `$out` field by field. - Array literals like `[1, 2, 3]`. Use `push(null, x)` to start an array. ## What's next - **[Control flow](/guides/tgl/control-flow)**: filtering rows, `#if`/`#elseif`/`#else`/`/if`, `#each`. - **[Operators](/guides/tgl/operators)**: comparison, logical, `??`. - **[Functions](/guides/tgl/functions)**: every built-in.