Department apps call a shared city GenAI API that must stream tokens and surface token-limit errors clearly. Which application-integration design addresses those GenAI-specific failure modes?

Department apps calling a shared city GenAI API face GenAI-specific failure modes: streamed token delivery and hard token or context limits. The correct application-integration design is an FM-facing API contract that supports streaming responses and returns explicit token-limit or context-overflow error codes so callers can recover—shorten context, chunk, or notify users—instead of guessing. Civic platforms that wrap Bedrock should expose these behaviors as first-class contract elements, not as accidental side effects of opaque HTTP 200 bodies.

Returning only opaque 200 OK bodies with no streaming and no error detail when limits are hit fails by concept: clients cannot distinguish success from truncated or refused generation. Forcing every client to call Bedrock directly with long-lived keys embedded in mobile apps fails on security and governance—keys proliferate and the city loses a central policy enforcement point. Collapsing all GenAI errors into a single generic “try again later” string with no machine-readable code prevents automated backoff, user messaging, and correct remediation.

Exam caveat: streaming and typed errors are API design concerns; they do not by themselves enforce content safety or tenancy isolation. Token-limit errors should be stable, documented codes (not free-text only) so disparate department SDKs handle them uniformly. Clients must still authenticate to the shared city API rather than holding FM credentials.

Operational check: from a department test client, consume a streamed completion and assert incremental chunks; force a context overflow and confirm a distinct token-limit or context-overflow code; verify mobile or web apps never embed Bedrock long-lived keys and only call the shared municipal API.