FG API

Appearance

Step 5: Response Configuration ​

Response configuration defines what callers get back from your endpoint: success payloads, error behavior, status codes, and—where your flow includes them—structured outputs from the recommendation pipeline.

Overview ​

In this step you typically:

  • Choose how successful requests are shaped (data included, formatting)

  • Decide how errors are surfaced (status codes, bodies, logging)

  • Align downstream consumers (forms, apps, webhooks) with a stable contract

For low-level HTTP and error codes, see the Error handling reference.

Success responses ​

Successful responses should be predictable so integrations can parse them without special cases.

  • Prefer a consistent JSON shape per endpoint (same top-level keys for the same operation).

  • Document which fields are always present vs optional.

  • If your flow returns product or AI-generated content, keep field names stable across deploys when possible.

Error responses ​

Errors should be actionable for both humans and automation.

  • Use appropriate HTTP status codes (e.g. 400 for validation, 401 for auth, 500 for unexpected server faults).

  • Return a body that explains what failed and, when safe, which field or rule triggered it.

  • See Error handling for status codes, patterns, and troubleshooting.

Headers and metadata ​

Depending on your deployment, you may rely on:

  • Content-Type (application/json for JSON bodies)

  • Caching headers if you serve cacheable public data

  • Correlation IDs or request IDs if your platform adds them for support and logging

Document any required headers for callers in your integration notes.

Testing responses ​

Before going live:

  1. Send valid sample payloads and confirm the success body matches your contract.

  2. Send invalid payloads (missing fields, wrong types) and confirm status codes and error bodies.

  3. Continue to Step 6: Testing & Deployment for a full checklist.