sdk invoke exists for the moment before you trust something: a freshly applied version, a rotated credential, a new operation in a pipeline. It resolves one exact SDK version, calls the Engine with your execution token, and prints what came back.
Call something
sdk invoke never picks a version for you, which is the property that makes it useful in CI.
--params. Any JSON option also accepts @file, or - for stdin, which keeps large payloads and anything sensitive out of your shell history.
In a pipeline
Keep the token out of the environment where you can, and gate on the structured output rather than the exit code alone.--json prints the endpoint, kind, results, rollbacks, and timing, so a job can assert on what actually ran. A stable --idempotency-key keeps a retried job from counting as a second logical request.
Flags
The token comes from
FUSED_SDK_TOKEN unless you redirect it. Management credentials and provider credentials are never substituted for it.
Unified operations
A unified operation runs across several services in one call. Invoking one requires explicit targets, and never defaults to every declared target:Limits worth knowing
This is a debug surface, not a production transport. It accepts one buffered JSON provider document up to 1 MiB, and bounds a Unified aggregate at 17 MiB. Generated SDKs keep their broader gRPC transports, so a payload that fails here may be perfectly fine from your application. It produces one logical Engine execution and does not retry locally or follow redirects itself — the Engine owns retries, pagination, and continuation.Read the receipts
sdk activity shows what every execution did, whichever route made it.