ElanoryaModel catalogue
A catalogue model reaches the phone as nine fields, and none of them is a name
Before publishing an image made with a catalogue model, sellers ask what the app carries about that model. At the transport level the answer is short: nine descriptive fields, one of which is a code the source describes as generic and never a person name, and no human-readable name column among them.
What one catalogue model carries to the phone
Four statements, each read from the API source in August 2026 at the file named beside it.
- Nine fields travel, and the name column is not among them.
- The client interface for a catalogue model lists identifier, catalogue code, category, gender, framing, body region, order number, thumbnail address and full-size image address. The human-readable name field held in the database is not part of that set (apps/api/src/models/models.service.ts).
- The code field is annotated as generic.
- The code that identifies a model on the client is marked in the source as generic, with a written statement that it is never a person name (apps/api/src/models/models.service.ts).
- An account is required before any list is produced.
- The listing endpoint is placed behind the authentication guard, so an anonymous caller receives no model list (apps/api/src/models/models.controller.ts).
- Body region is carried, not queried.
- The field appears in the response and does not appear in the filter set, so the request cannot be narrowed by it (apps/api/src/models/models.service.ts).
The nine fields, one line each
The client-facing interface in apps/api/src/models/models.service.ts, field by field. Nothing outside this list travels with a catalogue model.
| Field | What the response carries |
|---|---|
| Identifier | The record's own identifier in the catalogue |
| Catalogue code | The code shown to the client, annotated in the source as never a person name |
| Category | The catalogue grouping the model belongs to |
| Gender | A descriptive attribute of the catalogue entry |
| Framing | Whether the frame is close or wide |
| Body region | A descriptive attribute; carried in the response, absent from the filter set |
| Order number | The ordering number carried with the record |
| Thumbnail address | The address of the small image |
| Full-size image address | The address of the full-size image |
Four readings this answer does not support
Each of these goes beyond what the field mapping and the source annotation can carry.
Turning a transport fact into a conclusion about identity.
What is established is which fields travel and what one annotation says. Who appears in a catalogue image, and how the entry was produced, are outside this surface entirely.
Inferring how many models exist, or how they are spread across categories.
Those are values in the database rather than facts in the code, and this page does not state them.
Assuming the field list describes what the app displays on a card.
The list is the response contract. Which of those fields the interface draws, and how, is not settled here.
Treating the two image addresses as fixed links to keep.
This page names the two address fields and stops there; how long an address stays usable is settled on the page about image addresses, not on this one.
What an annotated code proves, and what it does not
The strongest sentence available here is also the narrowest: the code that identifies a model on the client is a catalogue code, and the source says in writing that it is never a person name (apps/api/src/models/models.service.ts). That is a field mapping plus an annotation beside it, verified against the API source in August 2026.
It does not extend to the values that were entered into the database, to how any catalogue entry was made, or to anything about the people who may appear in the images. A seller doing due diligence gets one thing from this page: a precise account of what the app sends to the phone for each catalogue model.
Where this answer stops
The read path for catalogue models is a small surface, and these questions sit outside it.
- How many models the catalogue holds, and how they are distributed across categories, is not readable from this surface.
- How model records are created, loaded or edited is not part of the read path described here.
- How a model is selected or checked while a generation runs belongs to a different part of the API.
- How long an image address stays usable, and when it is issued again, is settled on the page about image addresses.
- Which filters the mobile interface offers, and how they are presented, is not established by the API surface.
- Working with a model photograph you supply yourself is outside this page; the field list covers system catalogue models only.
Questions
Do catalogue models have names?
The code that identifies a model on the phone is a catalogue code, annotated in the source as never a person name, and the database's human-readable name column is not among the nine fields the API returns (apps/api/src/models/models.service.ts).
Can I ask the app for hand models only?
No. Body region is carried in the response and is not part of the filter set, so the request cannot be narrowed by it (apps/api/src/models/models.service.ts).
Do I need an account to browse the model catalogue?
Yes. The listing endpoint sits behind the authentication guard and produces no list for an anonymous caller (apps/api/src/models/models.controller.ts).
Does the phone receive everything the system stores about a model?
No. The row in the database holds columns the API does not return (packages/db/prisma/schema.prisma:394-410). This page describes the nine fields that travel, not the stored record.