This is not another QC inspection checklist. It is a close reading of the fields RizzitGO publicly documents for partner QC records and an explanation of why structured metadata is useful without being proof of authenticity or delivered condition.
What the QC detail response contains
The RizzitGO Open API defines a QC-detail response with a goods ID, a list of QC photo URLs, length, width, height, weight, volume and completion time. Dimensions are documented in centimeters, weight in grams and completion time in a date-time format. The request pairs the goods ID with its marketplace source.
A separate endpoint returns the QC image list, while a paginated endpoint can filter records by goods ID, source, creation time or completion time. That time-based query makes QC data more than a loose folder of images: each result can be tied to a record and a documented completion window.
Why dimensions and weight are discovery signals
Length, width, height and weight can expose obvious mismatches and provide logistics context. A recorded weight can distinguish a lightweight accessory from a bulky garment entry; dimensions can help identify when a photographed package does not resemble the expected product category.
Those values still require context. The documentation does not state that every measurement describes the bare product rather than its packaging, and a single set of dimensions does not establish size, material or manufacturing quality. An index should display the values as reported metadata, not convert them into an unqualified verdict.
- Photo count measures available records, not inspection quality
- Measurements can flag inconsistencies but need product context
- Completion time helps distinguish one QC event from another
The privacy boundary is part of the schema
The official documentation explicitly says QC endpoints do not return inspector or photographer staff IDs or names. This is a useful boundary: partner applications can access product-level evidence without turning warehouse staff identity into a catalog field.
The same principle applies to public-facing directories. A QC badge should summarize the availability of records, not imply that a named person endorsed the product or that the platform has authenticated a brand claim.
Creation time and completion time describe different moments
The paginated QC query can filter by both createTime and completionTime. The first refers to when the record was created; the second refers to when the documented QC process was completed. The API keeps them as separate filters, so a publisher should not silently treat one as the other.
A gap between the two moments can occur for ordinary operational reasons, but the public schema does not provide a universal explanation for every gap. What can be said is that completion time offers a more precise way to associate photos and measurements with a finished QC record than a generic product update date would.
For historical indexes, this distinction helps prevent a new product listing from being paired with an older, unrelated QC event solely because the title looks similar. The goods ID, source and record time belong together as provenance.
A list of photos is not a written inspection conclusion
The documented QC response returns photo URLs and physical measurements. It does not define a public pass-or-fail field, a defect taxonomy, angle labels or an authenticity result in the response described by the guide. A directory should not invent those conclusions from the existence of images alone.
Photo count can still be useful because it tells a reader whether more than one visual record is available. Yet ten unclear images are not automatically more informative than four relevant ones. Count is a quantity signal, while usefulness depends on what the images actually show and whether they belong to the current record.
Measurements have a similar boundary. They can support comparison, but the schema does not say that they certify sizing accuracy or final parcel billing. Treating reported dimensions as exact promises would turn descriptive metadata into a guarantee the source does not make.
What the record still cannot prove
A structured QC record can show that photos and measurements were associated with a goods ID, source and completion time. It cannot by itself prove that a branded claim is authentic, that every defect is visible, that an option matches a buyer's expectation or that the delivered parcel will remain in the same condition.
RizzitGO's About page describes warehouse quality inspection and QC imagery as platform services. The API schema adds technical detail to that statement, but neither source supports treating every indexed image as authentication, inventory confirmation or a delivery guarantee.
The most defensible public description is therefore narrow: QC material is available for comparison. Any stronger conclusion needs evidence beyond the fields in the published partner response.
Sources and references2 reviewed+
These links document the facts used above. The wording and analysis on this page are original to this independent site.
Related site resource
Open the separate practical QC guide →