Skip to main content
Before a vendor can go live on your platform, they must pass an identity and business verification check. Vendors submit one or more documents during onboarding, and you review each document individually in the Meneja dashboard. The platform tracks verification at both the document level and the overall vendor level, so you always have a clear picture of where a vendor stands in the approval process.

​
How the KYC flow works

1

Vendor submits documents

During onboarding (or later from their profile), the vendor uploads verification documents. Each uploaded item becomes a VerificationDocument record with an initial verification_status of pending.
2

You review each document

Open the vendor’s profile and navigate to the Documents section. For each document, you can see its type, submission date, and current status. Review the uploaded file via document_url.
3

Approve or reject the document

Select Approve to mark the document as verified, or Reject to mark it as rejected. When rejecting, you must provide a rejection reason, which is stored in rejection_reason.
4

Approve or reject the vendor

Once all required documents are verified, you can approve the vendor as a whole. If documents are missing or invalid, you can reject the vendor. This updates the vendor’s top-level verification_status.
5

Activate the vendor

An approved vendor still starts with is_active set to false. After approval, activate the vendor to make their store visible to shoppers.

​
VerificationDocument fields

Each document submitted by a vendor contains the following fields:

​
Document verification statuses

The verification_status field on an individual VerificationDocument uses verified (not approved) to indicate a passing review. The top-level vendor verification_status uses approved.

​
Overall vendor status

After you act on a document, the API response includes an overall_vendor_status field that reflects the vendor’s aggregate verification state. This value is derived from the combination of all document statuses and any explicit approve or reject action you take on the vendor as a whole. The vendor-level verification_status can be:
Approving a vendor sets is_active to false by default. You must separately activate the vendor to make their store live. Rejecting a vendor also sets is_active to false.

​
Rejecting a vendor or document

When you reject a document or a vendor, the dashboard prompts you to select or enter a rejection reason. Common reasons include:
  • Incomplete or missing verification documents
  • Invalid or expired verification documents
  • Inconsistent business information
  • Violation of platform policies
The rejection reason is stored in rejection_reason on the VerificationDocument record (for document-level rejections) or sent as part of the vendor status update payload (for vendor-level rejections).
Always provide a clear rejection reason. The reason is available to you when you review the vendor record later, helping you track why a vendor was previously rejected.