You run a platform that pays creators, and you have been told to verify people before money moves. You are weighing whether identity checks belong in a separate vendor or somewhere closer to the payouts code. So you open Whop's tutorial on how to integrate a KYC verification API into your platform, and you find it makes one argument and then builds it in Next.js: if you are verifying people because you are going to pay them, the KYC check should live inside the payouts API.
The flow is short. One call starts a verification against an account. Whop returns a record whose ID starts with idpf_, plus a link to a Whop-hosted page. The person finishes the check there, and approval switches on payouts for the same account. You do not stitch two systems together.
The line worth keeping, the post says, is the takeaway: "Treat webhooks as change signals only, re-reading the record before writing any verification status." You would write that on a sticky note. There are no vendor figures in the tutorial to discount, only engineering advice, and most of it is good on its merits.
You read on and the advice keeps being practical. The tutorial asks for narrow key scopes: identity:write, identity:read, and webhook_receive:identity_profiles. It passes an idempotency key on create. It validates every environment variable on startup. It handles the action_required state a reviewer can come back with before money moves, which is the case you would probably forget until a payout stalled.
Then it flags a quiet trap. Older SDK option names like apiKey and baseURL are "silently ignored" in plain JavaScript, "which sends every call to production instead of the sandbox environment." You have the sandbox in mind for testing, so you stop and check your own config. That, the post notes, is exactly the kind of sentence a provider rarely writes about its own SDK.
Now you do what you would do before committing: you look Whop up in the APIs.io catalog. Whop there carries 12 API pages, and the payout half of the story is present. You find the Whop Payments API, the Whop Transfers API, the Whop Companies API that owns the biz_ accounts being verified, the Whop Users API, and the Whop Webhooks API that delivers the result events.
What you do not find is the thing the tutorial is about. The verifications surface itself, the verifications.create and verifications.retrieve calls, has no API page. The agentic access profile counts 51 operations, 30 of them acting, and none of them is the identity check. The catalog has not mapped it.
The post turns that gap back on the catalog's own record, and the measurement explains why. Whop scores 21.2 on the Kin Score, emerging. Discoverability is 66.1 and developer ergonomics is 32.1, while access clarity is 7.9 and operational transparency is 13.2. Agent Readiness is 38.6, agent-ready, with MCP server, delegated identity, protected resource metadata and dynamic client registration lit.
Idempotency and error semantics are unlit. Yet the tutorial you just read passes an idempotency key and documents a 404 on an unknown record. So Whop is writing a better contract in its blog than the one the catalog can measure. The post's conclusion is that the fix is a published spec for identity, not better prose.
You take two things away. First, the design: keep the check next to the payout, re-read the record before you trust a webhook, and test against sandbox only after confirming your SDK options are not being ignored. Second, the caution: the catalog's silence on verifications is a limit of what has been mapped, not proof the calls are missing, because the tutorial shows them working. Until Whop publishes a spec for identity, the blog post is your contract, and you should treat it that way.
Read the original: https://apis.io/2026/11/04/whops-kyc-tutorial-walks-an-identity-api-the-catalog-has-not-mapped/