Historical references/Historical API parameters
Historical API parameters and migration
Find handwritten legacy parameters and migrate to team-level keys, explicit application IDs, and generated references.
These archives preserve handwritten documentation from before the generated-reference migration. Check each old endpoint against your deployed version.
- Historical application parameters
- Historical conversation parameters
- Historical knowledge-base parameters
Migration checklist
- Find the operation in your deployment's
/apidoc/systemopenapiand verify method, path, authentication, and parameters. - Create a team-level API key for the current member and provide
body.appIdexplicitly when calling an application. - For clients accepting only a key, use
<apiKey>-<appId>compatibility syntax. Selection priority is request body, Bearer suffix, then legacy key binding. - Verify fixed inputs, conversation ownership, and error handling before moving business traffic.
Legacy application-bound keys can continue supplying a compatibility application selection. Identity proxy requires an enabled team-level credential; see identity proxy.
Edit on GitHub
Last updated