A service in the T-Gate platform represents one of the fulfillment options a branch can offer to its customers — dine-in, delivery, pick-up, or curbside. The services endpoint exposes the catalog of services configured on the platform; a branch then opts into a subset of them through its branch_services, and each Order is anchored to one of those service types.

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

Model Attributes

The partner portal exposes services through a single endpoint: GET /partner_portal/v1/services. The same payload is also embedded (flattened) inside each branch_service returned with a branch.

Attribute	Description	Type
id	The unique identifier of that table entity.	Integer
name_en	Service name in English.	String
name_ar	Service name in Arabic.	String
name	Localized service name returned according to the request's `Accept-Language` header. Resolves to `name_en` for `en` and to `name_ar` for `ar`.	String
service_type	The canonical identifier of the service. One of `dine_in`, `delivery`, `pick_up`, `curbside`. This is the value used to match orders.	String
image	URL of the service's icon/illustration. `null` if no image has been uploaded.	String or Null

📘
name VS name_en / name_ar
Responses always include both name_en and name_ar so consumers can render either translation regardless of the current request locale.
The name attribute is a convenience field resolved on the server side from the Accept-Language header. Applications that already maintain their own localization layer can ignore it and read name_en / name_ar directly.

📘
service_type Is The Canonical Identifier
name_en and name_ar are display labels and can be edited by T-Gate; service_type is the stable, machine-readable identifier and is what should be used when matching a service against the rest of the API.
For example, Order#service_type, branch_service.service.service_type, and the per-service flags on a branch all key off this same service_type value.

Available Service Types

The full set of service_type values is fixed by T-Gate. New service types cannot be added by partner integrations.

service_type	Description
dine_in	Service for customers who choose to eat within the restaurant premises.
delivery	Service for delivering orders to customers' specified locations.
pick_up	Service allowing customers to place orders and pick them up at the restaurant.
curbside	Service where customers place orders and have them brought to their vehicles at a designated curbside location.

✈️
app_delivery Is Not Listed Here
Orders can also carry service_type = app_delivery, which means the partner application itself fulfills the delivery rather than the branch. app_delivery is not a regular service — it is not stored in the services table, will not appear in the services listing endpoint, and cannot be assigned to a branch through branch_services.
See the orders documentation for the full set of order service types.

🔎
Filtering Services By Name
The services listing endpoint accepts a name filter that performs a case-insensitive substring match against both name_en and name_ar. Use it to locate a service by part of its display name.

Relationship With Branches

The link between a service and a branch is stored as a branch_service record. Each branch_service carries:

Attribute	Description	Type
id	The unique identifier of the branch-service link.	Integer
default_order_estimated_time	The default estimated preparation time (in minutes) that T-Gate assigns to new orders of this service at this branch.	Integer
is_active	Whether this service is currently enabled on the branch. Inactive services cannot be used to create new orders.	Boolean

The underlying service is flattened into the branch_service payload — meaning the branch_service object returned with a branch carries the service's service_type, name, name_en, name_ar, and image directly alongside id, default_order_estimated_time, and is_active.

See the branches documentation for the full branch model.

Relationship With Orders

Every order is anchored to one service_type. T-Gate validates at order creation that the chosen service is both supported by the platform and active on the branch — either via an active branch_service (for dine_in / delivery / pick_up / curbside) or via the partner application's own delivery support flag (for app_delivery).

See the orders documentation for the full set of validations applied at order creation.