The Due KYC API is the onboarding half of Due, a London-founded payments infrastructure company that bridges banking rails and blockchain networks for cross-border transfers and fiat-to-stablecoin ramps. Before an account can move money, it has to get through KYC or KYB, and this API is how you drive that. Every one of its 17 operations documents exactly one response: 200 OK.
That is the finding. A verification flow is mostly made of things that go wrong: a document that fails, an applicant who is missing information, a submission that is not ready to complete. The contract describes none of them.
What the API covers
The contract is OpenAPI 3.2.0, with a production server at api.due.network and a sandbox at api.sandbox.due.network, and bearer auth across the board. The operations fall into four groups:
| Group | Operations | What they do |
|---|---|---|
| Standard flow | 4 | get the hosted KYC/KYB link, initiate, create an access session, share an existing Sumsub applicant |
| Submissions | 9 | list, get, provide info, add questionnaire answers, set relations, create a child applicant, request an upload token, upload documents, complete |
| Endorsements | 3 | list, get by code, post by code |
| Sessions | 1 | create a KYC session |
The submissions group is the interesting part. It is a full programmatic path through verification, without the hosted link: you write applicant info, answer questionnaires, attach related beneficiaries, get a token, upload documents against it and mark the submission complete. The schemas behind it are rich. Requirements come back as a oneOf with a kind discriminator (static, oneOf, conditional), and questionnaire questions are typed (multiple choice, multiple countries, number, text, files).
Three things to watch
No error paths. All 17 operations declare only 200. You cannot tell from the contract what a rejected document or an incomplete submission returns, so you will find out at runtime.
Two session endpoints. POST /v1/kyc/session returns a KYCSession and takes no body. POST /v1/kyc/sessions takes a JSON body and returns a JwtToken. The names differ by one letter and the contract does not say when to use which.
Derived summaries. Three endorsement operations carry summaries marked x-summary-source: derived, such as “Get v1 kyc endorsements code”. We wrote those because Due’s fragments had none, so nothing in the contract says what an endorsement is.
What is ours to fix
We assembled this contract from Due’s per-operation OpenAPI fragments on due.readme.io, and the counts disagree with each other. The API page description says 15 operations, while its own operation list holds 17. The overview says Due publishes 18 APIs on the network, while the provider record counts 1. Due scores 48.3 on the Kin Score (developing) and 26.0 on Agent Readiness (agent-aware). The provider also carries an Arazzo workflow named “Onboard a customer account with KYC/KYB”, which strings these calls together.
Takeaway
The submissions path is a real alternative to sending users to a hosted page, and the typed requirement schemas show it was built for that. Build the error handling from the sandbox, not from the contract, and confirm which session endpoint your flow needs before you ship. The contract and docs are linked from apis.io/apis/due/due-kyc-api/.