Search

Local mode exposes two searches. They answer the same question against different stores, and the one you pick decides what you can filter and what you can see.

Beta — Early Access

Kushki ONE Local Network is currently in Beta for Perú 🇵🇪. Do not deploy to production without coordinating with the Kushki integration team.

Which one to call

	Online	Local
Endpoint	`POST /sync/transaction_search_online`	`POST /sync/transaction_search_local`
Reads from	The Kushki acquirer backend	The terminal's own storage
Needs internet	Yes	No
Scope	Every terminal of the merchant	Only this terminal
Filter by `transaction_type`	✅	❌
Use it for	Reconciliation, recovering a lost `transaction_reference`	Offline reconciliation, or when the acquirer is unreachable

When in doubt use Online — it is authoritative. Fall back to Local when the venue's internet is down and the cashier needs to see what the device processed.

Request

Only page and size are required. filters and every property inside it are optional.

{
  "page": 1,
  "size": 10,
  "filters": {
    "last_four_digits": "9130",
    "start_date": 1785560400000,
    "end_date": 1788238799000
  }
}

Filter	Online	Local
`bin`	✅	✅
`last_four_digits`	✅	✅
`client_transaction_id`	✅	✅
`transaction_reference`	✅	✅
`start_date` / `end_date`	✅	✅
`transaction_type`	✅	—

size caps at 500. transaction_type uses camelCase (preAuth, reAuthorization, posTip) even though the endpoint paths use snake_case.

Dates are the easy thing to get wrong

start_date and end_date are 13-digit millisecond timestamps. A 10-digit value in seconds is a thousand times smaller, so it lands in January 1970:

What you sent	Symptom
Both fields in seconds	Empty result set
Only `start_date` in seconds	Returns your full history, not the range you asked for
Only `end_date` in seconds	Validation error `2021`, `start_date must be before end_date`

DANGER

The middle case is the dangerous one — the request succeeds and returns data, just far more than you meant. Check the digit count before you reconcile.

Send 0 in both fields to disable date filtering entirely. The value is an absolute instant on the epoch, with no timezone of its own. Peru does not observe daylight saving time, so America/Lima stays on UTC-5 all year — resolve it with a timezone library anyway:

Got a suggestion on this documentation? Contact us.

Which one to call#

Request#

Dates are the easy thing to get wrong#

Which one to call

Request

Dates are the easy thing to get wrong