How this differs from the API Reference tab
The API Reference tab documents endpoints you call on Atonom — for example scheduling a meeting or creating a contact. Those requests go to Atonom with your API credentials. This Integration Connectors tab documents the opposite direction: endpoints your server must implement so Atonom can invoke connector actions you configure in the dashboard. Atonom calls your infrastructure when a Cloud Employee or workflow triggers an action.About this reference
The operations listed here are not live Atonom-hosted URLs. They document an illustrative contract: the kinds of HTTP (and, where applicable, gRPC) handlers your infrastructure should implement. Path names and base URLs in the spec exist to show shape and semantics, not to point at a service you can call as-is.Generating implementation code
You can and should generate clients, servers, types, or validators from the Integration Connectors OpenAPI definition openapi.yaml using your preferred toolchain (for example OpenAPI Generator,openapi-typescript, or protoc plugins where gRPC is involved). That keeps your implementation aligned with the documented request and response models and reduces drift as the contract evolves.
Errors that should be stored as logs
When a connector action fails in a way that should appear in Atonom logs (as opposed to only a generic failure), use one of the following patterns:- gRPC — Return a normal gRPC error status on the RPC. Atonom can treat that as a loggable failure path when you follow the connector contract for your action.
- HTTP — Return a response that includes the error. Put a short, operator-safe explanation in the header value.