Connect the app to other services
Understand what the app sends, what comes back, and what can fail.
By the end, you can describe an integration's inputs, outputs, failure cases, and usage limits.
Step 1: See the order slip
An API lets parts of an app exchange and replies. The is the service address and action; the is the order slip carrying fields. Write down names, meaning, units, required values, and allowed sizes. A field named amountCents: 1250 means something different from price: 12.50 dollars.
Step 2: Separate rejection from uncertainty
A server may reject invalid input, deny access, limit usage, or fail. A lost leaves the outcome unknown. Use one same-action ticket, called an , for retries of the same payment or booking. The receiver must remember the ticket and result and reject different details attached to that ticket.
Step 3: Bound calls where they happen
Ask the server to input, limit volume, cap size, and keep provider secrets private. Add a finite wait and a limited retry policy. means too many ; respect any Retry-After guidance and show a waiting status. A spending alert reports usage; it is not itself a blocking budget.
Step 4: Check contracts and repeated events
Try invalid input, a denied action, a rate limit, and a lost in a test setup. Check all screens using changed field names or units. A is a provider’s event sent to your server; verify authenticity and recognize repeated event IDs. Do not recreate a saved order just because its receipt email failed.
Interactive System Map
An API call is a trip there and back
Plan both the request the app sends and the response it receives. The response may be data, a rejection, a delay, or an error.
For a server-side integration
Keep private provider keys and important limits in server-side code.
Before implementing, show the and fields, units, , and server-enforced usage limits. For a lost , define an outcome lookup or supported same-key retry. Explain how repeated events are recognized. Keep payment secrets server-side and inspect both checkout and receipt readers after any field change. Illustrative before / after (behavior, not ready-to-run code): - Slow reply → new charge + Slow reply → confirm existing result or repeat the same supported ticket
Same-action protection does not resolve two different people competing for the last item. That is a separate shared availability rule.
Picture it, then try it
Follow one request
Track a parcel through its checkpoints. A button starts the trip; it does not prove the parcel arrived.
Browser button → request: bookId + action → server: verify person + permission → database: save permitted result → reply: saved request ID → browser: show confirmed result
The page says Saved, but you cannot find the . Name two things to check before asking AI to recreate the database.
Compare your reasoning with the worked answer
Repeat one . Inspect its and which database/environment it targeted. Then check the read filter and account permissions. A missing in one view could mean a rejected save, the wrong environment, or a view that hides an existing result. Ask AI to report evidence at each checkpoint.
Picture it, then try it
Read the reply before retrying
A service counter can say your form is invalid, your badge is missing, access is denied, or the queue is full. Each calls for a different action.
400 → inspect invalid input 401 → inspect missing/invalid sign-in 403 → inspect denied permission 429 → wait according to retry guidance 5xx → inspect service failure; retry only if safe
A paid service returns 429 and Retry-After: 30. Should you retry every second or wait?
Compare your reasoning with the worked answer
Respect the 30-second guidance, show a waiting status, and bound the number of attempts. Do not treat rejection as success. For a payment or booking, retain the same intent and resolve unknown outcomes. Not every error should be retried. A spending alert reports cost but does not automatically block it.
Picture it, then try it
Agree on the envelope, including its units
A delivery form must say grams or kilograms. A number without its meaning can be interpreted a hundred times too large or small.
Old response: amountCents: 1250 New response: price: 12.50 (dollars) Readers: checkout + receipt + open old tabs Compatible support → move readers → verify → retire old field
AI says a receipt can guess cents from decimal places. Find a price that makes that rule fail.
Compare your reasoning with the worked answer
A price of 12 dollars can be written as 12, without a decimal point. Names, units, required values, and formats must be explicit. Find affected readers and keep compatible support while moving them. With an , also ask which existing the conflict target matches and which fields it overwrites; a successful write can still replace valuable data.
Sources and further reading
A form calls a paid AI service. The AI disabled the button during a . Which additional plan best protects the bill?
Choose one answer.