--- title: "Compute Cohort" method: POST path: "/analytics/sales-report/cohort" tags: ["Analytics"] --- # Compute Cohort `POST /analytics/sales-report/cohort` ## Request - Base URL: `https://be.graph8.com/api/v1` - URL: `https://be.graph8.com/api/v1/analytics/sales-report/cohort` - Auth: HTTP bearer The whole Sales Report for one filter, in one round trip. Cohort plus funnel, pipeline, revenue and drill-down - thirteen sections resolved from a single deal cohort, which is the reason this is one call and not thirteen: the sections agree because they are computed over the same resolved set, not re-derived. Reads; writes nothing. It is a POST because the filter is a tree, not because it mutates - and it is tiered `read` for that reason. The filter is `extra="forbid"`: a misspelled key is a 422 naming it, rather than a silently wider result with a 200 on it. ## Query parameters - `tz` string: IANA timezone the local-day window bounds are computed in, e.g. `Asia/Tokyo`. Changes which deals fall inside the date range. ## Headers - `Authorization` string, nullable - `X-Target-Org-Id` string, nullable ## Request body - FilterQueryDto: JSON shape consumed by POST /api/sales-report/cohort. Empty groups are omitted by callers; absent groups treated as empty. - `date` DateRangeDto, required - `from` string, date, required - `to` string, date, required - `rep` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `pipeline` UuidFilterGroupDto: `pipeline` / `stage` — `CBDeal.pipeline_id` and `.stage_id` are real `PostgresUUID` columns, so a non-UUID can only ever fail open. - `in` string[] - `not` boolean - `stage` UuidFilterGroupDto: `pipeline` / `stage` — `CBDeal.pipeline_id` and `.stage_id` are real `PostgresUUID` columns, so a non-UUID can only ever fail open. - `in` string[] - `not` boolean - `lifecycle` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `audiences` IntIdFilterGroupDto: `rec_type` / `audiences` — `Lead.rec_type` is `SmallInteger` and `audience_id` is `Integer`; both appliers coerce and skip what will not parse. - `in` string[] - `not` boolean - `rec_type` IntIdFilterGroupDto: `rec_type` / `audiences` — `Lead.rec_type` is `SmallInteger` and `audience_id` is `Integer`; both appliers coerce and skip what will not parse. - `in` string[] - `not` boolean - `signals_email` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_voice` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_linkedin` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_sms` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_forms` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_website` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_calendar` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_chat` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_intent` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_crm` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_sequence` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_enrichment` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `channel` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `campaign` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `country` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `industry` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `headcount` HeadcountFilterGroupDto: `headcount` — a CLOSED vocabulary (`HEADCOUNT_BANDS`), and the exact list `/filter-options` hands the client. - `in` string[] - `not` boolean - `grading_bucket` GradingBucketFilterGroupDto: `grading_bucket` — a CLOSED vocabulary (`GRADING_BUCKETS`). An unknown bucket produces no band clause and widens to the full book. - `in` string[] - `not` boolean - `objections` ObjectionCodeFilterGroupDto: `objections` — codes live in the PER-ORG `cb_objection_codes` catalog, so only the SHAPE can be checked here. Blank is the one thing the applier provably cannot use. - `in` string[] - `not` boolean - `tier` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `pipeline_target` 'prospects_meeting' | 'prospects_revenue' | 'customers_revenue', nullable - `granularity` 'day' | 'week' | 'month', nullable ## Response `200` Successful Response - ApiResponseReportPayload - `data` ReportPayload, required: An OPEN envelope around one report's answer. The app wraps every one of these reports in `{success, data, meta}`, where `meta` carries the cache state, the window and - on the agency reports - `failed_org_ids`, the orgs that contributed NOTHING to the totals above. That field is the difference between "this client sent no email" and "we could not query this client", so it is forwarded rather than flattened away. Open on purpose: `data` is `dict | list` in the app and its contents grow with the product. A closed model would turn every new metric into a silently dropped one. - `pagination` PaginationMeta - `page` integer, required: Current page number (1-indexed) - `limit` integer, required: Items per page - `total` integer, required: Total number of items - `has_next` boolean, required: Whether there are more pages - `next_cursor` string, nullable: Opaque cursor for the next page; null when there are no more items. Pass it back as the `cursor` query param to fetch the following page without computing page numbers. - `total_available` integer, nullable: Search endpoints only: how many records really match, when known. Can be larger than `total`, which is capped at the 10,000 results that can be paged. For company search this is a distinct-company estimate. Null when unknown; absent outside search. - `total_is_lower_bound` boolean, nullable: Search endpoints only: true when more records match than `total` shows (the result set is larger than the 10,000 results that can be paged). Absent outside search. - `notes` string[], nullable: Search endpoints only: plain-language notes about the result, e.g. that more records match than can be paged, or that a reversed `between` range was put in order. ## Other responses - `422`: Validation Error --- [API](https://skmtc.dev/graph8/apis/graph8-developer-api.md) · [All operations](https://skmtc.dev/graph8/apis/graph8-developer-api/llms.txt) · [OpenAPI document](https://skmtc.dev/graph8/apis/graph8-developer-api/revisions/2e7cfa0ca921?raw)