> 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/workflows/testing-and-support.md).

# Testing and support

Offline validation boundaries, runtime test gates and safe support evidence

{% hint style="warning" %}
**Not approval to test, publish or release.** Documentation and offline validation do not authorise product/token requests, invitations, messages, gateway registration or deployment. No target-environment call was performed for this documentation.
{% endhint %}

## What offline checks establish

Offline checks can verify OpenAPI structure and references, inventory, examples, source citations, links and documentation consistency. Examples are synthetic. Static results do not prove an instance accepts requests, uses the pinned assemblies, applies the same permissions or returns identical status/header/body values.

The source baseline is commit `ea9cb106e13aa4b9b92c01d090118742b44dd470`. The contract derives from public API **1.34.0.0 / Release1.34** and contains 217 operations on 212 paths. Read-only investigation says the current non-production Atreemo environment runs **Release1.35**. Runtime compatibility with Release1.35 remains to be validated.

## Remaining findings

* **Native names versus lint policy:** native parameter casing must be retained. Spectral findings must be reported, not hidden by renaming parameters or weakening rules.
* **Bodyless successes:** AppRemovePushNotificationToken, CompanyAddComment, CompanyDeleteCompany and SocialApproveSocialCampaign truthfully have no success body in inspected source. The owner must resolve the repository's blanket response-model policy conflict.
* **Dynamic rows:** three Selection results truthfully use open `DataTable` rows. Publishing format-specific schemas requires owner-approved evidence; columns must not be invented.
* **Runtime alignment:** deployed version/build, authentication branch/provider, serializer dependencies, method/brand permissions, errors and three `BrandID` optionality conflicts need validation.
* **Workspace GET body:** canonical `WorkspaceInviteUser` retains its source-backed request body and side effect. Client/intermediary forwarding is not established.
* **Publication and routing:** examples use the Staging resource base; the Production resource base is used only after separately approved release steps. Endpoint availability and routing behaviour require staged release validation.

## Prepare an approved non-production test

Confirm the target Atreemo instance and its release through the approved Atreemo support and onboarding process. Obtain least-privileged identities and synthetic fixtures through an approved channel; never retrieve production credentials or customer records to complete documentation.

| Area                | Required evidence                                                                                                   |
| ------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Contract            | Success, failure, early-return and boundary cases; native casing; status/header/body and bodyless behaviour.        |
| Authentication      | Applicable native/provider path, invalid/expired credentials, lockout and returned lifetime without unsafe retries. |
| Permissions         | Allowed/denied method and brand contexts; `UserID` versus `CtcID`; shared mappings.                                 |
| Data and binding    | Required/nullable/omitted inputs, GET/DELETE bodies, dates and source/publication conflicts.                        |
| Paging and recovery | First/last/out-of-range batches, lost responses, duplicates, resets, concurrency and export cleanup.                |
| Operational safety  | External sends/triggers, privacy-safe telemetry, routing, cache/rate-limit behaviour, latency and errors.           |

Define exact expected results and objective pass/fail/rollback thresholds before testing. Unexpected authorisation, routing, response equivalence or privacy outcomes must stop promotion. Set thresholds from a known-good baseline rather than inventing an SLA.

GET is not a safe-test category. Workspace invitations, social approval, WhatsApp checks, event attendance, AI generation and stateful extracts require operation-specific review.

## Release gates remain separate

1. **Owner review.** Identify API, authentication, gateway, publishing, shared-component and affected-consumer owners and recent human authors. Obtain owner/delegated-maintainer review; record any ownership gap.
2. **Blast radius and live baseline.** List affected routes, APIs, environments, identities, data flows, consumers and artifacts. Assess failures, privacy/security, performance/cost and non-atomic publication/deployment. Verify live state rather than equating it with Git.
3. **Before/after tests.** Review fixtures, equivalence checks and measurable pass/fail/rollback thresholds. Static validation is not a substitute for target-platform/runtime evidence.
4. **Rollback.** Agree the exact last-known-good artifacts/actions, owner, triggers and verification. Documentation rollback does not undo invitations, messages or business transactions.
5. **Explicit action approval.** State the exact action, artifact/PR, target environment and side effects. Release and deployment approvals are separate.
6. **Staged validation.** Validate in Staging before Production, using approved synthetic fixtures and separately approved release steps.

## Request support safely

Start with the approved Atreemo support and onboarding contact that supplies the instance URL and access. No support email, response-time SLA or credential endpoint is established in this documentation.

Provide only approved, redacted evidence: environment label, operation ID/method/path, UTC observation time, document/source revision, expected versus observed status/business outcome and minimal non-sensitive differences. Include approved correlation identifiers only if actually returned.

Never include passwords, bearer tokens, cookies, connection strings, full customer payloads, raw exports or unsanitised browser evidence. Ask for a safe channel and synthetic reproduction.


---

# 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/workflows/testing-and-support.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.