[Medium] SDK Sync: Add Opal Token retrieve/deactivate + report types

[mack-ship-it]

Medium — Missing Operations

• Opal Token: Add and methods (only had )
• Reports: Add and types

Part of the SDK sync split.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9f73c306dc

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Use the authenticated Opal token route

The Method OpenAPI spec defines retrieveOpalToken and deactivateOpalToken on GET/DELETE /opal/token with OpalToken bearer auth and no path parameter (see latest/openapi.bundled.json in https://github.com/MethodFi/openapi); passing _id to _get_with_id/_delete makes the SDK call /opal/token/{id} using the parent client's secret-key Authorization, so these newly exposed methods return 404/401 instead of retrieving or deactivating the authenticated Opal token.

Useful? React with 👍 / 👎.

[mack-ship-it]

Codex Review Assessment

Comment 1 (P2) - Opal Token retrieve/deactivate using _get_with_id/_delete with path parameter:
Valid concern. The OpenAPI spec shows retrieveOpalToken and deactivateOpalToken operate on GET/DELETE /opal/token (no path parameter) with OpalToken bearer auth, not GET/DELETE /opal/token/{id} with secret key auth. However, the Node SDK implementation uses the exact same pattern (passing an ID to _getWithId/_delete). Both SDKs are consistent. This may need to be addressed in both SDKs together, or the spec may be incomplete. Flagging for Geoffrey to confirm the correct behavior.