Illustrative structured Jahez record
The following example shows how an agreed Saudi restaurant/menu observation could be structured.
It is illustrative—not a live Jahez response, a production NenoData endpoint contract, customer data, or proof that every field is available.
Illustrative schema — not a live Jahez response, production NenoData endpoint contract, customer record, or proof of universal field availability.
{
"source": "jahez",
"market": "SA",
"source_surface": "restaurant_menu",
"restaurant": {
"name": "Example Restaurant",
"category": "Example Cuisine",
"source_id": "example-id"
},
"menu_item": {
"category": "Example Category",
"name": "Example Item",
"description": "Example visible description"
},
"pricing": {
"listed_price": "42.00",
"promotional_price": "35.00",
"currency": "SAR",
"promotion_text": "Example visible offer"
},
"delivery_context": {
"availability": "example-visible-status",
"delivery_fee": "example-visible-value",
"estimated_delivery_time": "example-visible-value"
},
"location_context": {
"city": "Example City",
"area": "Example Area"
},
"source_reference": "illustrative-source-reference",
"collected_at": "YYYY-MM-DDTHH:mm:ssZ",
"refresh_batch_id": "example-batch",
"validation_status": "passed"
}
Unavailable fields should follow the project's agreed null or exception rules rather than being fabricated.
For grocery/retail collection, use a product-oriented structure containing fields such as product, brand, category, store, price, promotion, availability, and location where those values are verified.
