Skip to main content
The Headless UI library is part of @amp-labs/react and provides a powerful foundation for managing connections and installations while giving you complete control over your UI implementation. This library is designed for developers who want to build custom user interfaces while leveraging robust connection, integration, and installation management capabilities.
The Headless UI library is in beta. It may change in non-backwards-compatible ways. (Although we are very serious about semantic versioning.)If you have any feedback, please file an issue on Github.

Overview

The Headless UI Library provides a series of React hooks that manage connections, installations, and other configuration data using query and mutation hooks. The hooks may be used together or independently of the prebuilt UI components. The Headless UI Library separates the logic of connection and installation management from the UI components, allowing you to:
  • Manage connections to various services and platforms.
  • Handle installation processes.
  • Implement custom UI components.
  • Maintain full control over the user experience.

Prerequisites

Install the library

The Headless UI Library is currently in the same package as our prebuilt UI components.

Context setup

In order for the headless hooks and functions to have relevant context, you can only use them inside AmpersandProvider and InstallationProvider. The AmpersandProvider needs to wrap all usages of headless hooks and functions as well as prebuilt UI components. See AmpersandProvider for more details on configuration and authentication methods. The InstallationProvider needs to wrap any code that interacts with a particular installation. This means that if your UI needs to handle multiple installations (e.g., one for Asana and one for Zendesk), then you need two instances of InstallationProvider: one that wraps the code for Asana setup, and one that wraps the code for Zendesk setup. InstallationProvider requires the following props:
  • integration (string): the name of an integration that you’ve defined in amp.yaml.
  • consumerRef (string): the ID that your app uses to identify this end user.
  • consumerName (string, optional): the display name for this end user.
  • groupRef (string): the ID that your app uses to identify a company, team, or workspace. See group.
  • groupName (string, optional): the display name for this group.

Connection management

The library provides hooks and utilities for managing Connections. The useConnection hook provides access to the current connection state and management functions. It returns an object with the following properties:
  • connection: The current Connection object, or null if there isn’t one.
  • error: Any error that occurred while fetching the Connection.
  • isPending: If true, there is no data yet.
  • isFetching: If true, the data is being fetched (including refetches).
  • isError: If true, an error occurred while fetching the connection.
  • isSuccess: If true, the last fetch was successful.

Installation management

Get current installation

The useInstallation hook provides access to the current installation state and management functions. It returns an object with the following properties:
  • installation: The current Installation object, or null if not installed.
  • error: Any error that occurred while fetching the Installation.
  • isPending: If true, there is no data yet.
  • isFetching: If true, the data is being fetched (including refetches).
  • isError: If true, an error occurred while fetching the connection.
  • isSuccess: If true, the last fetch was successful.

Get config from existing installation

To access the configuration from an existing installation, you can use the installation.config property. See API reference for more details:
For more advanced config management: including getting/setting read/write objects in the config and managing a local draft copy, use the useLocalConfig() hook.

Create, update, and delete installations

The following hooks provide granular control over Installation operations:
  • useCreateInstallation
  • useUpdateInstallation
  • useDeleteInstallation
For example, the useCreateInstallation hook is used to create a new Installation.
As of v2.12.1, useCreateInstallation automatically populates config.provider from the integration object if it is not explicitly set in the config. This means you no longer need to manually set the provider.
It returns the following:
  • createInstallation: a tanstack-query mutation function to create a new Installation. Its signature is:
  • isPending: Boolean indicating if creation is in progress.
  • error: Any error that occurred during creation.
  • errorMsg: String message describing the error.
  • isIdle: If true, createInstallation has not been called yet.
  • isSuccess: If true, installation was successfully created.
useUpdateInstallation and useDeleteInstallation follow similar conventions. Here’s an example of how you can use these hooks:

Get manifest and field metadata

The useManifest hook provides the data that you need to build input forms for your users to help them configure the integration. This hook allows you to:
  • Access integrations as defined in the manifest (amp.yaml).
  • Retrieve object and field metadata from the connected provider (e.g., Salesforce, Hubspot). This allows your application to know about the exact objects and fields that exist in your customer’s SaaS instance, including custom objects and fields. With this information, you can build dropdowns, checkboxes, etc.
useManifest always returns the integration’s latest published revision of amp.yaml — it is not tied to any specific installation. If an installation was created against an older revision, useManifest will still reflect the current amp.yaml and may differ from the installation’s saved config. See useManifest vs useLocalConfig.
useManifest exposes typed helpers for read and write objects (getReadObject, getReadObjects, getWriteObject).

Get fields from customer’s SaaS

The getCustomerFieldsForObject function returned by useManifest allows you to retrieve the standard and custom fields that exist in your customer’s SaaS instance for a particular object.
The fields mapping page of the demo app provides a full example for using useManifest to build the UI for customers to configure the installation.

Get all read objects from manifest

The getReadObjects function returned by useManifest returns all read objects defined in the manifest, which is useful when you need to iterate over all objects rather than fetching them individually by name. Supported in @amp-labs/react v2.12.1+.

Local config management

Managing the Config that keeps track of each customer’s preference for how the integration behaves can be complex, with deeply nested objects and the need to manage this state locally. The useLocalConfig hook simplifies local state management of the config object by providing flexible utilities to manipulate the config through a set of setters and getters. It maintains a draft state, which you can modify before committing changes to the installation.
Deprecated: useConfig has been deprecated in v2.9.0. It has been renamed to useLocalConfig() without any other changes.For fetching an existing config from an installation, use useInstallation which provides access to the current installation’s configuration.
Prefer the helper functions (readObject, writeObject, proxy, setDraft, removeObject, reset, get) over accessing draft directly. The helpers encapsulate how the draft is initialized, synced with the installation, and merged with manifest defaults. For authoritative installation state, use useInstallation. For the integration’s latest manifest (from your amp.yaml file), use useManifest. See useManifest vs useLocalConfig.
It returns these fields:

Basic example

This is a basic example that hard-codes a Config and does not allow the user to modify it.

Manage read config

This is an example for how to use helper functions to more easily construct a read config, so you do not have to create the full config object manually.

Enable, disable, and remove read objects

The readObject() handlers include setEnableRead and setDisableRead to control whether an object is read. removeObject fully deletes an object from the config. Supported in @amp-labs/react v2.12.1+.
  • setEnableRead — initializes a read object in the draft config and enables it. Safe to call multiple times (idempotent). For convenience, you can skip calling this function if you are already calling setFieldMapping or setSelectedField.
  • setDisableRead — pauses reads for the object without removing its config (sets a disabled flag).
  • removeObject — fully deletes an object from all actions (both read and write) in the draft config.
Calling setSelectedField or setFieldMapping will also automatically enable the read object, so setEnableRead is primarily useful when you want to enable an object without configuring fields, or to re-enable an object that was previously disabled.

Manage write config

The headless UI library provides helper functions to more easily construct a write config. Here’s a simple example that enables a particular object to be written to:
You can also configure advanced write use cases, which include the ability to:
  • Set default values for certain fields.
  • Prevent overwriting of existing customer data.

Configure features individually

You can configure write settings for individual features using these methods:

Configure features together

You can use setFieldSettings to set all advanced write features at once for a field:

useManifest vs useLocalConfig

Use the right hook for the job

  • “What does this integration currently support?”useManifest(). Use this when building configuration UI — pickers, field checkboxes, mapping dropdowns — that should follow the current amp.yaml.
  • “What did this installation actually deploy?”useInstallation().installation.config.content. This is the authoritative saved state. See the installation response schema for its shape. Do not use useLocalConfig for this — the draft is mutable and may include unsaved edits.
  • “Let the user edit the installation’s config.”useLocalConfig(), via its helper functions. See below.

Read and write through helper functions, not draft

Interact with useLocalConfig through its helpers rather than reading or mutating draft directly:

Examples

Demo app

View the source code on GitHub Dynamic Fields Table Example The headless demo app uses a Salesforce integration, and includes:
  • Ability to map fields; the dropdown is populated with standard and optional fields from the connected Salesforce instance.
  • Ability to create and update an Installation with the “Install” button.
  • Ability to reset Config to previous state with the “Reset” button.
  • Ability to delete an Installation with the “Delete” button.
  • Usage of Shadcn UI components + Tailwind CSS to demonstrate how you can bring your own design system.
It uses the following headless hooks:

Demo app with write config

View the source code on GitHub Write Features Table Example The headless write demo app uses a Salesforce integration, and extends the basic demo app with:
  • Ability to set default values for fields when writing.
  • Ability to prevent overwriting of customer data.

Pre-defined configuration flow

If you do not want your users to be able to modify or configure the installation, you can build a pre-defined configuration flow using the code snippet below. This is helpful if you do not want your user to be able to modify which objects and fields your integration reads and writes, and you do not need them to do any field mappings.