---
title: "get sales velocity events table"
method: GET
path: "/api/v1/sales/velocity/events/table"
tags: ["sales_velocity_events"]
---

# get sales velocity events table

`GET /api/v1/sales/velocity/events/table`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/sales/velocity/events/table`
- Auth: HTTP bearer

A page of sales velocity events with their windows, statuses, adjustment types and item counts. Page with `limit` and `offset`, narrow with `filter_args` and `search`, order with `sort_args`.

Beside the page it serves the whole filtered book's breakdown, so a figure row above a calendar costs no second read. `status_counts` carries `{active, upcoming, past, cancelled}` and honours every filter and the search term EXCEPT a status filter, so the four sum to `filtered_max_size` whether or not a status is selected, and they are served even on a page with no rows. `awaiting_input_count` is how many of those events are custom events, not yet past, with no values entered anywhere in their window, which is the same fact as `awaiting_input` on each row, and it honours every filter except an `awaiting_input` filter.

Every row carries `exclude_from_training`, whether the baseline has been told not to learn from that window. A planner sets the mark when the event is created or edited in Tightly, and no operation in this reference sets it. It reads false on an organisation whose events table cannot record the mark, which is the truth there.

Scope: `sales:read`.

## Query parameters

- `limit` integer
- `offset` integer
- `filter_args` string
- `sort_args` string
- `search` string

## Headers

- `Tightly-Version` string

## Response `200`

The sales velocity events table

- SalesVelocityEventsApiResponse
  - `data` unknown
  - `message` SalesVelocityEventsApiMessage
    - `desc` string
    - `service` string
    - `severity` 'SUCCESS' | 'INFO' | 'ERROR' | 'WARNING'

## Other responses

- `400`: Bad Request - Invalid request parameters or validation errors
- `401`: No usable key: malformed, unknown, revoked, expired or stopped. One refusal covers all five, telling a caller which is which maps the surface for them. A request with no Authorization header at all is refused 400 before any key is looked for.
- `403`: The key may not reach this operation. `scope_missing` when the key does not hold Sales; `organization_mismatch` when the path names an organisation that is not the key's; `ip_not_allowed` when the caller's address is outside the key's allowlist.
- `429`: The key has spent its allowance for this minute. 600 reads and 120 writes a minute, counted per key, refused calls included. `Retry-After` says how long to wait.
- `500`: Internal Server Error - Database connection or processing errors
- `503`: The database is briefly out of reach, which is what a failover or a full connection pool looks like from outside. Wait the seconds `Retry-After` names and send the request again. A read is safe to repeat. A write is not, because the connection was lost in the middle of it, so read the object back before sending it a second time. Branch on the status rather than on `code`, which is `POSTGRES_UNAVAILABLE` from one of the two seams that raise this and `SERVICE_UNAVAILABLE` from the other.

---

[API](https://skmtc.dev/tightly/apis/tightly-api.md) · [All operations](https://skmtc.dev/tightly/apis/tightly-api/llms.txt) · [OpenAPI document](https://skmtc.dev/tightly/apis/tightly-api/revisions/199f7eb35afb?raw)