i01-api-fundamentals

Q1 multiple-choice · auth-header

In PhotoRobot API V2, how is the API key passed to authenticate a request?

A) Query string ?api_key=...
B) HTTP header Authorization: Bearer <api-key>
C) Cookie pr_api_key=...
D) POST body field api_key

Explanation: V2 requires the API key in Authorization: Bearer <api-key> header. V1 supported query-string ?api_key=... but that’s deprecated in V2 — never put credentials in URLs (they leak into server logs, browser history, referer headers). Cookie + body-field auth are not used by PhotoRobot.

Q2 multiple-choice · response-wrapper

A V2 list endpoint returns items where exactly in the response?

A) At the root of the JSON object
B) Under the data key
C) Under the results key
D) Under the items key

Explanation: V2 wraps responses in a { "data": [...], "meta": {...}, "links": {...} } envelope. The actual payload is in data. V1 returned items at the root; this is one of the most common migration footguns when moving V1 → V2.

Q3 scenario · v1-v2-migration · weight 2

You’re maintaining a V1 integration that parses item objects directly from the JSON root (response.id, response.name, etc.). You migrate to V2 and your integration silently breaks — no parse errors, no exceptions, just empty results.

A) V2 doesn’t return the items at all — they were deprecated
B) V2 wraps responses under a data key. Code reading response.id finds undefined; need response.data.id (or response.data then iterate).
C) V2 requires XML instead of JSON
D) V2 requires a different HTTP method

Explanation: The data wrapper is one of the named V2 migration footguns. Integrations that silently look at the wrong path get empty results without explicit errors. Fix: update all parsers to expect data envelope. Migration tip from §4: do this before migrating the call code — keeps error handling consistent.

Q4 multiple-choice · rate-limit-header

PhotoRobot’s API returns a 429 status code. Which header tells you how long to wait before retrying?

A) X-Wait-For
B) Retry-After
C) X-RateLimit-Reset
D) Cooldown

Explanation: Retry-After is the canonical HTTP header (per RFC) for “wait N seconds before retrying”. PhotoRobot uses it on 429 responses. X-RateLimit-Reset is also present but is the timestamp when the window resets, not the recommended pause. Production integrations should honor Retry-After and combine it with exponential backoff for resilience.

Q5 multiple-choice · backoff-jitter

Why is jitter important in exponential backoff for API retries?

A) It makes the backoff faster
B) It’s required by the HTTP spec
C) Without jitter, many concurrent integrations retry at exactly the same time after a 429, overloading the recovery window — jitter spreads them out
D) It logs the retry attempts more clearly

Explanation: When many client integrations all back off after a 429 with exactly Retry-After + base_delay, they all retry at the same moment and immediately re-trigger rate limits. Random jitter (e.g., adding Math.random() * 1000 ms) spreads the retry herd across a wider window so the recovery window is not slammed.

Q6 scenario · monitoring-contract · weight 2

Your team built a PhotoRobot integration 8 months ago, deployed it, and moved on. Today, a customer complains their items aren’t reaching the DAM. You check the integration’s logs and discover it has been silently failing for 6 weeks — every webhook returns 500 from the DAM and PhotoRobot has been retrying (and failing) ever since.

A) The DAM has a bug — switch DAM vendor
B) PhotoRobot’s webhook spec changed — update the webhook handler
C) A monitoring contract was missing — named owner who notices breaks, named fixer, alert thresholds, response-time SLA. The fix is structural: every integration MUST have a monitoring contract signed before production deploy.
D) The customer should have noticed sooner

Q7 multiple-choice · request-id-logging

Why is logging the request_id from V2 error responses important?

A) It’s required for compliance audit
B) It lets PhotoRobot support trace the call server-side when you escalate an issue — without it, support can’t correlate your report with server logs
C) It prevents 429 errors
D) It’s used for OAuth token refresh

Explanation: When you escalate “this call failed with error X” to PhotoRobot support, the request_id is the single most valuable piece of information. It tells support exactly which call in their server logs to look at — without it, they have to guess based on timestamp + endpoint + customer, which is much slower. Always log it.

Q8 scenario · polling-vs-webhook · weight 2

Your integration polls GET /api/v2/items?modified_since=<timestamp> every 30 seconds to detect new or changed items. The integration works but consumes a large fraction of the customer’s rate-limit quota.

A) Increase the polling interval to 5 minutes
B) Switch to GET requests with If-Modified-Since header
C) Subscribe to PhotoRobot webhooks for item events. PhotoRobot pushes events to your handler when items change — no polling overhead, near-real-time, much less rate-limit consumption.
D) Use a different API key

Q9 multiple-choice · api-key-storage

Where should a PhotoRobot API key be stored?

A) In source code, with a comment “remember to rotate”
B) In a config file checked into git
C) In a secrets vault (env variable, AWS Secrets Manager, GitHub Actions secret, etc.) — never in source code, never in client-side JavaScript
D) In the browser’s localStorage

Q10 scenario · phased-rollout · weight 2

You finished building a PhotoRobot integration for a customer with 200 PhotoRobot studios. QA passed all tests in staging.

A) Deploy to all 200 studios simultaneously — the customer needs it live everywhere
B) Phased rollout: 1 pilot studio for 1-2 weeks → cohort of 5-10 studios for another 1-2 weeks → general availability. Monitor metrics between phases.
C) Roll back to manual export and never deploy
D) Deploy to 50 % of studios first, then the other 50 %

Q11 true-false · data-wrapper-presence

PhotoRobot API V2 returns single-resource responses without a data wrapper — only list endpoints wrap.

True
False

Explanation: Both list AND single-resource endpoints wrap responses under data. List endpoints return { "data": [...], "meta": {}, "links": {} }; single-resource endpoints return { "data": { ... } }. Consistent wrapping simplifies client parsers — one envelope shape for everything.

Q12 multiple-choice · contract-tests

What’s the purpose of running contract tests against the PhotoRobot OpenAPI spec in your CI pipeline?

A) To improve test coverage stats
B) To detect when the PhotoRobot API spec changes, before those changes break your integration in production
C) To replace integration tests
D) To bypass rate limits

Ready to commit? You can review and change your answers before submitting. Once submitted, this attempt is final and we'll show you your score, correct answers, and explanations.