Course Map
This course teaches frontend teams how to build regulated product workflows on top of the KYC API.
The course is now organized as topic pages. You can read it from start to finish, but you do not have to. Each page gives enough context to work on that topic directly, then links to the pages that naturally come before or after it.
What You Will Be Able To Build
After working through the course, you should be able to:
- Configure a browser application without leaking secrets.
- Build a typed TypeScript client for protected KYC API calls.
- Diagnose connectivity, readiness, and authentication problems.
- Render API errors as useful product states.
- Build quick screening as evidence, not a final decision.
- Create durable case workspaces.
- Save one case section at a time.
- Generate and read report snapshots.
- Display workflow progress without treating events as the compliance archive.
- Keep generated recommendations separate from human review decisions.
- Adapt the same integration pattern to banks, fintechs, insurers, lenders, marketplaces, and other regulated products.
Start Here
Use these pages first:
- Big Picture explains the product architecture and the learning path.
- Integration Boundary defines what the frontend should and should not know.
- Environment Configuration lists the public configuration values a frontend app needs.
- API Client gives the reusable TypeScript request wrapper used by every screen.
Choose A Workflow
If you are building a concrete product surface, start with one workflow:
| Goal | Start with |
|---|---|
| Show API status and user access | Read-Only Dashboard |
| Collect user or applicant details | Case Intake Form |
| Support analyst or reviewer work | Reviewer Workspace |
| Prepare a regulated frontend for release | Launch-Ready Frontend |
Each workflow links to smaller task pages instead of repeating the same implementation guidance.
Topic Types
The course uses predictable topic types:
| Topic type | Purpose |
|---|---|
| Big picture | Explains the full system and how the pages fit together. |
| Workflow | Shows an end-to-end product path and links to task pages. |
| Foundation | Establishes a reusable boundary, type, client, or state model. |
| Task | Builds one API-backed feature. |
| Quality | Verifies accessibility, audit readiness, tests, and launch safety. |
How To Use A Topic Page
Every implementation page follows the same rhythm:
- Use this when tells you whether the page matches your problem.
- What you will build defines the visible outcome.
- What must already be true lists the prerequisites.
- API contract names the endpoint or data shape.
- UI states turns API behavior into product behavior.
- Implementation steps gives the build sequence.
- Checkpoint gives a clear stopping point.
- Common mistakes prevents predictable integration bugs.
- Related pages points to adjacent work.
This keeps each page useful when reached from search, a teammate’s link, or an LLM coding agent.
Stable Implementation Order
When in doubt, build in this order:
configuration -> API client -> diagnostics -> errors -> screening -> cases -> reports -> review
Do not build every screen at once. Finish one visible layer, run its checkpoint, then move to the next layer.
Final Teaching Pattern
Use this sequence when coaching a frontend team:
- Prove the API is reachable.
- Prove authentication works.
- Prove structured errors are useful.
- Render evidence without making a decision.
- Persist the case.
- Save one section at a time.
- Generate the right report view.
- Show progress while work is active.
- Require an accountable human decision.
- Verify the customer-facing view hides restricted data.
That sequence turns an API integration into a reliable product workflow.