# How to Use Feast's Feature Service API for Model Serving

> Learn how to use Feast's Feature Service API to bundle features from multiple views for efficient model serving. Ensure consistent feature sets between training and inference.

- Repository: [Feast/feast](https://github.com/feast-dev/feast)
- Tags: how-to-guide
- Published: 2026-03-01

---

**Feast's Feature Service API lets you bundle features from multiple views into a single named object that can be retrieved in one call during model serving, ensuring consistent feature sets between training and inference.**

The **Feature Service API** in Feast (feast-dev/feast) provides a declarative way to group related features for model serving. By defining a `FeatureService` object in your feature repository, you create a versioned contract that maps to specific columns across one or more feature views, enabling low-latency retrieval via the Python SDK or the standalone feature server.

## What Is the Feature Service API?

A **Feature Service** is a logical grouping of feature view projections. Rather than passing raw feature references to your model serving code, you define a service that encapsulates exactly the features your model expects.

Key characteristics:

- **Projection-based**: Each service contains references to specific columns (projections) from one or more `FeatureView` objects.
- **Schema inference**: If a feature view lacks an explicit schema, the service can infer required features during the `feast apply` phase via the `infer_features` method.
- **Dual-mode**: The same service definition works for both **offline training** (historical joins) and **online serving** (real-time inference).

The core implementation resides in [`sdk/python/feast/feature_service.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/feature_service.py), where the `FeatureService` class stores projections and performs inference logic.

## How the Feature Service API Is Implemented

Feast exposes feature services through multiple interfaces:

### Registry REST API

The registry server provides REST endpoints for service discovery, defined in [`sdk/python/feast/api/registry/rest/feature_services.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/api/registry/rest/feature_services.py):

- `GET /feature_services` – Lists all services with optional filtering by name, tags, or feature view.
- `GET /feature_services/{name}` – Retrieves a specific service, including a rendered Python code snippet for easy reuse.

### Client SDK

The `FeatureStore` class in [`sdk/python/feast/feature_store.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/feature_store.py) provides the primary interface:

- `get_feature_service(name)` – Fetches the service definition from the registry.
- `get_online_features(features=service, ...)` – Accepts a `FeatureService` instance instead of a raw feature list.

### Serving Layer

The standalone feature server ([`sdk/python/feast/feature_server.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/feature_server.py)) and the underlying gRPC service (`protos/feast/serving/ServingService.proto`) resolve service names at request time, expanding them into constituent feature references before querying the online store.

## Defining a Feature Service for Model Serving

To use the Feature Service API in production, first define the service in your feature repository.

### Step 1: Create the Service Definition

In [`feature_repo.py`](https://github.com/feast-dev/feast/blob/main/feature_repo.py), instantiate `FeatureService` with a list of feature view projections:

```python
from datetime import timedelta
from feast import Entity, FeatureView, FeatureService, FileSource, Field, ValueType

# Define entity and source

driver = Entity(name="driver_id", description="driver identifier")

driver_stats_source = FileSource(
    path="data/driver_stats.parquet",
    timestamp_field="event_timestamp",
    created_timestamp_column="created",
)

# Define the feature view

driver_stats_fv = FeatureView(
    name="driver_stats",
    entities=[driver],
    ttl=timedelta(days=1),
    source=driver_stats_source,
    schema=[
        Field(name="daily_trips", dtype=ValueType.INT64),
        Field(name="average_speed", dtype=ValueType.FLOAT),
    ],
)

# Group specific features into a service for model serving

driver_service = FeatureService(
    name="driver_service",
    features=[driver_stats_fv[["daily_trips", "average_speed"]]],
)

```

### Step 2: Apply the Configuration

Run `feast apply` to register the service. This triggers `FeatureService.infer_features` in [`sdk/python/feast/feature_service.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/feature_service.py), which resolves the projection against the concrete feature view schema.

```bash
feast apply

```

## Retrieving Features via the Feature Service API

Once registered, retrieve features using the service object or name.

### Method 1: Python SDK

Fetch the service from the registry and pass it to `get_online_features`:

```python
from feast import FeatureStore

store = FeatureStore(repo_path="path/to/feature_repo")

# Retrieve the service definition

svc = store.get_feature_service("driver_service")

# Request features for inference

entity_rows = [{"driver_id": 123}]
response = store.get_online_features(
    entity_rows=entity_rows,
    features=svc,  # Pass the FeatureService object

    full_feature_names=True,
)

# Convert to dictionary for model input

feature_dict = response.to_dict()

```

### Method 2: Standalone Feature Server

For production serving, run the Feast feature server and query via HTTP:

```bash
feast feature-server start \
  --project=my_project \
  --host=0.0.0.0 \
  --port=6565

```

Then query using the service name:

```python
import requests
import json

payload = {
    "features": ["driver_service"],  # Service name as string

    "entities": [{"driver_id": 123}]
}

response = requests.post(
    "http://localhost:6565/get-online-features",
    json=payload,
    timeout=5
)

features = json.loads(response.text)

```

The server expands `"driver_service"` into its constituent feature references (`driver_stats:daily_trips`, `driver_stats:average_speed`) before querying the online store, ensuring low-latency retrieval while keeping your model code decoupled from the underlying feature view topology.

## Summary

- The **Feature Service API** groups feature view projections into a single, versioned object for consistent retrieval.
- Define services in Python using `FeatureService`, then apply with `feast apply` to register them in [`sdk/python/feast/feature_service.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/feature_service.py).
- Retrieve features via `FeatureStore.get_online_features` by passing the service object, or query the standalone feature server using the service name.
- This approach decouples model serving code from underlying feature view schemas, ensuring training-serving consistency.

## Frequently Asked Questions

### What is the difference between a Feature View and a Feature Service?

A **Feature View** defines a logical grouping of features based on a data source and entity keys, typically corresponding to a specific table or stream. A **Feature Service** is a higher-level abstraction that selects specific columns (projections) from one or more Feature Views to create a curated feature set for a specific model or use case. While a Feature View manages the data pipeline and storage, a Feature Service manages the serving contract.

### Can I use the same Feature Service for both training and serving?

Yes. The Feature Service API is designed for **dual-mode** usage. When passed to `get_historical_features`, it retrieves point-in-time correct feature values for model training. When passed to `get_online_features` or queried via the feature server, it retrieves the latest values for real-time inference. This ensures that the exact same feature set is used in both contexts, preventing training-serving skew.

### How does the Feature Service API handle schema evolution?

When you run `feast apply`, the `FeatureService.infer_features` method in [`sdk/python/feast/feature_service.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/feature_service.py) resolves the feature projections against the concrete schemas of the underlying Feature Views. If a Feature View schema changes (e.g., a new column is added), the service definition remains valid as long as the projected columns still exist. To add new features to a service, simply update the projection list in the Python definition and re-run `feast apply`.

### What latency can I expect when using the Feature Service API for online serving?

The Feature Service API itself introduces negligible overhead. When using `get_online_features` with a Feature Service object, the client expands the service into a list of feature references before sending a single batch request to the online store. When using the standalone feature server (`feast feature-server start`), the server performs this expansion internally. In both cases, the online store (e.g., Redis, DynamoDB, Bigtable) is queried in a single batch operation, typically achieving p99 latencies under 10-20ms depending on your infrastructure.