At Ntropy, a transaction denotes the movement of money between two entities - the account holder, and the counterparty, mediated by one or more intermediaries. The direction of the flow - outgoing or incoming, is always determined from the perspective of the account holder:

• In an outgoing transaction, the account holder is the sender and the counterparty is the receiver.
• In an incoming transaction, the account holder is the receiver and the counterparty is the sender.

Enriching your first transaction

In order to enrich a transaction, we need to first create an account holder.

Having the account holder created, we can now submit a transaction for enrichment:

How does it work?

Enrichment API

The Enrichment API enriches transactions synchronously. Transactions are expected to have a unique id. If two transactions are submitted with the same id, the last will overwrite the older one.

Transactions require an account holder to be specified. Setting it as null will disable both categorization and recurrence. Attributes specified for an account holder can drastically improve enrichment accuracy, for more details please refer to the guide.

Enriched transactions are always accessible via the Transactions API and only by the API key that has submitted them.

Throughput considerations

The enrichment provided by the Transactions API is optimized to reduce latency. As a result, it might not be the best fit for your workload, as you might hit rate limits. To overcome these limitations, refer to our Batch API.

Error handling

When submitting transactions for enrichment, some errors might occur. It is important to note that transactions that have errors or return a non-2xx status code on enrichment are not billed. This is applicable to batch operations as well.

Transaction errors can be due to user input, such as submitting a transaction with a non-existing account holder id, resulting in a account_holder_not_found error or due to infrastructural issues on our side, such as external API timeouts and in some cases LLM instability, resulting in an internal_error.

Managing transactions

After enrichment, the enriched transactions are persisted in our system. You can interact with them via our Transactions API. The API is consistent with that of other endpoints, and it allows you to bulk fetch transactions, get and delete a transaction and reassigning account holders. Unlike the Enrichment API, the transactions returned by these endpoints contain the original transaction input fields.

Fetching the previous enriched transaction

List all transactions

For listing operations, the SDK returns a cursor with the next set of results. The cursor has to be added to the subsequent requests alongside the initial query parameters. We recommend that you use our SDK for this purpose, as it’s handled automatically there.

Deleting a transaction

The transaction API also let’s you delete transactions. Deleting a transaction deletes it from our system and is permanent.

Reassigning the account holder

Sometimes when submitting transactions, there is a mistake when assigning transactions to an account holder. This operation allows you to change account holders of a transaction without having to resubmit them. The old and new account holders should share the same set of categories.

Reporting wrong results

In some cases a transaction might be incorrectly categorized - it might have the wrong counterparty or have been assigned the wrong category. The Reporting wrong results section walks you through how to report these incorrect results from the enrichment process and ensure that future transactions won’t carry these errors.

---