> This page is for API Reference.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://fiftytwo-demo.ferndocs.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://fiftytwo-demo.ferndocs.com/_mcp/server.

# About Transaction POS Log

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](https://pulsar.apache.org/). Topics
are structured:

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

> **Note**
>
> 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:

| Endpoint                                                                             | Purpose                               |
| ------------------------------------------------------------------------------------ | ------------------------------------- |
| `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-day` | End-of-day report for a session       |

> **Warning**
>
> 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](/docs/guides/transaction-events)

A working consumer, plus reconciliation strategy.

#### [Migrating off the Receipt API](/api/transactions/receipt-api)

If you are still polling the deprecated API.