---
title: "Resolve the email subject for a fiscal document"
method: GET
path: "/fiscal-document/v1/fiscal-documents/email-subject"
tags: ["Fiscal Documents"]
---

# Resolve the email subject for a fiscal document

`GET /fiscal-document/v1/fiscal-documents/email-subject`

## Request

- Base URL: `https://api.cloudbeds.com`
- URL: `https://api.cloudbeds.com/fiscal-document/v1/fiscal-documents/email-subject`
- Auth: one of:
  - HTTP bearer
  - OAuth 2
    - Authorization code: `https://api.cloudbeds.com/auth/oauth/authorize`
    - Token URL: `https://api.cloudbeds.com/auth/oauth/token` scopes: `read:reservation`

Returns the subject the service would put on the email, so a UI can seed an editable Subject
field from the same resolution the send uses rather than reimplementing it.

Give `documentId` for a document that exists. The answer is then exactly what a send with no
subject override produces: a token the service holds no value for resolves to an empty
string, as it would in the delivered email.

Give `documentKind`, `sourceKind` and `sourceId` instead for a document about to be created.
A token whose value is only assigned at creation is then returned **verbatim**, for example
`Grand Hotel - Invoice #[Invoice Number]`. Send the string back, edited or not, on the create
request and the service fills those tokens in once the values exist.

Supplying the chosen recipient lets the guest's language win when the property has
"use guest language" enabled; without it the subject falls back to the property's language.

## Query parameters

- `documentId` string
- `documentKind` 'INVOICE' | 'CREDIT_NOTE' | 'RECEIPT' | 'RECTIFY_INVOICE' | 'PRO_FORMA_INVOICE' | 'REFUND_RECEIPT' | 'INVOICE_RECEIPT' | 'ADVANCE_INVOICE' | 'SETTLEMENT_INVOICE' | 'TAX_WITHHOLDING': Kind of fiscal document
- `sourceKind` 'GROUP_PROFILE' | 'RESERVATION' | 'HOUSE_ACCOUNT' | 'ACCOUNTS_RECEIVABLE_LEDGER': Kind of the source entity
- `sourceId` integer
- `recipientType` 'GUEST' | 'CONTACT' | 'GROUP' | 'COMPANY' | 'GROUP_PROFILE' | 'GROUP_PROFILE_CONTACT': Which backing record a recipient id points at. Deliberately a separate schema from RecipientRequest.type even though the values match: $ref-ing that one would rename the generated RecipientRequest.TypeEnum and break every creation call site.
- `recipientId` integer

## Headers

- `X-Property-ID` integer, required

## Response `200`

OK

- EmailSubjectResponse
  - `subject` string, required: The resolved subject. On the create-form variant, tokens the service cannot fill yet are left verbatim, e.g. "Grand Hotel - Invoice #[Invoice Number]".

## Other responses

- `400`: Bad Request
- `403`: Access denied
- `404`: Not found

---

[API](https://skmtc.dev/cloudbeds/apis/fiscal-document-service-api.md) - [All operations](https://skmtc.dev/cloudbeds/apis/fiscal-document-service-api/llms.txt) - [OpenAPI document](https://skmtc.dev/cloudbeds/apis/fiscal-document-service-api/revisions/9c2a47775e5e?raw)