> For the complete documentation index, see [llms.txt](https://developer.sahamati.org.in/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.sahamati.org.in/sahamatinet-agent-sna/integration-guide/dispatch-input-reference/additional-attributes-addlattr.md).

# Additional Attributes (addlAttr)

The `addlAttr` field in `sna.dispatch()` carries additional attributes that SNA needs for accurate latency measurement, billing, and correlation across the AA-FIP and AA-FIU interfaces. Which attributes apply depends on the API and the interface.

#### Structure

All values below are synthetic and for illustration only.

```json
"addlAttr": {
  "eventTime": "2026-01-01T10:00:00.000Z",
  "consentTypes": ["PROFILE", "SUMMARY", "TRANSACTIONS"],
  "cnsCorId": "consent-uuid-test-001",
  "fiuCnsId": "fiu-consent-id-test-001",
  "ssnCorId": "session-uuid-test-001",
  "fiuSsnId": "fiu-session-id-test-001",
  "fiFetchEncDataLen": 2131
}
```

Send only the attributes that apply to the API being dispatched.

#### Applicability

**AA-FIU Interface**

| API                              | eventTime | consentTypes | cnsCorId | ssnCorId | fiFetchEncDataLen           |
| -------------------------------- | --------- | ------------ | -------- | -------- | --------------------------- |
| /Consent                         | Required  |              | Optional |          |                             |
| /Consent/handle                  | Required  |              | Optional |          |                             |
| /Consent/fetch                   | Required  |              | Optional |          |                             |
| /Consent/Notification (AA → FIU) | Required  |              | Optional |          |                             |
| /FI/request                      | Required  | Required     |          | Optional |                             |
| /FI/Notification (AA → FIU)      | Required  |              |          | Optional |                             |
| /FI/fetch                        | Required  |              |          | Optional | Conditional (response only) |
| /Consent/Notification (FIU → AA) | Required  |              |          |          |                             |
| /FI/Notification (FIU → AA)      | Required  |              |          |          |                             |
| /Heartbeat                       | Required  |              |          |          |                             |

**AA-FIP Interface**

| API                              | eventTime | consentTypes   | cnsCorId | fiuCnsId | ssnCorId | fiuSsnId | fiFetchEncDataLen           |
| -------------------------------- | --------- | -------------- | -------- | -------- | -------- | -------- | --------------------------- |
| /Consent                         | Required  |                | Optional | Optional |          |          |                             |
| /Consent/Notification (FIP → AA) | Required  |                | Optional | Optional |          |          |                             |
| /FI/request                      | Required  | For future use |          |          | Optional | Optional |                             |
| /FI/Notification (FIP → AA)      | Required  |                |          |          | Optional | Optional |                             |
| /FI/fetch                        | Required  |                |          |          | Optional | Optional | Conditional (response only) |
| All other AA-FIP APIs            | Required  |                |          |          |          |          |                             |

Each attribute applies to both the request and the response of the API, unless marked otherwise.

> 📌 **Optional** attributes are for future use. **Conditional** means required only when `encryptedFI` is redacted.

#### eventTime

**Required** on every `sna.dispatch()` call, on both interfaces.

**What to send:** The UTC timestamp, in ISO 8601 format with milliseconds, at which the AA:

* received a request (`requestIn`) or response (`responseIn`), or
* is sending a request (`requestOut`) or response (`responseOut`).

**Why:** SNA calculates latencies from the AA's own timestamps. This keeps latency measurement accurate and independent of whether the peer's clock is in sync.

#### consentTypes

**Required** on /FI/request on the AA-FIU interface. On the AA-FIP interface, it is for future use.

**What to send:** The array of consent types from the `consentTypes` field of the approved, signed consent that the AA returned to the FIU in the /Consent/fetch response.

**Why:** SNA uses the consent types to determine whether a data fetch is for transactions or only for profile and summary, since these may be billed differently. SNA does not store consents for long periods, so it relies on the AA to provide this context with each data fetch.

#### cnsCorId (Consent Correlation ID)

**Optional.** For future use.

**What to send:** A UUID that the AA creates when it first receives a /Consent request from an FIU. It is different from the consent ID. Send the same value on all consent APIs related to that consent, on both interfaces.

**Why:** In future, this may be used to map a consent requested by an FIU from the AA to the corresponding consent sent by the AA to the FIP. AAs can send either `cnsCorId` or `fiuCnsId`.

#### fiuCnsId (FIU Consent ID)

**Optional.** For future use. AA-FIP interface only.

**What to send:** The consent ID from the FIU side, sent on the consent APIs to and from the FIP.

**Why:** Serves the same purpose as `cnsCorId`. If you already send `cnsCorId`, this is not required.

#### ssnCorId (Session Correlation ID)

**Optional.** For future use.

**What to send:** A UUID that the AA creates when it first receives an /FI/request from an FIU. It is different from the session ID. Send the same value on all data-fetch APIs related to that session, on both interfaces.

**Why:** In future, this may be used to map a data fetch by an FIU from the AA to the corresponding data fetch by the AA from the FIP. AAs can send either `ssnCorId` or `fiuSsnId`.

#### fiuSsnId (FIU Session ID)

**Optional.** For future use. AA-FIP interface only.

**What to send:** The session ID from the FIU side, sent on the data-fetch APIs to and from the FIP.

**Why:** Serves the same purpose as `ssnCorId`. If you already send `ssnCorId`, this is not required.

#### fiFetchEncDataLen (FI Fetch Encrypted Data Length)

**Conditional.** Required only when the `encryptedFI` field is redacted. Applies to /FI/fetch responses on both interfaces.

**What to send:** The length of the original `encryptedFI` string in the /FI/fetch response.

**Why:** SNA uses the length of `encryptedFI` to calculate the volume of data exchanged. AAs that prefer not to share the encrypted payload with SNA can redact or mask `encryptedFI` in the body and send its length here instead. Continue to send the rest of the body as usual.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://developer.sahamati.org.in/sahamatinet-agent-sna/integration-guide/dispatch-input-reference/additional-attributes-addlattr.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.