fix: allow null values in the ManagedConfig schema

[leggetter]

Problem

On managed Outpost, GET /config returns null for keys that aren't set (51 of 73 keys in one project). The ManagedConfig schema declares every property as type: string, so the generated SDKs reject the response. With @hookdeck/outpost-sdk 1.7.0:

const outpost = new Outpost({ apiKey });
await outpost.configuration.getManagedConfig();
// ResponseValidationError: Response validation failed
// DESTINATIONS_AWS_KINESIS_METADATA_IN_PAYLOAD: Expected string, received null
// ... 51 issues

The same schema is the PATCH /config request and response body. The PATCH docs say "Null values clear the configuration", but the SDK types don't allow sending null, and the response fails validation in the same way.

Change

Every ManagedConfig property is now type: [string, "null"], the OpenAPI 3.1 form (this spec is 3.1.0). Spec only: the SDKs pick it up when they're regenerated on the next release.

Testing

• speakeasy lint openapi: same result as main (0 errors).
• Regenerated the TypeScript SDK locally (speakeasy run -t outpost-ts, not committed). The schema becomes z.nullable(z.string()).optional(), and the type string | null | undefined.
• With that regenerated SDK against managed Outpost: getManagedConfig() parses the response (73 keys, 51 null), and updateManagedConfig() round-trips a no-op update.
• spec-sdk-tests runs against self-hosted Outpost, which has no /config, so it can't cover this endpoint.

Notes

• For SDK users, these fields widen from string | undefined to string | null | undefined. Strict TypeScript code reading them may need a null check, and Speakeasy may version that as a breaking change.
• A few other properties in the spec still use the 3.0-style nullable: true. Speakeasy accepts both; I left them alone.

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🟢 Approval recommended

The schema change consistently matches the documented and verified managed API behavior.

Review effort: Balanced
Findings: None

What changed in this PR

Review summary

Updates the OpenAPI schema to accurately represent nullable managed configuration values.

Changes:

• Allows all 73 ManagedConfig properties to accept strings or null.
• Enables generated SDKs to validate responses and send configuration-clearing updates.

File	Description
docs/​apis/​openapi.yaml	Makes managed configuration properties nullable using OpenAPI 3.1 syntax.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[leggetter]

@alexluong - you may have better insight into what should actually be allowed to be null rather than this blanket approach.

[alexluong]

Thanks Phil. The blanket approach is right. GET returns null for any key that has no override and no default, and PATCH accepts null on every key to clear it. Since one schema covers the request and both responses, every property needs to be nullable. LGTM.

One thing for the release notes: in the Go SDK every ManagedConfig field changes from *string to optionalnullable.OptionalNullable[string], so existing Go code breaks (DeliveryTimeoutSeconds: outpost.String("45") becomes optionalnullable.From(outpost.String("45"))). TS and Python only widen the type.