MyOpsAgent API & Integration Reference

1. Integration Types

Website / Digital Agent

A customer-facing agent can be embedded into an approved website. Browser-facing access should use only credentials or identifiers explicitly issued for that purpose and may be restricted to approved domains.

Server-to-Server API

Backend systems can exchange approved business context or invoke enabled capabilities using organisation-scoped authentication. Server credentials must never be exposed in public JavaScript, source control or client-side storage.

Module & Tool Integrations

Enabled modules can expose organisation-specific tools for actions such as checking availability, creating a booking, retrieving operational state or carrying out another permitted workflow step.

2. Authentication & Scope

Integrations are scoped to an organisation. Authentication requirements depend on whether the request originates from an approved browser deployment, an authenticated user session or a trusted server-to-server integration.

Authorization: Bearer <organisation-scoped credential>
Content-Type: application/json

The exact header name or credential type may vary by integration. Use the credentials and examples issued with the enabled module rather than assuming a public example is the active contract.

3. Request Model

A controlled integration request should identify the intended operation and provide only the context required for that operation. Organisation identity is derived from authenticated scope and must not be trusted solely from user-controlled payload fields.

{
  "operation": "check_availability",
  "input": {
    "service": "Example service",
    "requested_date": "2026-10-08"
  },
  "context": {
    "channel": "customer_agent"
  }
}

4. Response Model

Responses should distinguish normal information, a permitted action result and a controlled decision that requires approval or further workflow.

{
  "status": "ok",
  "correlation_id": "example-correlation-id",
  "result": {
    "type": "availability",
    "data": {}
  }
}

Fields shown here are illustrative. Module-specific contracts may add identifiers, validation state, decision references, approval status or UI hints.

5. Controlled Decision Workflows

Some integrations retrieve or update straightforward business data. Others initiate a governed decision. In the latter case the platform can separate:

1. the recorded business change or request;
2. the consequence analysis;
3. the recommended valid plan;
4. human approval where required;
5. authorised execution; and
6. verification of the resulting state.

A conversational response must not be interpreted as proof that an operational action has been executed. Use the workflow status or execution record returned by the relevant controlled capability.

6. Errors & Correlation IDs

Integrations should treat non-success responses as structured failures and retain any correlation or request identifier supplied by the platform. See Integration Errors & Safe Failure Behaviour for the public error model.

7. Integration Security

• Keep server credentials outside browser code and source control.
• Use HTTPS for all production integration traffic.
• Apply least-privilege scopes and enable only the tools a workflow requires.
• Validate webhook or callback authenticity where those mechanisms are enabled.
• Do not bypass organisation, identity, permission or approval checks in client code.
• Log correlation identifiers rather than sensitive payloads unless your data policy permits it.
• Rotate or revoke credentials when staff, systems or environments change.

8. Versioning

Integrations should rely on the contract supplied for the enabled module and environment. Breaking changes should be introduced through an explicit version or migration path rather than silently changing an established integration contract.