Search and retrieve pending (not yet posted) transactions for a property. Pending transactions represent charges, payments, or adjustments that have been created but not yet finalized. This endpoint uses POST (instead of GET) to support complex filter criteria in the request body. The filter and sort options are the same as for posted transactions.
Routing behavior: pending transactions keep their original source; when a transaction is routed to another source (for example a group profile), the routing target is stored separately. Filters on source_kind, source_id, and source_identifier (with equals or in operators) match the transaction's original or routed-to source, so querying a group profile returns both its direct pending charges and pending charges routed into it from reservations. folio_id filters (with equals or in operators) likewise match the folio the transaction occupies on either side of the routing. Returned transactions always show their original source in sourceKind / sourceId / sourceIdentifier.
Supported filter fields:
account_categorychart_of_account_typecreated_at(alias fortransaction_datetime)customer_idcustom_codeexternal_relation_idexternal_relation_kindfolio_ididinternal_codeorigin_idparent_idsource_idsource_identifiersource_kindtransaction_datetimetrial_balance_idservice_date
Supported sort fields:
created_at(alias fortransaction_datetime)idinternal_codesource_idtransaction_datetimeservice_date
Required filter constraints: The API has certain constraints for filters so that the system is able to efficiently query the data. Every request must include at least one of the following base filters:
idwith operatorequalsorinsource_idtogether withsource_kindsource_identifiertogether withsource_kindexternal_relation_idtogether withexternal_relation_kindtransaction_datetimeservice_datetrial_balance_id
Additional filter rules:
- Filters cannot be empty.
source_idrequiressource_kindto be present in the same request.source_identifierrequiressource_kindto be present in the same request.external_relation_idandexternal_relation_kindmust always be used together.trial_balance_idonly supports theequalsoperator and cannot appear more than once.- When using a single filter condition (without
and/or), onlyid,transaction_datetime,
orservice_dateare allowed, and the operator must beequalsorin.
Example — single filter condition (no AND/OR needed):
{
"filters": {
"field": "id",
"operator": "in",
"value": [101, 102, 103]
}
}
{
"filters": {
"field": "service_date",
"operator": "equals",
"value": "2024-01-01"
}
}
Example — composite filter condition:
{
"filters": {
"and": [
{
"field": "transaction_datetime",
"operator": "greater_than_or_equal",
"value": "2024-01-01T00:00:00Z"
},
{
"field": "transaction_datetime",
"operator": "less_than",
"value": "2024-02-01T00:00:00Z"
}
]
}
}
Example — composite filter condition with sorting and pagination:
{
"filters": {
"and": [
{
"operator": "greater_than_or_equal",
"value": "2019-01-11T08:59:00Z",
"field": "transaction_datetime"
},
{
"operator": "equals",
"value": "123",
"field": "source_id"
},
{
"operator": "equals",
"value": "RESERVATION",
"field": "source_kind"
},
{
"or": [
{
"operator": "in",
"value": ["1", "2", "3"],
"field": "customer_id"
},
{
"operator": "equals",
"value": "9000",
"field": "internal_code"
}
]
}
]
},
"pageToken": null,
"limit": 10,
"sort": [
{
"field": "transaction_datetime",
"direction": "asc"
}
]
}| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||

