> For the complete documentation index, see [llms.txt](https://docs.hos.accessacloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hos.accessacloud.com/atreemo-api/get-started/response-format.md).

# Response format

Native Atreemo response envelopes, bodyless successes and dynamic rows

{% hint style="warning" %}
**Beta, runtime validation pending.** Published tables/samples are supplemented by read-only source inspection at commit `ea9cb106e13aa4b9b92c01d090118742b44dd470`. Source returns are not proof of the deployed release.
{% endhint %}

Request `Accept: application/json`; source also configures XML formatting. Not every success has a body and HTTP `200` does not always mean business success.

Atreemo has **no universal response envelope**. Preserve casing, singular/plural names and payload placement.

| Convention                    | Operations | Distinction                                              |
| ----------------------------- | ---------: | -------------------------------------------------------- |
| ResponseStatus and Errors     |         48 | `Errors` contains `APICallError` objects.                |
| Response and Error            |         59 | `Error` can be a string or list.                         |
| Response and Errors           |         23 | `Errors` is a list of strings.                           |
| Lowercase response and errors |         30 | Native names are lowercase.                              |
| Success and Error             |          7 | Event-specific envelope.                                 |
| Error only                    |          8 | No status flag.                                          |
| Response flag only            |          1 | Also has operation-specific fields.                      |
| Payload-only                  |         35 | Object, array, dictionary or operation-specific value.   |
| Success and Message           |          1 | Real-time dispatch can report business failure in `200`. |
| Lowercase success and data    |          1 | Engagement AI shape.                                     |
| Source-verified bodyless      |          4 | `Ok()` without a value; no fabricated schema.            |

## Representative conventions

### ResponseStatus and Errors

```json
{
  "ResponseData": {
    "CurrentTiersName": "Synthetic tier"
  },
  "ResponseStatus": false,
  "Errors": [
    {
      "ErrorCode": 13,
      "ErrorDescription": "Invalid CtcID"
    }
  ]
}
```

This is a synthetic LoyaltyPoint-shaped failure, not a universal model.

### Response and Error

```json
{
  "Response": false,
  "Error": "Synthetic validation failure"
}
```

Do not substitute a string where an operation declares an error array.

### Lowercase response and errors

```json
{
  "response": true,
  "ProjectID": 1,
  "errors": []
}
```

This is a synthetic `PostSLPOutput` shape.

Payload-only examples include Company/GetCompanies returning an array, Corporate/Get returning an array, AtreemoTranslator/Translate returning a dictionary, and Workspace using JSON names such as `organisation`, `inviteUser` and `error`.

## Four bodyless successes

Absence of public documentation was not treated as proof of emptiness. Source inspection establishes exactly four bodyless success paths:

| Operation                                                  | Source return                                                                       |
| ---------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `POST /api/App/RemovePushNotificationToken`                | `AppController.cs:405–452`; public boolean annotation/sample conflicts with `Ok()`. |
| `POST /api/Company/AddComment`                             | `CompanyController.cs:535–568`.                                                     |
| `DELETE /api/Company/DeleteCompany/{cpyId}`                | `CompanyController.cs:508–530`.                                                     |
| `GET /api/Social/ApproveSocialCampaign/{socialCampaignId}` | `SocialController.cs:22–63`; successful upstream update returns `Ok()`.             |

Their `200` responses intentionally have no content/schema. This truthfully models source and conflicts with the repository's blanket response-schema policy; owner resolution is still required. Do not change them to `204` or invent empty objects.

Every body-bearing operation has a synthetic response example. The bodyless four deliberately do not.

## Models, serialization and dynamic rows

All 55 originally fieldless named models have source-backed definitions and nested types. Recursive `CubeSelection`, its numeric `CritType` names and engagement metrics are retained from source. Runtime/build alignment remains separate.

`GetSelectionResult`, `GetSelectionResult_Ext` and `GetSelectionResultWithUserFilter` return `Result` arrays whose row keys depend on `FormatID` and database logic. The contract intentionally uses open row objects with `additionalProperties: true`. There is no one fixed `DataTable` row model to infer; format-specific schemas require explicit owner approval and evidence.

Wire names depend on serializer path:

* Ordinary Web API JSON can use serializable field contracts, including compiler backing-field names.
* `CubeSelection` explicitly uses public properties through `JsonObject(MemberSerialization.OptOut)`.
* PATCH binders can use the default Json.NET resolver and therefore a different nested shape.
* `JsonProperty` and `IgnoreDataMember` are respected; MessagePack `IgnoreMember` is not a Json.NET ignore attribute.
* Nullable CLR value types remain nullable; request-property presence is not inferred from CLR non-nullability.

| Source type               | JSON/OpenAPI representation                                      |
| ------------------------- | ---------------------------------------------------------------- |
| String                    | string                                                           |
| Int16 / Int32 / Int64     | integer with appropriate width                                   |
| Decimal / Double / Single | number                                                           |
| Boolean                   | boolean                                                          |
| DateTime                  | date-time string, without a universal time-zone claim            |
| Byte array                | base64 string                                                    |
| List / array              | array                                                            |
| String-key dictionary     | object with typed additional values                              |
| Enum                      | numeric output; names recorded separately from closed validation |
| object / dynamic          | arbitrary JSON, not an invented fixed object                     |

All examples are synthetic. Avoid logging personal data, authentication members, tokens or full payloads. See [Errors](broken://pages/85e546b61406ff3ffac18f135046c2c4b67841e3), [Request format](broken://pages/a9c041f0cee2801011fe8f84c258e85a5190d739), [Paging](broken://pages/1df82a06dedb9c9a6567fc85e2e486a4726dd2b7) and [Testing and support](broken://pages/4ebb976c2c8353fb6080a8cf9f615312b52d4144).


---

# 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://docs.hos.accessacloud.com/atreemo-api/get-started/response-format.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.