Uploads one or more Universal KYB documents against a single document type.

Which entity does entityId refer to? Always the BUSINESS entity being onboarded, regardless of document type.

For ubo-kyc, the beneficial owner is named separately by two required fields: individualEntityId (the UBO's own INDIVIDUAL entity uuid, as returned when the UBO was declared) and uboDocumentType (the kind of identity document being uploaded — one of PASSPORT, ID_CARD, DRIVERS_LICENCE). Neither field may be sent for any other document type.

Allowed extensions, for every requirement except ubo-kyc: .jpg, .jpeg, .pdf, .png, .gif, .xlsx, .xls, .doc, .docx, .csv. ubo-kyc accepts a narrower set — .jpg, .jpeg, .png, .pdf. Either way the declared multipart MIME type must match the extension (e.g. .pdf requires application/pdf).

File caps, per requirement type. ubo-kyc: 2 files per request (a front/back pair), and at most 20 files in total for one beneficial owner — that total counts superseded files, so it does not reset when you re-upload. Every other requirement: 5 files per request and 20 files in total per requirement, counted per requirement so filling one does not restrict another.

Re-uploading behaves differently for identity documents. For ubo-kyc, a second upload for the same uboDocumentType replaces what was there before: the previous files stop being part of the submission. This is destructive — send the complete set you want on record, not just the side you are correcting. Different uboDocumentType values are independent, so a passport and a driving licence can both be held at once.
Every other requirement appends. Files accumulate across uploads and nothing is replaced, so send only what is new.
File order is meaningful for ubo-kyc. files[0] is the front of the document and files[1] the back. Send one file for a single-sided document such as a passport bio page. The order is preserved in the response.