> For the complete documentation index, see [llms.txt](https://docs.nerovasystems.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nerovasystems.com/guides/observe-and-account/work-and-receipts.md).

# Audit work and receipts

The work ledger records business-action evidence and historical job records. Retiring fixed native campaigns does not retire action policy, approvals, or the ledger. A record's presence is not evidence that its originating campaign remains an offered feature.

> **Experimental.** The `/api/v1/**` operations on this page are callable with your Live key (`nrv_live_`), which runs on the free testing allowance until a commercial agreement is signed or a card is saved. See [Lifecycle and availability](https://docs.nerovasystems.com/documentation/api/lifecycle).

## What you'll build

An audit trail in your platform: a paged ledger view that distinguishes jobs from receipts, plus durable storage of the activation receipt issued when a tenant went live.

## Prerequisites

* An activated tenant and an API key with both `work:read` and `receipt:read` (the ledger requires every listed scope); see [Authentication](https://docs.nerovasystems.com/documentation/getting-started/authentication).

## 1. Page the ledger

Jobs and receipts are merged into one ledger, newest first:

```bash
curl --request GET \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/work?Limit=25" \
  --header "Accept: application/json" \
  --header "Authorization: ******"
```

Follow `nextCursor` until it is `null` (`Limit` 1–100, default 50), and narrow with `From`/`To`, a half-open UTC window of at most 31 days. The `evidence` field on every item is a PII-redacted human summary you can show as-is.

## 2. Tell jobs from receipts

Both kinds share one item shape; `kind` and the id prefix tell them apart.

* **`"kind": "job"`** (`jobrn_` prefix): a recorded job for the tenant, including historical jobs. `provider` is `nerova` and `capability` is the recorded job type, not a current campaign catalog. `status` and `outcome` carry the run status in lowercase: `detected`, `awaitingapproval`, `executing`, `completed`, `skipped`, or `failed`. `verified` is `true` when the job completed and left a receipt.
* **`"kind": "receipt"`** (`ebrcp_` prefix): a billing-grade receipt for one mutation against an external booking provider. `status` is the billing status (`pendingevidence`, `pendingreconciliation`, `billable`, `nonbillable`, `periodclosed`, `adjusted`, or `legacyunclassified`) and `outcome` is the verification outcome (`IntentRecorded`, `Verified`, `Unverified`, `OutcomeUnknown`, `Failed`, `Escalated`, `UnsupportedProvider`, or `LegacyUnclassified`). `hostRecordReference` points at the record created in the system of record, for example an `Appointment`, or is `null` while the provider identifier is pending.

**Historical vocabulary, not a campaign offering:** earlier examples used `weekly-digest`, `vaccination-due`, `service-due`, `win-back`, `fill-tomorrow`, `gap-fill`, and `payment-recovery`. Keep readers compatible with historical data rather than presenting those labels as available automation. The [authored source retirement](https://docs.nerovasystems.com/documentation/console/platform-access#campaign-and-escalation-retirement) removes fixed native campaigns, but is not a deployment claim. Infrastructure, usage, and SaaS jobs, including unrelated account usage preferences, are separate.

A blocked action or an `OutcomeUnproven` result is not a verified business action. That distinction does not rename the receipt's existing `OutcomeUnknown` or historical `Escalated` values, and those values do not imply a live escalation-routing engine.

The verification model behind `verified` is described in [Capabilities and verification](https://docs.nerovasystems.com/documentation/platform/capability-model).

## 3. Fetch one item

Either identifier works against the single-item endpoint:

```bash
curl --request GET \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/work/{workId}" \
  --header "Accept: application/json" \
  --header "Authorization: ******"
```

Use this when your platform stores `hostReference` values from the ledger and later needs to re-read a single job or receipt.

## 4. Keep the activation receipt

Activation itself issues a receipt, separate from the work ledger. Store the `receiptId` returned when you activate, and re-read it any time with:

```bash
curl --request GET \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/receipts/{receiptId}" \
  --header "Accept: application/json" \
  --header "Authorization: ******"
```

It records the activation `state`, `activatedAt`, the `consentVersions` accepted, the `mandateContractVersion`, and the provider and channel evidence hashes: the proof of what the tenant agreed to when it went live. See [Activation reference](https://docs.nerovasystems.com/api-reference/activation).

## Next steps

* Turn verified receipts into a billing meter: [Meter usage for billing](/guides/observe-and-account/usage.md).
* See what the work added up to: [Report on performance](/guides/observe-and-account/performance.md).
* Full request and response shapes: [Work and receipts reference](https://docs.nerovasystems.com/api-reference/work).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nerovasystems.com/guides/observe-and-account/work-and-receipts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.