API reference
Use a stored snapshot to inspect the contract captured with that file. The generic reference below preserves complete selected public operations and generic schemas; it is deliberately incomplete. Exact customer integration operations, callback schemas and identifiers remain in the permitted integration edition. Documentation access permissions do not enable an API feature in the product deployment.
A filename release label and the version inside its JSON are separate evidence.
In particular, some earlier stored files declare edge. Do not infer a verified
release export from their filename or substitute a later snapshot when one is
missing. Profile names describe stored export inputs, not proof that your target
has the same routes or flags enabled.
The historical full JSON and HTML URLs remain assigned to protected exact references. Sign in through your documentation account with the required customer/module permission before following an integration contract link. The protected HTML is rendered from the matching retained JSON with actual schema anchors; it does not depend on the old external interactive renderer. Public selected downloads are labelled separately so clients do not mistake them for the complete API specification.
Why this isn't the live /documentation
A live endpoint describes the specific deployment and its enabled routes at the time it is queried, if that deployment exposes documentation. A retained file is stable evidence of its own stored schema; it is not evidence that the deployment still runs that version or that every declared response was exercised. Use the selected release instructions and actual deployment configuration to decide what is available. Do not export production documentation into a public repository without checking its visibility.
See also
- Generic HTTP integration — authentication and availability workflow.
- Release identity and compatibility — declarations, running artifacts and acceptance are separate.