# Reporting and audit access Source: https://docs.settlemint.com/docs/api-reference/observability/reporting-audit-access Use DALP's indexed read APIs, dashboard exports, transaction references, webhook delivery records, and audit-access responsibilities for reporting and data retrieval. You answer reporting and audit questions from DALP indexed read APIs, dashboard exports, transaction references, and webhook delivery records. The platform does not replace statutory books, reserve attestations, custody records, bank ledgers, or regulatory filings. DALP indexes EVM events and transaction receipts into read models. Authenticated callers query those models through read-only routes, export visible dashboard tables, and retain webhook delivery evidence. Organisation-scoped API keys let your integration pull the indexed tokenization dataset programmatically; you provision separate credentials for auditors or regulators who need the same surfaces. This page maps common reporting questions to those surfaces. For scope limits and unsupported capabilities, see [Access and audit responsibilities](#access-and-audit-responsibilities) and [What DALP does not provide](#what-dalp-does-not-provide). ## Reporting access modes [#reporting-access-modes] | Mode | DALP surface | Typical datasets | Export or delivery format | | ------------------------------ | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Online (interactive) | Dashboard tables and live read APIs | Current holders, filtered token or user events, token-action records, transaction status | Visible table rows via CSV or JSON export; JSON API responses for the queried page | | On-demand (pull) | Paginated read APIs, webhook replays, and dashboard exports | Holder register, event history for a date range, user events, token-action records, webhook delivery and chain-of-custody records | JSON from API routes; CSV or JSON from dashboard export; replay payloads from webhook routes | | Batch (push or scheduled pull) | Webhook subscriptions and your own scheduled API jobs | Event streams your integration subscribes to; full extracts your jobs page through holder, event, and token-action routes | Webhook HTTP deliveries with delivery-attempt records; JSON files your scheduler writes from API pagination | DALP does not ship a built-in regulatory reporting scheduler or a separate auditor portal. Batch reporting is either webhook push into your systems or scheduled pulls you operate against the read APIs. ## What DALP can answer [#what-dalp-can-answer] | Reporting question | Start here | Use it for | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Who currently holds this token? | `GET /api/token/{tokenAddress}/holders` | Current holder balances, available balance, frozen balance, and last indexed balance update. | | What changed this token's state? | `GET /api/token/{tokenAddress}/events` or `GET /api/v2/tokens/{tokenAddress}/events` | Event history filtered by event name, sender, transaction hash, wallet, date range, pagination, and sorting. | | Which token-action records are pending or executed for an asset? | `GET /api/token/{tokenAddress}/actions` | Time-bound on-chain and off-chain operations such as yield claims, maturity approvals, XvP operations, KYC update operations, and multisig approvals. | | What did this authenticated user do or receive? | `GET /api/v2/users/me/events` | User-scoped on-chain event history for transfers, approvals, and role changes. | | What transaction backs an operation? | Transaction status and token events | Match the operation status, on-chain transaction hash, block number, and event payload before closing a reconciliation item. | | Can dashboard data leave the platform? | Dashboard table export | Console tables that use the shared export component can download visible table rows as CSV or JSON. | | Can webhook evidence be audited? | Webhook delivery and chain-of-custody routes | Delivery attempts, replays by block range or event id, and event chain-of-custody proof where webhook events are used downstream. | ## Token-level reporting surfaces [#token-level-reporting-surfaces] ### Current holder register [#current-holder-register] Use the holder endpoint when the report needs the current indexed register for one token. The response groups balances under `token.balances`; compare `value`, `available`, `frozen`, `isFrozen`, and `lastUpdatedAt` against your internal ledger. Review frozen balances and whole-address freeze state separately from the total balance. ```bash curl -X GET "https://your-platform.example.com/api/token/0xTOKEN_ADDRESS/holders" \ -H "X-Api-Key: sm_dalp_xxxxxxxxxxxxxxxx" ``` For a point-in-time question, use historical-balance routes only when the token has the historical-balances feature attached. Those routes cover list reads, plus balance-at-block and holders-at-block queries. ### Event history [#event-history] Use token events when the report needs the activity trail behind balances, supply, compliance decisions, or feature state. ```bash curl -X GET "https://your-platform.example.com/api/token/0xTOKEN_ADDRESS/events?eventNames=TransferCompleted&eventNames=MintCompleted&eventNames=BurnCompleted" \ -H "X-Api-Key: sm_dalp_xxxxxxxxxxxxxxxx" ``` Event responses include `eventName`, `transactionHash`, `blockNumber`, `blockTimestamp`, `emitter.id`, `sender.id`, and event-specific `values`. The paginated token-events route adds JSON:API pagination with faceted filters and column sorting for token-event tables. Filter by `transactionHash` when your ledger stores the submitted hash, by `senderAddress` for the submitting wallet, or by `walletAddress` when you want events where a wallet was sender or recipient. Do not treat event amounts as formatted token values until you have applied the token decimals. ### Token-action records and corporate-operation evidence [#token-action-records-and-corporate-operation-evidence] Use the token-actions endpoint for time-bound tasks that need operational review, such as maturity or yield approvals, XvP approvals and execution, KYC update steps, and multisig approvals. Each record includes the type, status, activation time, optional expiry, execution time, and executor where applicable. ```bash curl -X GET "https://your-platform.example.com/api/token/0xTOKEN_ADDRESS/actions" \ -H "X-Api-Key: sm_dalp_xxxxxxxxxxxxxxxx" ``` Query the token-actions endpoint to find whether an operation is pending, upcoming, executed, or expired. Use token events and transaction status to confirm the on-chain result after execution. ## Dashboard exports [#dashboard-exports] DALP dashboard tables can expose a download dropdown when they use the shared table export component. The CSV option downloads the visible row model with Excel-compatible encoding and respects per-column settings. The JSON option downloads the row data, with an optional table-specific transform when a table needs a structured output format. Use dashboard downloads for working files and review packs. Treat them as snapshots of the current visible table state, not as signed regulatory filings or a substitute for the underlying API and on-chain evidence. ## Webhook audit evidence [#webhook-audit-evidence] When downstream systems consume DALP events through webhooks, keep the delivery records with the report. The webhook API supports reading attempts for an endpoint, retrying a failed push, replaying historical notifications by block range or event id, and reading chain-of-custody proof for a specific notification. | Need | Endpoint | | -------------------------------- | ------------------------------------------------------ | | List webhook endpoints | `GET /api/v2/webhooks` | | List delivery attempts | `GET /api/v2/webhooks/{id}/deliveries` | | Read one delivery attempt | `GET /api/v2/webhooks/{id}/deliveries/{deliveryId}` | | Replay historical webhook events | `POST /api/v2/webhooks/{id}/replays` | | Read event chain of custody | `GET /api/v2/webhooks/events/{evtId}/chain-of-custody` | Use these records to prove what DALP attempted to deliver to your integration. The receiving system owns its own ingestion logs, any data transformations it applied, and its filing records. ## Access and audit responsibilities [#access-and-audit-responsibilities] DALP separates reporting data from operating authority. Read APIs are authenticated; scope resolves from the caller's organisation, system, user role, participant assignment, and route permissions. API keys are organisation-scoped; create separate keys per organisation and environment when you run independent extraction jobs or hand credentials to audit firms. Asset-level operating authority remains separate from dashboard membership or report access. For organisation and system scope details, see [Organisation and system scope](/docs/api-reference/reference/organization-system-scope). Global-admin operations have a structured audit-log path for both successful calls and denied calls. That audit stream records the user, route, outcome (success or denial reason), and timing. Cache context is also recorded when present. The global-admin audit stream is an operator surface, not a tenant-export API. ## What DALP does not provide [#what-dalp-does-not-provide] | Topic | Responsibility | | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Statutory or bank ledger of record | DALP supplies indexed platform and on-chain evidence. You reconcile it with bank ledgers, custody records, reserve attestations, and filings. | | Signed regulatory filing packages | Dashboard exports and API JSON are working files, not certified filings. | | Vendor-operated manual report runs | Read APIs and exports run under credentials you control. DALP does not operate scheduled regulatory report generation on your behalf. | | Cross-organisation data joins in one call | API keys resolve one organisation context. Combine extracts in your reporting warehouse when you span organisations. | | Tenant export of global-admin audit logs | The global-admin audit stream is for operator review, not a customer reporting API. | ## Recommended reporting workflow [#recommended-reporting-workflow] 1. Start with the holder register for the token. 2. Pull token events for the reporting period, filtered by event names, wallet, sender, or transaction hash. 3. Match each ledger entry to a transaction hash, block timestamp, event name, and amount after decimal conversion. 4. Review the token-actions list for pending, expired, or executed operational tasks that explain expected changes. 5. Export relevant dashboard tables when reviewers need spreadsheet or JSON working files. 6. Attach webhook delivery or chain-of-custody evidence when an external system relies on pushed DALP events. 7. Reconcile DALP evidence with bank ledgers, custody records, reserve attestations, and statutory books before final reporting. ## Related pages [#related-pages] * [Reconcile balances](/docs/developers/operations/reconciliate-balances) for a step-by-step balance reconciliation workflow. * [Token events](/docs/api-reference/tokens/token-events) for event filters, faceted search, and table behaviour. * [Token holders and transfers](/docs/api-reference/tokens/token-holders-transfers) for holder and transfer API details. * [Data availability](/docs/architects/data-availability) for the difference between indexed read models and on-chain execution truth. * [Webhook endpoints](/docs/api-reference/webhooks/webhook-endpoints) for webhook event subscriptions and payload references.