---
title: "Enterprise integrations"
description: "Configure the Segment and Spoonity settings shown in Dashboard, then verify provider behavior and outcomes separately."
canonical: https://docs.ordering.co/docs/products/dashboard/settings/enterprise/integrations/
---

# Integrations

This guide covers the historical Dashboard settings for **Segment** and **Spoonity**. The screenshots show empty example fields and an example selection; the controls, identifiers, and available providers in your project can differ.

Each screenshot opens at full size. Do not copy tracking IDs, vendor IDs, account identifiers, credentials, endpoints, customer data, order data, or provider responses from another workspace into your configuration or public documentation.

## Current catalog and example settings

The current configuration catalog has two child groups: Segment has one tracking field, while Spoonity has enablement, platform-name, and vendor-identifier fields. The documented source role for this category is an authorized administrator at level 0, and Dashboard must return the category before a field can be used.

This catalog does not prove that a provider, field, identifier, connection, or permission is available in a project. The labels and empty fields in the screenshots are example settings; they do not supply account values or provider authorization.

[![Historical Dashboard integrations screen with Segment and Spoonity configuration sections](https://docs.ordering.co/img/help-center-import/0d2fd85ba828dbb1524401de.png)](https://docs.ordering.co/img/help-center-import/031b3c2ef510d37e4f64142a.png)

> **Saved configuration is not a provider outcome**
>
> Adding an identifier, enabling an integration, or saving a setting does not prove a provider accepted it, data was sent, a webhook ran, analytics are available, loyalty records changed, a reward was applied, or a customer experience changed.

## Before you configure an integration

- Confirm that your organization has authorized the intended Dashboard and provider-account changes.
- Collect the account-specific values through your approved secret-management process; do not use a value from another project, environment, screenshot, or ticket.
- Identify the isolated test and the exact result to verify, such as a saved configuration, an approved test event, or a provider-owner confirmation.
- Change one setting at a time. A successful Dashboard response is different from provider acceptance and downstream behavior.

## Save behavior and partial persistence

For ordinary integration fields, the current Dashboard source stages edits until **Save** and writes configuration records sequentially. A later failure can follow an earlier persisted change, so a multi-field save is not evidence that every identifier or enablement choice was stored. This describes the source contract only; no request, provider handoff, event, loyalty update, or analytics result is verified here.

## Configure Segment

The example settings includes a **Segment Tracking ID** field. The current catalog associates Segment with one tracking field, but neither source proves a current rendered label or an accepted account identifier.

1. Open the available integration category in Dashboard.
2. Locate the **Segment Tracking ID** field when it is available.
3. Enter the value issued for the intended account through the approved process.
4. Save the configuration if the current interface provides a save action.
5. Verify the chosen test boundary without exposing the identifier or payload.

The source frames Segment as a way to collect and analyze selected website and app interactions. Treat that as an intended integration purpose, not proof that an event, customer interaction, commerce action, or analytics record has been received.

[![Historical Segment Tracking ID field using an empty placeholder](https://docs.ordering.co/img/help-center-import/4fbab5f446f99f1f1de37ddc.png)](https://docs.ordering.co/img/help-center-import/67858b8af332206a6bf12758.png)

Use the [Segment website](https://segment.com/) only for the provider guidance approved for the account you are configuring. Do not infer a provider destination, tracking scope, data-access permission, or event schema from this Dashboard field alone.

## Configure Spoonity

The example settings includes:

| Setting                           | Intended configuration                                               |
| --------------------------------- | -------------------------------------------------------------------- |
| **Activate Spoonity Integration** | Whether the Spoonity integration is enabled in the category.         |
| **Enter Spoonity Vendor ID**      | The vendor identifier associated with the intended Spoonity account. |
| **Define Spoonity Platform Name** | The platform name shown for the intended loyalty configuration.      |

To configure an available setting, open the Spoonity section, enter the account-specific vendor ID and platform name through the approved process, select the intended enablement value, and save if the current interface provides a save action.

The source describes Spoonity as a loyalty-oriented integration that can be used for points and rewards. A configuration change does not prove a customer account is connected, points are recorded, a reward is available, an order qualifies, or a benefit is delivered.

[![Historical Spoonity integration controls using empty identifier and platform-name fields](https://docs.ordering.co/img/help-center-import/3060cbb03a612821cffefe7f.png)](https://docs.ordering.co/img/help-center-import/88229f0291216b0b6feb075c.png)

Use the [Spoonity website](https://www.spoonity.com/) only with the provider guidance and account authorization approved for your organization. Do not substitute a vendor ID, provider setting, or destination from another workspace.

## Verify each boundary separately

Keep configuration, provider behavior, and user outcomes separate:

| Boundary                | Evidence to confirm                                                                   | What it does not prove                                                               |
| ----------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Dashboard configuration | The intended fields and saved values are shown for the intended project.              | That a provider accepts, authorizes, or can use the configuration.                   |
| Provider account        | The provider owner confirms the account-specific setup through the approved channel.  | That Dashboard sent data or that every future request will succeed.                  |
| Analytics               | An approved synthetic test produces the expected authorized evidence.                 | That all user interactions, orders, or customer data are collected correctly.        |
| Loyalty workflow        | An approved synthetic test shows the expected authorized provider result.             | That points, rewards, eligibility, payments, or customer notifications are complete. |
| User outcome            | The approved flow shows the intended result for the correct test account and channel. | That a save response alone changed access, account state, an order, or a payment.    |

If a provider, field, or section is missing, do not work around it by adding an identifier to another setting. Resolve the intended connection with the responsible provider and Dashboard owners.

For the product overview of Segment tracking, see [Segment on Ordering.co](https://www.ordering.co/integrations/segment/).

---

**Related guides:** [Settings categories](https://docs.ordering.co/docs/products/dashboard/settings/enterprise/) · [Developers](https://docs.ordering.co/docs/products/dashboard/settings/pro/developers/) · [Settings overview](https://docs.ordering.co/docs/products/dashboard/settings-overview/)