Skip to navigation

About Transaction POS Log

Rich transaction events pushed to you, with REST endpoints for backfill.
View as Markdown

The Transaction POS Log API (TPLA) moves transaction POS logs into the event-driven space. Instead of polling a REST API for new data, FiftyTwo pushes the data to you as it arrives. It pushes rich events, so the payload has what you need without follow-up queries.

The event payload is identical to the one the REST endpoints return.

What this buys you

  • No long polling, so less network traffic
  • Real-time reaction to transactions
  • Resiliency: after a consumer outage, data is ordered and waiting
  • Horizontal scale: add consumers round-robin for high volume
  • No business logic around HTTP status codes; an event arriving is the data

Transport

Events are delivered over Apache Pulsar. Topics are structured:

persistent://customer-name/chain-name/topic-name

Pulsar credentials and your topic path are provisioned per customer and are not part of the OpenAPI specification. Ask your FiftyTwo consultant.

REST endpoints

Three remain, best used for backfill and reconciliation rather than steady-state ingestion:

EndpointPurpose
GET /v1/chain/{chainNumber}/transaction-pos-log/{lastId}Chain-wide transactions from a cursor
GET /v1/chain/{chainNumber}/store/{storeNumber}/transaction-pos-log/{lastId}Store-scoped, from a cursor
GET /v1/chain/{chainNumber}/store/{storeNumber}/session/{sessionNumber}/end-of-dayEnd-of-day report for a session

Pulsar delivery is at-least-once. Any event can arrive twice, so transaction handlers must be idempotent or you will double-count.

Next

Consume transaction events

A working consumer, plus reconciliation strategy.

Migrating off the Receipt API

If you are still polling the deprecated API.