# Integration with menta tech

## Overview

menta tech is an infrastructure layer that enables official secondary marketplaces for ticketing platforms. It operates entirely on top of your existing systems: you remain the source of truth for users, tickets, ownership, and fulfillment, while menta tech provides the orchestration, logic, and user flows required to power secure, controlled resale.

The integration is intentionally simple. Rather than exposing dozens of disconnected endpoints, menta tech is structured around a small set of architectural decisions that determine how resale works inside your environment. Once these decisions are defined, the resale experience becomes fully automated and rule-driven through menta tech.

This documentation will guide you through those decisions. Each represents one boundary where your platform and menta tech interact, and together they form a complete, future-proof integration.

## What the Integration Consists Of

The integration is built around six key components. Each addresses a specific question about how resale should operate inside your ecosystem:

- **Event Sync** - How the structure of your events is delivered to menta tech so resale can be enabled for the correct units.

- **Information Structure** - How your categories or access levels are represented so that resale inventory can be grouped and displayed correctly.

- **Ticket Sync** - How ownership information is synchronized so users can list, manage, and transfer resale tickets.

- **Access to Sell** - How users enter the resale listing flow from your "My Tickets" experience.

- **Access to Buy** - How resale inventory appears on your event pages, and how users enter the resale purchase flow.

- **Authentication** - How users are validated between your platform and menta tech without duplicating identity systems.

This is the complete surface area of the integration. There are no additional hidden requirements. Every resale capability menta tech provides — from dynamic CTAs, to embedded UI components, to automated supply/demand balancing — is powered by one of these sections.

The API reference describes each endpoint in detail.

## What You Can Expect as You Continue

Each section of this documentation:

- Explains the purpose of the integration component
- Presents the available options
- Describes when each option makes sense
- Outlines how menta tech adapts to your architecture
- Keeps all complexity inside menta tech so your integration remains lightweight

By the end of the documentation, you will have a clear understanding of how to design, implement, and operate a fully integrated secondary marketplace with minimal engineering effort and maximum flexibility.

If this is your first time working with menta tech, the best place to start is the next section, Core concepts and data model. It introduces the entities and relationships used across the integration and forms the shared vocabulary for the rest of the guides.

## Core concepts and data model

### Entities

menta tech's data model mirrors how ticketing platforms already think about events and tickets.

- **Event** - A high level concept such as "Coldplay - Music of the Spheres". An event can have one or many shows.

- **Show** - A specific date or performance of an event. Each show belongs to one event and includes date, venue and configuration.

- **Access category (ticketOption)** - Represents the way fans access a show, for example "General Admission", "VIP", "Lower bowl". This is what resale buyers see and select.

- **Price variation (priceType)** - Represents how a ticket was priced initially, for example "Early bird", "Presale", "Standard". It is important for configuration rules, but in resale flows the buyer often only cares about the access category.

- **Ticket** - Represents a single ticket owned by a user. A ticket belongs to one show, one ticketOption, and optionally one priceType. Ticket data includes ownership, seating and other attributes.

- **User** - Represents the person who owns tickets or buys on resale. You identify the user by your own userId and optionally email or phone, depending on your identity model.