Inbound is REST plus CloudEvents; there is no third path. A partner webhook is normalised into a CloudEvent by the trigger service, so the execution path never learns about partner-specific formats.
Every outbound call carries correlationId and taskExecutionId as headers, and the taskExecutionId doubles as the Idempotency-Key where the downstream supports one. That header is the entire duplicate-suppression contract (view 17).
Outbound credentials are managed identity first, Key Vault second. A downstream that requires a static credential is an exception recorded against the integration, not the default.
Numbers that constrain the design
Customer 360 accepts 400 rps, the identity SaaS 50 rps, the LLM gateway is token-budgeted per tenant per hour. These ceilings, not the worker fleet, determine real throughput.
Scaling workers past a downstream ceiling converts throughput into 429s and retry storms. That is why view 24 stops scaling when a circuit opens, rather than continuing to add pods.
180 registered HTTP endpoints share one generic handler, distinguished only by configuration held in the workflow definition.
Risks
Downstreams that cannot honour an idempotency key force the handler into non-retryable mode, so a transient failure becomes a dead-letter. Which systems these are is an open item for the client to confirm.
The nightly warehouse extract is a batch coupling that will age badly. It is V1 pragmatism, with the change feed already in place to replace it with a stream.
Partner webhook HMAC keys are the only long-lived shared secrets in the design. They are in Key Vault with a 90-day rotation, and rotation is an operational process rather than an automated one.
