Lookups

The lookups endpoint exposes the small reference lists T-Gate uses to populate dropdowns and selectors in partner integrations — things like the list of available brand types, cuisine types, services, applications, and the days of the week. Rather than spreading these across many dedicated endpoints, the partner portal multiplexes them through a single endpoint that returns only the lookup keys the caller explicitly requests.

For more details on the hierarchical structure and how different entities relate to each other, please refer to General → High Level Structure Guides.

Endpoint

GET /partner_portal/v1/lookups

The endpoint accepts one query parameter per lookup the caller wants in the response. A request that does not include any of the supported parameters returns an empty lookups array. Multiple lookups can be requested in a single call by passing multiple parameters.

Supported Lookups

The values in the table below are accepted as query parameter names. The parameter's value controls pagination for the model-backed lookups (see the Pagination callout); for the constant-backed lookups the value is ignored.

Lookup Key	Source	Description	Type
brand_types	BrandType records	The set of brand types that can be assigned to a brand (e.g. restaurant, café).	Model-backed
cuisine_types	CuisineType records	The set of cuisine types that can be assigned to a brand.	Model-backed
services	Service records	The set of services that a branch can offer (dine_in, delivery, pick_up, curbside).	Model-backed
applications	Application records	The partner applications registered on T-Gate.	Model-backed
week_days	OpeningHour enum	The seven days of the week, used when configuring opening hours.	Constant-backed

Response Shape

The endpoint always returns a top-level lookups array. Each element of that array is an object with a single key — matching one of the requested lookup keys — whose value is the array of entries for that lookup.

Each entry inside a lookup carries three fields:

Field	Description	Type
key	For model-backed lookups, the literal string "id". For constant-backed lookups, the singularized lookup key (e.g. "week_day"). Useful when entries from different lookups are merged into a single client-side list.	String
value	The identifier of the entry. For model-backed lookups this is the record's id rendered as a string. For constant-backed lookups this is the enum value (e.g. "saturday").	String
name	The display name for the entry. For model-backed lookups it is the localized translation of the record's name (resolved from Accept-Language). For constant-backed lookups it is the translation of the corresponding I18n key.	String

Example response when requesting ?brand_types=1&week_days=1:

JSON

{
  "lookups": [
    {
      "brand_types": [
        { "key": "id", "value": "1", "name": "Restaurant" },
        { "key": "id", "value": "2", "name": "Café" }
      ]
    },
    {
      "week_days": [
        { "key": "week_day", "value": "saturday", "name": "Saturday" },
        { "key": "week_day", "value": "sunday",   "name": "Sunday"   }
      ]
    }
  ]
}

📄

Pagination

Model-backed lookups are paginated. The value of the query parameter is interpreted as the requested page number — for example, ?brand_types=2 returns the second page of brand types. Passing -1 disables pagination and returns the full list in one response (?brand_types=-1).

Constant-backed lookups (week_days) ignore the parameter value entirely and always return the complete list.

🌐

Localization

Both model-backed and constant-backed lookups return their name field in the locale resolved from the request's Accept-Language header. Note that the Application model is the only model-backed lookup that does not use translations — its name is returned verbatim regardless of the requested locale.

🔁

Dedicated Endpoints

Some reference data the partner portal exposes has its own dedicated endpoint instead of going through this multiplex:

• GET /partner_portal/v1/countries — list of countries.
• GET /partner_portal/v1/cities — list of cities (supports a country_id filter).
• GET /partner_portal/v1/timezones — list of timezones.
• GET /partner_portal/v1/services — list of services (mirrors the services key on the lookups endpoint).

Use the dedicated endpoints when you need richer attributes than the { key, value, name } triple — for example, the timezones endpoint also returns each timezone's utc_offset, and the countries endpoint returns each country's name_en and name_ar alongside the localized name.