HTTP API
Use the customer reference for supported operations, authentication requirements, request shapes and error behavior.
Read the API guide →Connect a supported workflow to explicit authority and inspectable records. Start with the interface, the access requirements and the behavior you can test.
Self-service is the intended primary path. Start with the public documentation and controlled example without a sales call. Current authenticated product access is a scoped private preview; onboarding, checkout and supported integrations require separate verification.
Use the customer reference for supported operations, authentication requirements, request shapes and error behavior.
Read the API guide →Connect a compatible client to the supported tool interface. Your account and grants determine what becomes available.
Read the MCP guide →The read-only discovery request in the getting-started guide returns the advertised authorization server and supported scope. It needs no credentials.
Request preview access for one workflow. Confirm the principal, resources, permissions and environment before attempting authenticated operations.
Exercise a permitted operation and a refusal, then inspect the available record. Coverage is limited to the routes and conditions tested.
Authority and evidence are the current technical foundation. Full asset recovery, replacement-team handoff and broad provider portability are development goals. The documentation distinguishes current interfaces, controlled demonstrations and planned work.
Do not send credentials in a URL, a support message or a code example. Use the documented authentication mechanism for the environment you were given.
Review the evidence and limitations →Agree the supported observation points, records and acceptance checks for evidence capture or an outcome report. Response decisions and remediation stay with your team and its chosen providers.