You need to build an integration against a customer's legacy REST API that returns inconsistent schemas and has no sandbox environment. How do you approach it?
Quick Answer
Treat the live API as an untrusted, unstable contract: capture and version real sample responses, build a defensive parsing layer that tolerates missing/extra/renamed fields, add strong logging around every unexpected shape, and negotiate a low-risk testing window with the customer instead of assuming a stable spec.
Detailed Answer
Legacy customer APIs are rarely documented accurately, and without a sandbox you're integrating against production — so the first priority is reducing blast radius. Capture real request/response pairs early (with the customer's permission) and build a small local fixture set from them; write your parser against those fixtures rather than an idealized spec. Make deserialization defensive and explicit: validate required fields, tolerate unexpected/extra fields, and fail loudly (with context) rather than silently coercing bad data.
Agree with the customer on a safe testing pattern: a low-traffic time window, a specific test account/record range, or read-only endpoints first. Add structured logging that captures the raw response shape whenever parsing hits an unexpected case, so schema drift shows up as an alert instead of a silent data corruption. Where possible, push back gently: ask if they have a staging instance or can point you at historical data exports instead of live production traffic.
Code Example
# Defensive parsing pattern for an unstable legacy API
def parse_customer_record(raw: dict) -> Record:
missing = [f for f in REQUIRED_FIELDS if f not in raw]
if missing:
log.warning("legacy_api.missing_fields", missing=missing, raw_keys=list(raw.keys()))
raise SchemaDriftError(missing)
return Record(
id=str(raw["id"]),
# tolerate alternate field names seen across environments
status=raw.get("status") or raw.get("state") or "unknown",
updated_at=parse_flexible_date(raw.get("updated_at") or raw.get("last_modified")),
)Interview Tip
Show that you plan for schema drift as the default, not the exception — that mindset is what separates FDE integration work from typical greenfield API work.