---
title: "List invoice activity"
method: GET
path: "/companies/{company}/invoices/{invoice}/activities"
tags: ["Invoices"]
---

# List invoice activity

`GET /companies/{company}/invoices/{invoice}/activities`

## Request

- Base URL: `https://api.factuarea.com/v1`
- URL: `https://api.factuarea.com/v1/companies/{company}/invoices/{invoice}/activities`
- Auth: one of:
  - HTTP bearer
  - API key in header `X-API-Key`

Return the cursor-paginated activity timeline (audit log) of an invoice.
- Covers status transitions, emails, reminders, VeriFactu submission results to AEAT, public link visits and payments.
- The `metadata` of each type follows the `InvoiceActivity` schema.

## Path parameters

- `company` string, uuid, required
- `invoice` string, uuid, required

## Headers

- `Factuarea-Version` string, date

## Response `200`

- object: Cursor-paginated list envelope shared by every v1 listing endpoint. `data` holds the page items; `has_more` signals whether another page exists; `next_cursor` is the cursor to pass back for the following page. Treat it as strictly opaque: send it through verbatim, never parse it and never assume a format — it is not the same across listings, and each listing documents its own cursor parameter. Concrete listings narrow `data` to their resource type via `allOf`.
  - `data` object[], required: Items on the current page.
    - `object` 'activity', required
    - `event_type` string, required: Domain event type (e.g. `invoice.created`, `invoice.paid`). These types have an exact `metadata` contract (see `metadata`): `verifactu.record_accepted` (AEAT accepted a record of the invoice — the alta, a subsanation or the annulment —, with or without admissible errors), `verifactu.record_rejected` (AEAT rejected a record), `verifactu.transmission_failed` (the submission failed because of AEAT or the network and is retried automatically; ONE per incident, not one per attempt), `verifactu.transmission_blocked` (the submission is stopped with no automatic retry until someone fixes the cause), `invoice.email_failed` (the invoice email could not be delivered after its retries) and `invoice.public_link_viewed` (first visit of the day, Europe/Madrid, to the public link; later visits that day do not add another entry), `payment.payment_created` (a payment was registered), `payment.payment_reversed` (a payment was reversed) and `payment.payment_updated` (a payment was edited). Payment events also cover the payments recorded before they were published here.
    - `description` string, required: Human-readable description of the event in Spanish.
    - `metadata` object, required: Event metadata. Internal identifiers (PKs) are stripped; `*_uuid` values are preserved. The event types listed in `event_type` publish EXACTLY these keys: `verifactu.record_accepted` → `record_type`, `csv`, `aeat_error_code`, `requires_subsanation`, `attempt`; `verifactu.record_rejected` → `record_type`, `aeat_error_code`, `aeat_error_message`, `attempt`; `verifactu.transmission_failed` → `record_type`, `reason`, `attempt`, `next_retry_at`; `verifactu.transmission_blocked` → `record_type`, `block_reason`; `invoice.email_failed` → `recipient`, `reason`; `invoice.public_link_viewed` → `views_today` and, only when known, `downloaded_pdf`; `payment.payment_created` → `amount`, `method`, `provider`; `payment.payment_reversed` → `amount`, `reason`, `provider`; `payment.payment_updated` → `changed_fields`, `provider`.
      - `record_type` 'alta' | 'subsanacion' | 'anulacion': `verifactu.*` events: which record was submitted — the initial `alta`, a `subsanacion` (a new alta that corrects a previous one) or the `anulacion`.
      - `csv` string, nullable: `verifactu.record_accepted`: secure verification code (CSV) AEAT returned. `null` when AEAT confirmed the record as a duplicate of an earlier submission (the CSV belongs to that one).
      - `aeat_error_code` string, nullable: `verifactu.record_accepted`: code of the admissible error (`2xxx`) or warning AEAT accepted the record with, `null` when it was accepted without errors. `verifactu.record_rejected`: code of the rejection (`SCHEMA_INVALID` when the record was rejected without being sent because it breaks the AEAT XML schema).
      - `requires_subsanation` boolean: `verifactu.record_accepted`: whether AEAT requires a subsanation of `aeat_error_code`. Every admissible error does except `2004` (FechaHoraHusoGenRegistro) and `2009` (ClaveRegimen with IPSI), which AEAT exempts (AEAT «Validaciones» v1.2.2, §4.3.1). `false` when there is no error.
      - `aeat_error_message` string, nullable: `verifactu.record_rejected`: description of the rejection given by AEAT.
      - `attempt` integer: `verifactu.record_accepted`, `verifactu.record_rejected` and `verifactu.transmission_failed`: number of submission attempts of the record so far.
      - `reason` string: `verifactu.transmission_failed`: why the submission failed — `AEAT_UNREACHABLE` (AEAT did not answer, timed out or the network failed), `UNMATCHED_RESPONSE_LINE` (the AEAT answer did not include this record) or `SYSTEM_CERTIFICATE_UNAVAILABLE` (the Factuarea certificate used in third-party remission is not available). `invoice.email_failed`: readable reason in Spanish, without sensitive data (never the raw text of the mail server). `payment.payment_reversed`: key of the reversal reason (e.g. `issued_in_error`, `direct_debit_return`, `card_dispute`).
      - `next_retry_at` string, date-time, nullable: `verifactu.transmission_failed`: when the automatic retry is scheduled (ISO 8601), or `null`.
      - `block_reason` 'MISSING_CERTIFICATE' | 'MISSING_REPRESENTATION' | 'PRESENTER_NOT_ENABLED' | 'SUBMISSION_REJECTED': `verifactu.transmission_blocked`: why the submission is stopped. It does not go out again until the cause is fixed and the record is reactivated (`POST /v1/companies/{company}/verifactu/records/retry-blocked`).
      - `recipient` string: `invoice.email_failed`: email address the invoice was sent to.
      - `views_today` integer: `invoice.public_link_viewed`: visits of that day when the entry was recorded. The entry is written on the first visit and not rewritten, so it is `1`.
      - `amount` string: `payment.payment_created` and `payment.payment_reversed`: amount of the payment in euros as a 2-decimal string.
      - `method` string: `payment.payment_created`: payment method key, from the catalog of `GET /v1/payment-methods` (e.g. `bank_transfer`, `cash`, `credit_card`).
      - `provider` string, nullable: `payment.*`: origin of the payment when it was collected automatically — `stripe`, `gocardless`, `monei`, `woocommerce` or `shopify` — or `null` for a payment registered by hand. Read from the payment itself, so it is also present on events recorded before it existed. When `performed_by` is `null` and `provider` is set, the payment came from that gateway.
      - `changed_fields` string[]: `payment.payment_updated`: names of the payment fields that changed (`amount`, `date`, `method`, `reference`, `notes`).
      - `downloaded_pdf` boolean: `invoice.public_link_viewed`: `true` when the visit that opened the day was the PDF download. Absent when it is not known (a visit to the page).
    - `performed_by` object, nullable, required: Actor that originated the event. `{type:"user",...}` for an internal user, `{type:"api_key",...}` when performed via the public v1 API, or `null` when the event is system-generated (scheduler, periodic sweep) with no attributable actor.
      - `type` 'user' | 'api_key', required: Type of actor that originated the event: `user` for a human in the internal app, `api_key` for an action performed through the public v1 API.
      - `id` string, required: UUID v7 of the actor: the user when `type=user`, or the API key when `type=api_key`.
      - `name` string, nullable, required: Actor name at the time of the event: the user name or the API key name. `null` if it could not be resolved.
    - `created_at` string, date-time, required: When the event occurred (ISO 8601).
  - `has_more` boolean, required: Whether more pages are available after this one.
  - `next_cursor` string, nullable, required: Opaque cursor for the next page, or `null` when `has_more` is `false`. The example below shows the shape used by most listings; others return a different one, so pass the value back verbatim instead of validating it.

## Other responses

- `400`: `parameter_unknown` with `subcode` `retired_active_profile_header`: the retired `X-Active-Profile` header was sent; the company goes in the path. `parameter_invalid_format` on `Factuarea-Version`: the header is not a `YYYY-MM-DD` date. `unsupported_api_version`: the `Factuarea-Version` date is not a supported version.
- `401`: Missing or invalid API key.
- `403`: The request is authenticated but not allowed: the API key lacks the required scope (`insufficient_scope`), the plan does not include the public API or this feature (`addon_not_active`, `feature_not_available_in_plan`), or the module is not available with a test key (`module_not_available_in_sandbox`).
- `404`: The requested resource does not exist or belongs to another company.
- `429`: Rate limit exceeded. Retry after the duration in `Retry-After`.
- `500`: Unexpected server error.

---

[API](https://skmtc.dev/factuarea/apis/factuarea-public-api.md) · [All operations](https://skmtc.dev/factuarea/apis/factuarea-public-api/llms.txt) · [OpenAPI document](https://skmtc.dev/factuarea/apis/factuarea-public-api/revisions/718e77934422?raw)