Pydantic Strictness in Third-Party APIs
The project relies heavily on pydantic for modeling. While excellent for internal APIs, strictly validating payloads from external, proprietary enterprise systems (like iMednet) is highly fragile. Enterprise APIs frequently deploy silent, undocumented payload changes, such as adding new keys or returning null instead of empty strings. If the SDK models are strictly typed without fallback mechanisms, a minor upstream update will instantly break data pipelines relying on this library.
Actionable Solution: Ensure every Pydantic model is configured with model_config = ConfigDict(extra='ignore'). Utilize permissive typing (e.g., Optional[Any]) for any field that is not strictly required for routing or authentication to ensure the SDK does not crash simply because the API returned an unexpected telemetry field.
Pydantic Strictness in Third-Party APIs
The project relies heavily on pydantic for modeling. While excellent for internal APIs, strictly validating payloads from external, proprietary enterprise systems (like iMednet) is highly fragile. Enterprise APIs frequently deploy silent, undocumented payload changes, such as adding new keys or returning null instead of empty strings. If the SDK models are strictly typed without fallback mechanisms, a minor upstream update will instantly break data pipelines relying on this library.
Actionable Solution: Ensure every Pydantic model is configured with model_config = ConfigDict(extra='ignore'). Utilize permissive typing (e.g., Optional[Any]) for any field that is not strictly required for routing or authentication to ensure the SDK does not crash simply because the API returned an unexpected telemetry field.