Introduction

The Functional API is Keras's more flexible model-building approach, representing a model as a graph of layers rather than a strict linear stack — each layer is called explicitly as a function on a specific input, and the resulting connections between layers can branch, merge, or support multiple separate inputs and outputs. This directly addresses the core limitations of the Sequential API covered in the previous topic, unlocking the kinds of architectures needed for more complex, real-world deep learning tasks.

The Functional API gets its name from the way models are built: layers are used as callable functions, applied directly to tensors, making the connections between layers explicit and highly flexible rather than implicitly linear.

Why Does the Functional API Matter?

The Functional API helps to:

• Support architectures with multiple separate inputs or multiple outputs
• Enable branching and merging between different layers or paths
• Support skip/residual connections, as covered in earlier topics
• Allow layers to be reused and shared across different parts of a model
• Provide the flexibility needed for the majority of non-trivial, real-world architectures
• Serve as a natural next step once the Sequential API's limitations are reached

How the Functional API Works

Whiteboard

Instead of adding layers to a container one after another (as
in the Sequential API), the Functional API works by calling
each layer directly on a specific tensor, and capturing the
result:

output_tensor = SomeLayer(some_arguments)(input_tensor)

This explicit, function-call style is what allows layers to
be connected in any pattern needed — not just a single
straight line.

Building a Basic Model with the Functional API

Notice how each layer is called directly on the previous tensor ((inputs), then (x)), explicitly building the connections step by step, rather than simply appending layers to a list.

Handling Multiple Inputs

This model accepts two entirely separate inputs — text-based and numeric features — processes each independently, then merges (concatenate) them together before producing a final prediction, something the Sequential API simply cannot express.

Handling Multiple Outputs

This model takes a single image input but produces two separate outputs — a product category classification and a predicted price — sharing the same underlying feature-extraction layers.

Implementing Skip Connections with the Functional API

This directly demonstrates implementing the skip connection concept covered earlier — something structurally impossible to express using the strictly linear Sequential API.

Common Functional API Patterns

Functional API vs Sequential API

Key Properties of the Functional API

• The Functional API builds models by calling layers as functions directly on specific tensors.
• It supports multiple inputs, multiple outputs, branching, merging, and skip connections.
• Models are created by explicitly specifying keras.Model(inputs=..., outputs=...).
• Layers can be reused by calling the same layer instance on different inputs, enabling shared representations.
• It remains fully compatible with the standard compile → fit → evaluate → predict tf.keras workflow.

Where Is the Functional API Used?

Advantages

• Supports a much broader range of architectures than the Sequential API
• Explicit layer connections make complex model structures easy to trace and understand
• Enables layer reuse and parameter sharing across different parts of a model
• Directly supports patterns like skip connections that are essential in modern architectures
• Still relatively readable and intuitive compared to full Model Subclassing

Limitations

• Slightly more verbose and requires more explicit code than the Sequential API for simple models
• Requires understanding the concept of calling layers as functions on tensors
• Some highly dynamic or conditional architectures may still require Model Subclassing instead
• Debugging complex graphs with many branches can be more involved than a simple linear stack
• Requires more careful planning of the overall model graph structure upfront

Real-World Examples

Best Practices

• Move to the Functional API as soon as a project needs multiple inputs, outputs, or non-linear connections.
• Use model.summary() and keras.utils.plot_model() to visualize and verify complex graph structures.
• Name your inputs and outputs clearly (via the name argument) for models with multiple inputs/outputs.
• Reuse layer instances deliberately when you want genuinely shared weights across different inputs.
• Keep the overall graph structure as clear and well-organized as possible, even as complexity grows.

Interview Tip

A common interview question is:

"How would you build a model with two separate inputs using Keras, and why can't this be done with the Sequential API?"

A strong answer is:

I'd use the Functional API, defining two separate keras.Input layers, processing each through its own set of layers, and then combining them — typically with layers.concatenate() — before passing the combined representation through further layers to produce a final output, all wrapped in a keras.Model(inputs=[input1, input2], outputs=output) call. This can't be done with the Sequential API because it only supports a single, strictly linear stack of layers, with no way to represent two independent input paths that later merge — the Functional API's graph-based structure, where layers are called as functions on specific tensors, is exactly what's needed to express this kind of branching architecture.

Providing the specific mechanism (concatenate) and explaining why Sequential fails makes your answer stronger.

Conclusion

The Functional API unlocks the flexibility needed for complex, real-world architectures — multiple inputs and outputs, branching and merging, skip connections, and shared layers — that the Sequential API simply cannot express, while remaining relatively intuitive through its explicit, function-call style of connecting layers. With both the Sequential and Functional APIs now covered, the next topic explores Model Subclassing, the third and most flexible approach, offering full custom control for even the most complex or dynamic architectures.