---
title: "White Label Ordering Platform"
description: "Understand the white-label decisions in a branded Ordering.co implementation: customer-facing surfaces, operating responsibilities, and agreement scope."
canonical: https://www.ordering.co/developers/white-label/
---

# Make the brand experience clear before you scope the technology.

Ordering.co is a white-label ordering solution: the customer experience carries the operator’s brand while Ordering.co provides the platform underneath. The surfaces, rights, accounts, and responsibilities are agreed in your project scope.

[Talk to Ordering.co](https://www.ordering.co/contact/)[Read developer guides](https://www.ordering.co/solutions/agencies-resellers/)

- Branded experience
- Written scope
- Clear responsibilities

Verde CocinaMenuLocationsAccountCart

verdecocina.example

Luna PizzaMenuLocationsAccountCart

lunapizza.example

Illustrative brand treatments

Scope the customer experience

## Name every surface that needs a brand decision.

Ordering.co’s current public pricing materials list white-labeled marketplace websites, iOS and Android marketplace apps, and a dashboard. Treat that list as a starting point for a scope conversation, then document the exact surfaces and responsibilities for your project.

- ### Marketplace website
  Public Ordering.co pricing materials list a white-labeled marketplace website. Define the required identity, domain arrangement, content owner, and acceptance check for the website in your project scope.
- ### iOS and Android apps
  White-labeled iOS and Android marketplace apps can be published to the App Store and Google Play on every plan, by your team with the documentation or with support on request.
- ### Dashboard
  Public pricing materials also list a white-labeled dashboard. Record which operators need it, the branding decisions it carries, and the workflows it must support.
- ### Customer communications
  If messages, receipts, or support touchpoints are part of the brand promise, specify the channel, copy owner, data boundary, and acceptance check instead of assuming they are covered.
- ### Domains and accounts
  Write down which party owns domain, store, analytics, and service accounts. Ownership and access should be resolved before release work begins.
- ### Operating handoff
  Name who updates brand material, approves releases, responds to customers, and validates the finished experience once it is in use.

Who needs the decision

## White label is a coordination model, not only a visual treatment.

The same brand questions appear whether a business runs its own channel, an agency serves clients, or an existing product is adding ordering. The important distinction is who makes each operating decision and who accepts the result.

- [BrandA business running its own channelClarify the customer experience, the operating team, and the brand assets that need approval before implementation.](https://www.ordering.co/solutions/restaurants/)
- [AgencyAn agency or reseller serving clientsSeparate the agency’s delivery responsibilities from each client’s brand, account, data, and acceptance responsibilities.](https://www.ordering.co/solutions/agencies-resellers/)
- [ProductA product team adding orderingMap where ordering fits in the existing product and which team owns the interface, release, support, and ongoing change decisions.](https://www.ordering.co/solutions/software-companies/)

Write the boundaries down

## Turn brand decisions and platform responsibilities into one shared scope.

A white-label implementation needs more than a logo treatment. The project should identify the customer-facing decisions the operator approves and the technology, implementation, and support responsibilities the parties agree to in writing.

Operator decisions

### The experience to approve

- Brand identity and content rules
- Required customer-facing surfaces
- Domain and account ownership requirements
- Release and acceptance criteria
- Customer support and escalation model
- Ongoing change approvals

Implementation scope

### The work to define with the platform team

- Included technical surfaces
- Configuration and integration responsibilities
- Environment and credential handling
- Security and data responsibilities
- Release process and acceptance checks
- Maintenance and support terms

When branding is not the only decision

## Separate brand configuration from deeper technical requirements.

A branded surface may still leave product behavior, integrations, security, or operating workflows to resolve. Raise those requirements early, with documented acceptance criteria, so they are evaluated as scope rather than assumed to be part of white label.

- [01Integration and behavior requirementsUse the public developer reference to identify the operations, schemas, and handoffs that a product-specific build needs to review.](https://www.ordering.co/developers/)
- [02Commercial and operating termsDocument the included surfaces, rights, responsibilities, test conditions, and ongoing support expectations before the project relies on them.](https://www.ordering.co/solutions/custom-projects/)

## Bring a white-label scope, not just a mood board.

Start with the experience you need to brand, the teams and accounts involved, and the acceptance checks that matter. That creates a concrete basis for a scoped implementation conversation.

[Talk to Ordering.co](https://www.ordering.co/contact/)[Read developer guides](https://docs.ordering.co/docs/developers/)