Skip to main content
This guide walks through the complete process of enriching transactions, from preparing your data to processing the results.

Preparing Transaction Data

Required Fields

Every enrichment request needs three fields:

Transaction Title Best Practices

Don’t truncate or pre-process the transaction title. Include everything from the bank statement: ✓ "POS 4392 STARBUCKS STORE #1234 NEW YORK NY 10001" ✗ "STARBUCKS" The full string contains valuable signals (store numbers, locations, dates) that improve accuracy.
Keep the original case, spacing, and punctuation: ✓ "AMAZON.COM*2K4X9T3H2 AMZN.COM/BILL WA" ✗ "Amazon"
If your transaction source provides additional description fields, concatenate them: javascript const title = [ transaction.description, transaction.merchantName, transaction.locationInfo ].filter(Boolean).join(' ');

Country Code

The country code should be:
  • ISO 3166-1 alpha-2 format (2 letters)
  • The country where the transaction originated
  • Uppercase or lowercase (both work)
If you’re unsure of the country, use the account holder’s primary country. Transaction strings often contain location hints that Triqai can use for more accurate matching.

Transaction Type

Set type based on the transaction direction: This affects how Triqai interprets the transaction and which categories it considers.

Making the Request

Basic Request

Processing Multiple Transactions

For multiple transactions, make individual requests. Retries and rate limits are handled automatically:
Transient errors (429, 500, 503) are automatically retried with exponential backoff, so you don’t need to implement retry or rate-limit logic yourself.

Processing the Response

Successful Response

A successful enrichment returns structured data with an entities array:

Extracting Key Data

Handling Different Transaction Types

Regular Purchases

Most transactions identify a merchant directly:

Intermediary Transactions

When a payment processor or platform is involved:
Triqai identifies the intermediary (Stripe, role processor) and attempts to identify the underlying merchant (Acme Inc).

P2P Transfers

Peer-to-peer payments return both an intermediary and a person entity:
Returns the P2P platform as an intermediary (role p2p) and the recipient as a person entity.

Income Transactions

Refunds, salary, and other income:
Uses income-specific categories and classification logic.

Next Steps

Handling Responses

Learn to process different response types

Error Handling

Handle errors and edge cases

API Reference

See the full API documentation

Best Practices

Optimization tips and patterns