General Ledger Transactions
General Ledger Transactions endpoints for the Accounting API Unified API
A General Ledger Transaction is a posted entry in the general ledger, regardless of its origin — invoice posting, bill posting, payment, manual journal, payroll, etc. The source_type field discriminates the origin. Read-only by design: clients write through the originating resource (invoices, bills, payments, journal-entries).
The General Ledger Transactions model
A unique identifier for an object.
The originating transaction type that produced this posting in the general ledger. Discriminates whether the entry came from an invoice, a bill, a payment, a manual journal, etc. This is the key field that distinguishes general-ledger-transactions from journal-entries (which only covers manually-captured entries). May be null when the upstream connector did not return an origin discriminator (e.g. Xero's single-record endpoint strips SourceType for every record; certain historical records also omit it). To recover a populated value, query the list endpoint.
Identifier of the originating document in the vendor system. For example, when source_type is 'invoice', this is the id of the invoice that produced this posting. Use this id together with source_type to fetch the source document via its dedicated unified resource.
The date on which the transaction was posted to the general ledger. This is the accounting date — it is what determines the period the transaction belongs to and can be earlier than the creation date for backdated postings.
Optional reference identifier for the transaction.
Sequential number auto-assigned by the vendor system to the transaction (e.g. Xero JournalNumber). Unique per company.
List General Ledger Transactions
List General Ledger Transactions
Header parameters
ID of the consumer which you want to get or push data from
The ID of your Unify application
Provide the service id you want to call (e.g., pipedrive). Only needed when a consumer has activated multiple integrations for a Unified API.
The ID of the company to scope requests to. For connectors that support multi-company, this overrides the default company configured in connection settings.
Query parameters
Include raw response. Mostly used for debugging purposes
Cursor to start from. You can find cursors for next/previous pages in the meta.cursors property of the response.
Number of results to return. Minimum 1, Maximum 200, Default 20
Apply filters
Apply sorting
Optional unmapped key/values that will be passed through to downstream as query parameters. Ie: ?pass_through[search]=leads becomes ?search=leads
The 'fields' parameter allows API users to specify the fields they want to include in the API response. If this parameter is not present, the API will return all available fields. If this parameter is present, only the fields specified in the comma-separated string will be included in the response. Nested properties can also be requested by using a dot notation.
Example: fields=name,email,addresses.city
In the example above, the response will only include the fields "name", "email" and "addresses.city". If any other fields are available, they will be excluded.
Responses
Request example
Response example
Get General Ledger Transaction
Get General Ledger Transaction
Path parameters
ID of the record you are acting upon.
Header parameters
ID of the consumer which you want to get or push data from
The ID of your Unify application
Provide the service id you want to call (e.g., pipedrive). Only needed when a consumer has activated multiple integrations for a Unified API.
The ID of the company to scope requests to. For connectors that support multi-company, this overrides the default company configured in connection settings.
Query parameters
Include raw response. Mostly used for debugging purposes
The 'fields' parameter allows API users to specify the fields they want to include in the API response. If this parameter is not present, the API will return all available fields. If this parameter is present, only the fields specified in the comma-separated string will be included in the response. Nested properties can also be requested by using a dot notation.
Example: fields=name,email,addresses.city
In the example above, the response will only include the fields "name", "email" and "addresses.city". If any other fields are available, they will be excluded.
Responses
Request example
Response example