> 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/request-format.md).

# Request format

Native Atreemo methods, parameters, bodies and binding caveats

{% hint style="warning" %}
**Beta, runtime validation pending.** The public catalogue defines the operation inventory. Cited corrections use read-only source commit `ea9cb106e13aa4b9b92c01d090118742b44dd470`; no operation was executed.
{% endhint %}

## Base URL

Resource examples use the Staging base. The APIM resource bases are:

```
Staging
https://api-staging.hos.accessacloud.com/atreemo-api

Production
https://api.hos.accessacloud.com/atreemo-api
```

Endpoint availability and routing behaviour require staged release validation. Native token acquisition goes directly to the caller's relevant Atreemo instance at `https://<atreemo-instance>/token`, not APIM. The instance URL and credentials are supplied through the approved Atreemo support and onboarding process. Use HTTPS, with TLS 1.2+ recommended rather than claimed as a verified setting.

Most operations use `/api/{Area}/{Method}`. `POST /Workspace/AddUser` and `GET /Workspace/InviteUser` intentionally omit `/api` (`WorkspaceController.cs:17–39`). Their inclusion does not approve onboarding use.

## HTTP methods and side effects

The **217 operations on 212 paths** comprise 115 POST, 83 GET, 10 DELETE, 5 PUT and 4 PATCH operations. Use the documented method/path; do not infer a REST convention. `/api/SalesLeads/Put` and `/api/Subscription/Put` are POST operations.

**GET does not guarantee safety.** `Social/ApproveSocialCampaign` updates a campaign and may send email; `Workspace/InviteUser` mutates Workspace and sends an invitation; extraction GETs advance state. Never use them as connectivity probes, prefetch them or automatically retry them without operation-specific approval.

## Headers

| Header          | Value                               | When                                                                  |
| --------------- | ----------------------------------- | --------------------------------------------------------------------- |
| `Authorization` | `Bearer <synthetic-access-token>`   | Published resource requirement; source enforcement varies.            |
| `Content-Type`  | `application/json`                  | JSON body.                                                            |
| `Accept`        | `application/json`                  | Recommended for this contract; source also configures XML formatting. |
| `Content-Type`  | `application/x-www-form-urlencoded` | Native `/token` password grant only.                                  |

Phase 1 has no mandatory APIM subscription key. Native `Subscription_Key` query parameters on ApiOpenAI operations are not evidence of an APIM key policy.

## Query and path parameters

84 operations have **164 query parameter entries**. Preserve native spelling and casing, including `CtcID`, `BrandID`, `customerid`, `SourceID` and `Subscription_Key`.

Requiredness is separate from type:

* Declared defaults make parameters optional; BI reads declare defaults for `PageSize` and `resetStartProcessDate`.
* URI-bound simple parameters without defaults can be required by Web API action selection before business validation.
* Overloads allow both query variants for CommunicationPreference/Get and Subscription/Get; these are retained in `x-atreemo-query-variants`.
* LoyaltyPoint operations and LoyaltyProgram/Get declare nullable `BrandID` without a default while published prose calls it optional. The contract preserves published optionality and records the conflict pending runtime validation.

`CtcID` remains required for LoyaltyPoint operations and is not `UserID`.

```http
GET /api/LoyaltyPoint/Get?CtcID=1&BrandID=1
```

All four path parameters are integer and required. Preserve published names and segment positions even where CLR parameter names differ.

## Request bodies

All 55 originally fieldless named models now have source-backed members. Recursive `CubeSelection` uses its source public properties and recursive `Items`; do not truncate or invent a maximum depth in the documentation contract.

Important operation-specific constraints include:

* Ignored Company/internal patch-tracking members are not wire properties.
* PATCH omission and explicit null differ; HotelBooking and SalesLeads custom binders track selected keys.
* Event's nested input types can shadow similarly named models; use the action-bound contract.
* Serializable models can expose compiler backing-field names under the configured formatter; do not normalise them.
* `GET /Workspace/InviteUser` has a complex parameter without `FromUri`. The canonical contract therefore retains its JSON request body. It sends an invitation; the example is not permission to call it, and intermediary compatibility remains unverified.
* `DELETE /api/Corporate/RemoveContact` and `DELETE /api/RewardJourneys/RemoveFromRewardJourney` have JSON bodies; forwarding remains unverified.
* Five public GET entries with complex source inputs retain explicit binding questions instead of guessed query expansion.

Synthetic `POST /api/Customer/FindCustomerDetails` body:

```json
{
  "BrandID": 1,
  "SearchFilters": {
    "Email": "customer@example.com"
  }
}
```

`SearchFilters` is required. Use only approved synthetic Staging records.

## Values and brand identifiers

Published value/name lists remain distinct from source enum declarations. Numeric enum names are recorded in evidence extensions without asserting that every other integer is rejected. Special business values, such as `LoyaltyProgram.BrandID = 0`, are not universal enum rules.

Brand access depends on the operation and user's hierarchy. Correct typing and a valid token do not establish permission. See [Permissions](broken://pages/6069938d54cc2d7cacd1a7ecf3fef94e5360c6be), [Authentication](broken://pages/a92d1423ae54b22743d71e7ab5277f8258a1d52c), [Response format](broken://pages/cddb8394b7164be4a0110525fad35e1668e4f9bd) and [Errors](broken://pages/85e546b61406ff3ffac18f135046c2c4b67841e3).


---

# 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/request-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.
