Returns metadata about the authenticated API token, the user it belongs to, the account it is scoped to, the token-level permissions, and (for regular user tokens) the user's account_user role flags and accessible pipeline IDs. Useful for agents and integrations to introspect their own capabilities before making other calls. Legacy API tokens are rejected with a 403.

Admin-only. Returns the Decile Hub accounts the calling admin user can reach — accounts that have opted in to decile-admin access plus any account the admin is directly a member of. Results are sorted by name and capped at 100 rows; pass search to filter by name or subdomain when the admin has access to many accounts. Non-admin tokens receive 403. Requires X-Account-Id header set to any account this admin can access; the response then enumerates the full set including that seed account.

Returns the current account's basic information

Returns the AccountUsers belonging to the authenticated token's account.
Use to discover the assigned_id value for PATCH /api/v1/pipeline_prospects and
PATCH /api/v1/pipeline_prospects/{id} (the prospect-owner field).

Pagination is zero-indexed; page size is 100.

Returns the activity feed for the current account, newest first. Filter by
subject (entity), event type, actor, or date range.

Pagination is keyset — pass pagination.next_page_token from a response back
as page_token= to fetch the next page.

Returns one activity entry plus the full per-type entryable body —
audit change diffs, full email bodies and recipients, note bodies,
AML/KYC status, chat summaries, and so on. The list endpoint omits this detail.

Returns a paginated list of the firm-admin entities (funds, SPVs,
holdings, management companies, general partnerships) under the
authenticated token's account. Identity-only payload — fund-specific
configuration (cutover dates, GP carry %, logo URL) is returned by
GET /api/v1/entities/{id} instead.

Pagination is 1-indexed (page 1 is the first page). per_page is
capped at 100; values <= 0 fall back to the default of 50.

Creates a new AccountOrganization plus a fresh Organization and (for
fund kinds) a FundDetail under the authenticated account.

Onboarding side effects are suppressed for API-created entities —
no LP closing pipeline is generated, no AccountOrganizationUser is
attached for the account owner, and no Accelerator client_product
touch fires. Callers that want the full onboarding workflow should
continue to use the firm-admin UI.

POST is not idempotent. To retry safely, GET /api/v1/entities and
check whether the desired entity already exists before retrying.

Requires a caller who is a full_access_account_admin? of the target account.

Returns identity + a details block for one entity. The details
block always includes currency, currency_symbol, fiscal_year_end,
entity_name, logo_url, is_active, and kind. When the entity is a fund
(kind=fund, spv, or holding) the details block additionally
includes gp_carry, new_management_fee_system_cutover_date, and
new_carry_system_cutover_date. For non-fund entities those keys are
omitted entirely.

Pass ?include=calculations to embed a calculations block of
fund-level dashboard values. ?window=now (default) returns
as-of-today values and includes capital_activity.invested plus
fees.reserved_for_fees; ?window=lifetime returns forecast values
and omits those two fields entirely. calculations is only supported
on fund-kind entities (kind=fund, spv, or holding); requesting
it on a non-fund entity returns 404. Numeric values serialize as
2-decimal-place decimal strings (currency) or 4-decimal-place
decimal strings (ratios such as performance.net_irr); investor
counts are integers.

Returns 404 (not 403) when the id refers to an entity in a different
account.

Updates writable fields on an existing entity within the authenticated
account. All fields optional — only sent fields are applied.

kind is immutable. Sending a matching kind is a no-op; sending a
differing kind returns 422.

Renaming guard: if the entity's Organization is shared with sibling
AccountOrganization rows (an edge case for entities created before this
endpoint existed, or via paths that don't use the API's two-step create),
PATCH refuses with 409 organization_shared_with_siblings and includes
the sibling entity ids in error.details.sibling_entity_ids so callers
can fall back to the firm-admin UI.

Additional rename guard at the model level:
Organization#prevent_name_change_if_accounting_transactions_exist
returns 422 if the Organization has associated accounting transactions.

PATCH is_active=false is the v1 stopgap for hiding an entity, since
DELETE is not yet supported.

Requires a caller who is a full_access_account_admin? of the target account.

Identity-only list. Per-account calculation values (committed
capital, contributions, balances) are intentionally NOT included
here — they come from the per-record /calculations endpoint and
the bulk /entities/{entity_id}/capital_accounts/calculations
endpoint.

Returns 404 when entity_id resolves to an entity in a different
account (cross-account requests are not distinguished from missing).

Identity block + commitments + primary_contact + contacts + entity
ref. contacts is the full list of contacts on the capital account
(joint signatories, spouses, trustees, entity owners/signatories,
trust beneficiaries); each entry carries role flags plus
contact_status_type (none/primary/additional). Returns 404
when the capital account belongs to a different account. Use
?include=transfers to embed an ordered list of capital-account
transfers oriented at the requested CA (kind=outbound when the
requested CA is the from_capital_account, inbound otherwise);
effective_at is aliased from the underlying transferred_at
column.

Computes a single capital account's period figures. Response groups:

- commitments — 12 commitment + paid-in fields.
- period_activity — 15 ledger movements within the window.
- performance — dpi, rvpi, tvpi.
- meta — period_start, period_end, currency,
management_fee_system, carry_system, cutover_dates. The
*_system keys are legacy (window ends before the cutover),
new (window starts on/after the cutover), or hybrid (window
straddles the cutover).

All numeric values are returned as decimal strings (currency 2
decimal places, ratios 4 decimal places). Nil values are returned
as null. Returning decimal strings is intentional so callers
don't lose precision via JS number parsing.

Period semantics: pass both period_start and period_end (ISO
YYYY-MM-DD). Both are required together — supplying one without
the other returns a 400. period_end must be on or after
period_start. When neither is supplied, the window defaults to
the current fiscal-year-to-date for the parent entity.

In a hybrid window the API uses the new-system carry calculation
directly even for GP-carry capital accounts, which can differ from
calculating each side of the cutover separately. Request explicit
pre/post cutover windows if you need each side calculated on its own.

Paginated bulk variant of the single-CA calculations endpoint.
Each row in capital_accounts is the same shape as the single-CA
response (commitments/period_activity/performance/meta groups) but
with id+name pulled out of identity for easier table rendering.
Adds a fund-level totals block aggregated across the filtered
scope (NOT only the current page).

Totals semantics:
- Currency fields are summed across the filtered scope.
- Per-CA ratio fields (percentage_of_total_commitments,
percentage_of_lp_commitments, percentage_of_funds_called,
amount_paid_in_for_capital_accounts_percentage) are null in
totals — per-account ratios do not sum into a fund-level figure.
- Performance ratios (dpi, rvpi, tvpi) are null in totals
for the same reason.
- total_committed_capital, lp_committed_capital,
gp_committed_capital are fund-wide regardless of filters — the
per-row total_committed_capital denominator is a fund-level
value, not "total of the filtered list."

Period and decimal-string semantics are identical to the single-CA
endpoint.

fields= projection: comma-separated whitelist of calculation
field names. When supplied, rows AND totals are narrowed to just
the requested fields. If zero requested fields fall within a
group, that entire group key is dropped from both rows and totals.
id and name are always present on each row. Unknown field
names are silently dropped.

Returns the journal entries (general-ledger / accounting transactions —
double-entry GL postings) recorded under the given entity. Each row
carries the transaction date/amount, reconciled/pending flags, comment,
the debit and credit ledger accounts (code + name), and the polymorphic
counterparty (type, id, name; null when absent). Discarded entries are
excluded.

Filters (all optional): a transaction_at window via
transaction_at_start/transaction_at_end; debit_code/credit_code
(GL account codes — an unknown code returns no rows); reconciled and
pending (true/false); min_amount/max_amount; and
counterparty_type (+ optional counterparty_id).

Returns 404 when entity_id resolves to an entity in a different
account (cross-account requests are not distinguished from missing).

Creates a single journal entry (general-ledger / accounting transaction —
a double-entry GL posting) under the given entity. Posts one debit/credit
pair for the supplied amount and date. The entry is created unreconciled
(reconciled false, pending false). debit_code and credit_code are
GL account codes (see the chart-of-accounts endpoint) — they must differ
and both must resolve to a known accounting account. amount must be
numeric and greater than 0. transaction_at is an ISO date (YYYY-MM-DD).
An optional counterparty can be attached via counterparty_type +
counterparty_id; the counterparty must belong to the same account.

Returns 422 on invalid input (unknown code, equal debit/credit codes,
non-positive or non-numeric amount, malformed date, or a cross-account
counterparty), 403 for a read-only token, and 404 when entity_id
resolves to an entity in a different account.

Creates many journal entries (general-ledger / accounting transactions —
double-entry GL postings) under the given entity in a single atomic,
all-or-nothing batch. Each row in journal_entries is a full independent
entry validated by the same rules as the single-create endpoint:
debit_code and credit_code are GL account codes (see the
chart-of-accounts endpoint) that must differ and both resolve to a known
account, amount is numeric and greater than 0, transaction_at is an
ISO date (YYYY-MM-DD), and an optional counterparty may be attached via
counterparty_type + counterparty_id (same account).

Provide between 1 and 100 rows. EVERY row is validated first; if ANY row
is invalid the entire batch is rejected with 422 and a per-row errors
array ({index, field, message}) and NOTHING is created. When all rows
are valid they are created together inside one database transaction; any
unexpected failure rolls the whole batch back (never a partial commit).
All entries are created unreconciled (reconciled false, pending
false). Idempotency is the caller's responsibility — re-sending a batch
posts it again.

Returns 422 on validation failure or an out-of-range batch (empty or more
than 100 rows), 403 for a read-only token, and 404 when entity_id
resolves to an entity in a different account.

Returns a single journal entry (general-ledger / accounting transaction —
a double-entry GL posting): transaction date/amount, reconciled/pending
flags, comment, the debit and credit ledger accounts (code + name), and
the polymorphic counterparty (type, id, name; null when absent). Returns
404 when the entry is unknown, discarded, or belongs to a different
account (cross-account requests are not distinguished from missing).

Returns the chart of accounts (GL account codes) shared across the
account. Use this to discover valid account codes before posting
journal entries. Codes follow standard GL ranges: 1xxx=assets,
2xxx=liabilities, 3xxx=equity, 4xxx=revenue, 6xxx/7xxx=expenses. All
filters are optional and combine with AND. Results are paginated and
ordered by code.

Returns a single chart-of-accounts entry (GL account code) by its
integer id. Use after list_accounting_accounts to confirm a code
before posting a journal entry.

Returns the capital calls (draft/open/closed) issued from the given
entity's fund. Each row carries header fields only: id, name, status,
percentage_to_call, notes, amount_being_called (sum of per-LP details),
created_at, closed_at, due_date, and the parent entity ref.

Filter by status and a created_at window via period_start /
period_end (both ISO dates; supply together). Returns 404 when
entity_id belongs to a different account.

Returns the header block for a single capital call. Use
/api/v1/capital_calls/{id}/details for per-LP rows.

Returns the per-capital-account line items (LPs/GPs) attached to a
capital call: amount called, the LP's committed capital, wired amount
and wire date (from reconciled wire transactions on the period),
variance (wired − called) and a derived payment_status
(fully_paid/underpaid/overpaid/unpaid/prepaid/over_commitment/
any_variance/unknown).

Returns a paginated list of financial report generation jobs that belong to the authenticated token's account, regardless of which token within that account created them. Sorted by created_at descending. Successful jobs include download URLs for the generated files.

Queues an asynchronous financial report generation job. The job includes every entity of the requested entity_type within the token's account. Use the returned status_url to poll job status and download generated files after the job succeeds.

Returns the current status for a financial report generation job created by the authenticated token. Successful jobs include download URLs for the generated files.

Gets a paginated list of Events in your account. The response will have a data array with the events and a pagination object with the total count, current page, and total pages. Pages are 0-indexed, so the first page is page 0. The Events returned can be filtered and ordered. Order direction is ascending by default.

Creates a new Event in your account. A successful request will return the created event data with success status. The event will automatically have an associated pipeline and questionnaire created for guest management.

Get a single Event by ID or unique_event_id. The default response shape is unchanged from prior versions. The optional include= and fields= parameters are purely opt-in - include= replaces the default include set (currently empty for events) with a caller-specified set, and fields= narrows top-level columns. include_guests=true is preserved as a backwards-compatible alias for include=guests.

Update an existing Event. Only the provided fields will be updated.

Delete an Event and all associated data including pipeline and questionnaire.

Get a paginated list of guests for an event with their RSVP status and pipeline stage information. Results can be filtered by email or pipeline stage.

Add multiple guests to an event. Guests will be created as People if they don't exist and added to the event pipeline. The response includes arrays of added, duplicate, and error results for processing feedback.

Update a guest's RSVP status for an event. This will also update the guest's pipeline stage accordingly.

Gets a paginated list of Files in your Files. The response will have a data array with the files and a pagination object with the total count, current page, and total pages. Pages are 0-indexed, so the first page is page 0. The Files returned can be filtered and ordered. Order direction is ascending by default.

Uploads a new file.

Request format

Must be sent as multipart/form-data with file params nested under
the file key:

- file[file] — the upload (required)
- file[name] — optional custom name
- file[description] — optional description
- folder_id — optional, top-level (not under file[]). If omitted,
the file is placed in the account's default folder.
- file[attachable_type] and file[attachable_id] — optional pair. When
both are provided, the upload is *also* attached to the given record so
it appears in that record's attachment list (in addition to landing in
the data room). Allowed attachable_type values: Person,
Organization, PipelineProspect. For PipelineProspect, the
attachment is routed to the prospect's underlying prospectable
(Person or Organization) — this matches UI behavior.

Supported extensions

.ppt, .pptx, .key, .doc, .docx, .mov, .mp4, .ogg, .pdf,
.png, .jpg, .jpeg

Example

``
curl -X POST https://decilehub.com/api/v1/files \
-H "Authorization: Bearer $TOKEN" \
-F "file[file]=@./doc.pdf" \
-F "file[name]=My Doc" \
-F "folder_id=123"
``

Gets details for a specific file, including metadata and associated folders.

Updates a file. You can update just the metadata (name/description),
or upload a new version of the file — uploading a new file creates a new
version while maintaining history.

Request format

Must be sent as multipart/form-data with params nested under the
file key. All fields are optional:

- file[name] — updated name
- file[description] — updated description
- file[file] — new file upload (creates a new version)

Downloads a file from your Files. Returns the file content with appropriate headers for download.

Saves an in-message file (an Attachment) into a data room folder so it is
durably stored and visible to the folder's audience.

The {id} path parameter is the Attachment id. The target folder is given
by the required top-level folder_id in the JSON body.

The operation is idempotent on the pair of (file content, folder): if the
same file content already exists in the folder, no new placement is created
and the existing one is returned with status: unchanged. Otherwise a new
placement is created and returned with status: created.

The response includes folder_path (a breadcrumb such as "Parent > Child")
and audience (a human readable phrase describing who can see the file),
which the agent uses to compose its success message.

Gets a paginated list of Folders in your Files. The response will have a data array with the folders and a pagination object with the total count, current page, and total pages. Pages are 0-indexed, so the first page is page 0. The Folders returned can be filtered and ordered. Order direction is ascending by default.

Creates a new folder in your Files. You can optionally specify a parent folder by providing a parent_id. Folder names must be unique within the same parent folder.

Gets details for a specific folder, including optional child folders and files. Use the contents parameter to specify what to include: "folders", "files", or "folders,files". Default includes both folders and files.

Searches data room folders by name to help disambiguate a user's folder
reference (for example "save it to Acme") into folder ids.

Only folders in your account that you can read are returned. The match is
case insensitive on the folder name and is capped at 50 results. Each match
includes the folder id, name, a breadcrumb path (for example "Parent > Child"),
and an audience phrase describing who can see files saved to that folder. The
agent uses these to compose its confirmation request.

The q parameter is required (a missing or blank q returns 400). A query
that matches no folders returns an empty matches array.

Gets a paginated list of Organizations in your Organizations Directory. The response will have a data array with the organizations and a pagination object with the total count, current page, and total pages.Pages are 0-indexed, so the first page is page 0.The Organizations returned can be filtered and ordered. Order direction is ascending by default. The default response shape is unchanged from prior versions and embeds notes, people, and submit_your_company_response_data. The optional include= parameter is purely opt-in - when supplied it replaces the default include set with a caller-specified subset; absent the parameter, the legacy default is returned verbatim. fields= narrows top-level columns when supplied.

Adds Organizations to your Organizations Directory. Only the first 100 Organizations per request will be processed.The response will have a created, duplicates, and errors array. The created array will contain the emails of the organizations that were created. The duplicates array will contain the emails of the organizations that were not created because they already exist in the database. The errors array will contain the emails of the organizations that were not created because of an error.

Create or Update an existing Organization. The request can only contain one Organization. A successful request will return a json object containing the success status, the organization_id, and a list of changes in the form of field_name: [old_value, new_value].

Get a single Organization by id. The default response shape is unchanged from prior versions (embeds notes, people, submit_your_company_response_data). The optional include= and fields= parameters are purely opt-in - include= replaces the default include set with a caller-specified subset, and fields= narrows top-level columns. The response also carries a logo object (see schemas/attached_image) with a download url, or null when no logo is attached.

Append a plain-text note to an organization. The note is stored on the organization
and surfaced wherever organization notes appear (including the prospect view if the
organization is a pipeline prospect's prospectable).

Gets a paginated list of People in your People Directory. The response will have a data array with the people and a pagination object with the total count, current page, and total pages.Pages are 0-indexed, so the first page is page 0.The People returned can be filtered and ordered. Order direction is ascending by default. The default response shape is unchanged from prior versions and embeds notes, organizations_with_titles, and referred_by. The optional include= parameter is purely opt-in - when supplied it replaces the default include set with a caller-specified subset; absent the parameter, the legacy default is returned verbatim. fields= narrows top-level columns when supplied.

Adds People to your People Directory. Only the first 100 People per request will be processed.The response will have a created, duplicates, and errors array. The created array will contain the emails of the people that were created. The duplicates array will contain the emails of the people that were not created because they already exist in the database. The errors array will contain the emails of the people that were not created because of an error.

Create or Update an existing Person. The request can only contain one Person. A successful request will return a json object containing the success status, the person_id, and a list of changes in the form of field_name: [old_value, new_value].

Get a single Person by id. The default response shape is unchanged from prior versions (embeds notes, organizations_with_titles, referred_by). The optional include= and fields= parameters are purely opt-in - include= replaces the default include set with a caller-specified subset, and fields= narrows top-level columns. The response also carries a picture object (see schemas/attached_image) with a download url, or null when no photo is attached.

Append a plain-text note to a person. The note is stored on the person and surfaced
wherever person notes appear (including the prospect view if the person is a pipeline
prospect's prospectable).

Returns a paginated, account-scoped list of Tasks. Optional filters narrow by status, assignee, and origin. Pages are 0-indexed. Requires the :hub_tasks feature flag to be enabled for the account; otherwise a 404 is returned.

Creates a user-origin Task assigned to a member of the account. The authenticated token's user is recorded as the creator. Requires the :hub_tasks feature flag for the account.

Returns a single account-scoped Task by id.

Updates a Task's title, description, assignee, due date, or status. Permitted for the task creator, current assignee, account owners/admins, and Decile admins.

Marks a Task as completed. Permitted for the task creator, current assignee, account owners/admins, and Decile admins.

Lists the shared "Decile Research" LP roster. The same roster is
visible to every authenticated account. The response has a data array
of roster entries and a pagination object with the total count, current
page (0-indexed), and total pages. Each entry carries the research
prospect id (use it with POST /api/v1/research/investors/copy_to_pipeline),
the LP person details, organization name(s), stage name, and probability.

Copies selected entries from the shared "Decile Research" LP roster
into one of the caller's own pipeline stages. Supply the research
prospect ids (from GET /api/v1/research/investors) and the target
stage_id (a stage in your account's investor pipeline). Each copy is
processed asynchronously; the response reports how many copies were
enqueued and any ids that did not match the roster.

Gets a paginated list of Prospects in a Pipeline. The response has a
data array with the Prospects and a pagination object with the total
count, current page, and total pages. Pages are 0-indexed, so the
first page is page 0. The Prospects returned can be filtered and
ordered. Order direction is ascending by default. Pass
custom_data_points=* (or a narrowed subset) to embed each prospect's
pipeline-declared custom data point values. For Select (Dropdown)
data points, the human-readable option label is returned (not the
underlying stored value).

Creates Person/Organization pipeline prospects for a given pipeline. Only the first 100 organizations and first 100 people will be processed.A valid request will return a json object with two keys, organizations and people. Each key will have a created, duplicates, and errors array. The created array will contain the names of the prospects that were created. The duplicates array will contain the names of the prospects that were not created because they already exist in the database. The errors array will contain the names of the prospects that were not created because of an error.

Updates one or more prospects in a pipeline. Send pipeline_id (query or body) and a JSON array prospects.
Each element can identify the prospect by id (preferred), exact name, or for Person prospectables by email.

Stage moves: pass stage_id at the top level and/or per prospect. Omit stage_id to leave the stage unchanged.

Metadata: probability, rating, next_contact, and last_contact can be updated. Send JSON null for
next_contact or last_contact to clear them

Notes: pass note to append a note (same as the single-prospect upsert).

Tags: pass tag_list (comma-separated) to add tags and/or remove_tag_list (comma-separated) to remove tags. Tags not present on a prospect are ignored on removal.

Single prospect: PATCH /api/v1/pipeline_prospects/{id} accepts the same fields without wrapping in prospects.

Same fields as the batch PATCH /api/v1/pipeline_prospects body (except prospects). pipeline_id is required
(query or body). The prospect id is taken from the path. Unlike the batch endpoint, this endpoint returns a
singular response shape (no prospects/errors wrapper).

Append a plain-text note in the context of a pipeline prospect. To match the in-app
behavior, the note is stored against the prospect's prospectable (Person /
Organization) when one exists, falling back to the prospect itself otherwise. When
note.context is omitted, the prospect's pipeline name is used as the context.

Create or update an existing pipeline prospect in a given pipeline. The request must contain exactly one of
person or organization. On create, stage_id selects the stage. On update, the prospect's stage is
not changed unless you pass apply_stage_id_to_existing: true (then stage_id is applied to an existing
prospect in this pipeline only).

To move stages or update next_contact, probability, rating, or append notes without using this upsert,
prefer PATCH /api/v1/pipeline_prospects (batch) or PATCH /api/v1/pipeline_prospects/{id} (single).

A successful response includes success, pipeline_prospect_id, and changes (field name to [old, new]).

Lists the PipelineActionExecution rows for a single prospect — i.e. the
actions queued to run (or that have run / been skipped) on this prospect
at its current stage. Each row includes a human-readable description and
a per-type target block with foreign-key names resolved server-side, so
a caller (especially an agent / MCP client) can show the user *what the
action would do* before triggering it.

Defaults to state=pending. Pass state=completed, state=skipped,
or state=all to broaden. The state filter applies to ROOT executions —
children of returned roots are always included regardless of state, so
callers can see what's already been done within an in-progress task.

final_action_for_stage rows (the workflow gate that holds a
prospect at its current stage — not user-pickable) are excluded by
default. Pass include_final=true to include them.

### Response shape

Tree-shaped — data contains only ROOT executions (each represents
one task in the UI), and each root carries a children array with its
subtasks. Subtasks within a root are intended to execute in order.
Roots are ordered by position, then scheduled_at (NULLs last);
children are ordered by position within their parent.

- prospect: { id, name, stage_id, stage_name } envelope so the caller
knows the prospect's current stage in the same round-trip.
- data: array of root executions. Each row:
- id (string) — execution id (integer rendered as string).
- state — one of pending, completed, skipped.
- action_type — one of the 15 PipelineAction types
(send_email, move_to_stage, assign_user, apply_tag,
set_variable, record_task_completed, chat, execute_job,
copy_to_pipeline, final_action_for_stage,
move_to_stage_from_date_cell, base_post_reply,
start_questionnaire, create_user_notification).
- description — human-readable summary, e.g. "Send email Welcome",
"Change stage to Qualified", "Apply tag Lead". Plaintext (no
<em> tags).
- scheduled_at — ISO8601 or null.
- automate — boolean; whether the periodic worker will fire this
without manual completion.
- action_id — id of the source PipelineAction template (may be
null if the template was deleted; type is denormalised on the
execution and survives template deletion).
- parent_id — null on root rows, set to the parent root's id on
children (children appear inside their root's children array, but
still carry parent_id so flat traversals see the link).
- target — type-specific resolved payload (see below). May be
null for types with no resolvable target.
- next_pending_id (root rows only) — id of the next leaf the
caller should pass to the execute endpoint (first pending child
in position order, else the root if it's still pending, else
null). Mirrors the UI's "next" leaf. Prefer this over the
root's own id when the root has pending children: executing a
root with pending children CASCADES — the worker runs every
child in order then the root, in one call, with no per-subtask
note prompt. Walking via next_pending_id mirrors the UI's
per-subtask flow.
- children (root rows only) — array of child rows with the same
shape (minus their own children and next_pending_id).

### Per-type target shape

| action_type | target keys |
| --- | --- |
| send_email | email_template_id, email_template_name |
| move_to_stage | stage_id, stage_name |
| final_action_for_stage | stage_id, stage_name (omitted/blank stage_id means "hold at this stage") |
| move_to_stage_from_date_cell | stage_id, stage_name |
| assign_user | assignee_id, assignee_name |
| apply_tag | tag |
| set_variable | variable_name, value, use_today |
| execute_job | job_class (raw class name; review before triggering) |
| copy_to_pipeline | pipeline_id, pipeline_name |
| chat | chat_agenda_id, chat_agenda_name |
| record_task_completed | task_description |
| base_post_reply | reply_text (truncated to 200 chars) |

Other action_type values currently return null for target.

Executes one PipelineActionExecution for the prospect — sends the
templated email, moves the stage, applies the tag, runs the configured
background job, etc., according to the execution's action_type and
snapshotted data, then advances any chained automated actions.

The action runs as authored. This endpoint only triggers an
existing pending execution. An optional note body field is honored
for record_task_completed actions (attached when marking the task
complete) — see the request body below. Other
body fields are silently dropped.

One execution per call. This endpoint deliberately does not loop or
bulk-execute — agent / MCP callers are expected to list pending
executions, surface each action's resolved description to the user,
and call this endpoint per confirmed action.

Idempotency: if the execution is already completed or skipped,
returns 422 with code: already_finalized. Validation gates or
missing prerequisites surface as 422 with
code: action_execution_error.

Response shape mirrors GET /action_executions: a prospect
envelope (so callers see the resulting stage_id / stage_name if
the action transitioned the prospect) plus a single execution
object with the post-execute state, resolved description, and
per-type target block (see the GET endpoint for the per-type
target table).

Renders the would-be sent email for a pending send_email
PipelineActionExecution — substitutes variables, resolves cc/bcc,
and reports unresolved variables / blocker warnings — without
sending or mutating the execution. The recipient is fixed to the
prospect that owns the execution; you can override the email body,
subject, cc/bcc, attachments, scheduled_at, the from-actor, the
template, and custom_substituted_variables at preview time.

Defaults come from the execution's persisted
data[:pipeline_email_content] (the authored content snapshot).
Any override key you submit replaces the corresponding persisted
value for this preview only — nothing is written back to the
execution. Override keys are flat at the top level of the request
body (mirrors POST /api/v1/emails/preview), not nested under a
wrapper.

cc / bcc semantics: absent → fall back to the execution's
persisted cc/bcc. Explicit [] clears (distinct from absent).
Accepted entry shapes mirror POST /api/v1/emails/preview: raw
email string, {person_id: "..."}, or
{internal_user_id: <numeric_id>}. Malformed entries return 422
invalid_recipient_format.

Non-send_email actions return 422 unsupported_action_type.
Use GET /api/v1/pipeline_prospects/{id}/action_executions to
confirm the action_type first.

Response mirrors POST /api/v1/emails/preview plus a
pipeline_action_execution block carrying the execution id,
state, and resolved description.

Returns the active pipelines for the current account. Pass
kind=investor to filter to investor pipelines. Rows are ordered
with the account's primary investor pipeline first (when one is
marked); prefer the is_primary: true row when multiple investor
pipelines exist. The id field is the value to pass to any
pipeline-scoped endpoint (e.g. /api/v1/pipeline_prospects?pipeline_id=…).

Returns basic information for a specific pipeline and its stages.

Returns aggregate counts/values for a pipeline plus a 7-days-ago
snapshot for week-over-week deltas. The caller is expected to
compute deltas in its prose layer.

Create a custom data point (Variable) on the account, scoped to the type of the targeted pipeline (investor / company / etc). Data points are not attached to a single pipeline — they live at the account level under a type-specific context (e.g. investor_data_points, company_data_points). The pipeline_id in the path is used only to derive that type context. When add_as_column: true, the resulting kanban column is fanned out to every pipeline of that type in the account, not just the targeted pipeline (this matches the UI behavior). Account admin authorization is required (account admins, or decile admins acting on the account). The select format requires a non-empty select_options array.

Share a deal from the caller's account into the network feed. Idempotent per organization: if a Deal Share already exists for the given organization in the caller's account its attributes are updated; otherwise a new record is created. The target organization must belong to the caller's account — use POST /api/v1/organization to create or upsert one first. Pass selected_files to attach existing org / deal-memo / term-sheet files the caller account owns; foreign or unknown ids are skipped. The response attachments list confirms what was attached.

Returns the deal shares the caller's account has submitted into the network feed.
Each row carries the full submission attributes plus the computed stage.

Filter with search, industry, stage, and round. Sort with column +
direction. Pagination is keyset — pass pagination.next_page_token from a
response back as page_token= to fetch the next page.

Returns one deal share submitted by the caller's account, with the full
submission attributes and the computed stage. Returns 404 if the share
does not belong to the caller's account.

Permanently deletes a deal share owned by the caller's account. The lookup
is scoped to the caller's account, so an unknown id or one belonging to
another account returns 404 and deletes nothing. This action cannot be undone.

Copy a network-feed shared deal into one of the caller account's pipeline stages. Creates (or reuses) an organization in the caller's account and adds it as a prospect to the given stage, asynchronously. The pipeline_stage_id MUST belong to the caller's account. Requires the caller account's shared deal feed to be unlocked (deal_sharing_unlocked_until present and in the future); decile admins and full-access account admins bypass that gate.

Run AI auto-fill enrichment for a deal share. Given an organization in the caller's account and a list of deal-share form field names, the model reasons over the data Hub already holds (organization profile, deal memos, notes, documents) and returns suggested values for those fields. The organization MUST belong to the caller's account. The call runs the LLM synchronously, so response latency tracks the model call. Field names use the form-input shape, e.g. deals_share[region] or deals_share[industry_list][].

Returns a paginated list of deal memos belonging to the caller's
account. Each row is a compact summary suitable for triage; use
GET /api/v1/deal_memos/{id} for the full payload (counterfactual,
ratings, links, question answers).

Pagination is keyset — pass pagination.next_page_token from a
response back as page_token= to fetch the next page.

Start a new deal memo for an organization in the caller's account. The config template is resolved automatically from the account's latest deal memo config. Fails with 422 if the organization already has a non-closed deal memo. The target organization must belong to the caller's account. Set copy_last_deal_memo to true to clone the organization's most recent closed deal memo instead of starting a blank one. File attachments are not supported via the API.

Returns the full deal memo payload — organization, counterfactual,
links, ratings summary, and question answers — for an agent to inspect
before acting on the memo. Attachments, due-diligence tasks, and
comments are not included; fetch them via their own endpoints.

Update an existing deal memo in the caller's account. Rejects updates with 422 when the deal memo is closed. Does not modify ratings, answers, attachments, or due-diligence tasks.

Submit a deal memo for review by Decile Hub. Requires the account to have the Deal Memo Review product enabled (returns 422 otherwise). Optionally attach a submission comment via submission_comment.content.

Close a deal memo with an outcome of approve or pass. Moves the underlying prospect to the configured pipeline stage and dispatches the close notification.

Returns portfolio companies across every fund in the current account.
Each row is a (fund, organization) pair — the fund's stake in a single
underlying company. Filter by fund_id or organization_id.

Pagination is keyset — pass pagination.next_page_token from a response
back as page_token= to fetch the next page.

Returns one portfolio company — the same allowlisted fields surfaced by
GET /api/v1/portfolio_companies.