Metadata Discovery

Link to section

Overview

The /v1/meta endpoint is the foundation of working with the Reporting API. It returns a complete description of the available data model, including:

  • Cubes: Logical groupings of related metrics
  • Measures: Numeric aggregations you can calculate
  • Dimensions: Attributes for grouping and filtering
  • Segments: Predefined filters for common business logic

Understanding the metadata structure is essential for building dynamic, resilient clients.

Link to section

Views vs cubes

The /v1/meta endpoint returns two types of queryable entities: views and cubes. Each entry has a type field ("view" or "cube") that tells you which it is.

Link to section

Views — the recommended starting point

Views are curated, pre-joined interfaces designed for specific reporting use cases. They combine data from multiple cubes, pre-filter where appropriate, and expose human-readable dimensions.

For example, the Sales view:

  • Pre-filters to closed (fully settled) orders — no need to add segments: ["Orders.closed_checks"]
  • Includes location_name instead of just location_id
  • Has intuitive segments like Sales.online and Sales.in_store
  • Combines order, location, channel, and customer data in one queryable entity

Use views for most reporting tasks. They're simpler to query and less error-prone.

Link to section

Cubes — raw data for advanced use

Cubes are the underlying data building blocks. Each cube maps to a specific data domain (orders, items, payments, locations) and exposes its raw measures and dimensions. Cubes are useful when:

  • You need a field that isn't exposed in any view
  • You need raw, unfiltered data (e.g., including open or voided orders)
  • You're doing advanced analysis that doesn't fit a view's pre-defined shape

Warning

Some internal cubes are not intended for direct use. For example, ClosedOrders is an internal cube that backs the Sales view — its description says "Do not use directly — use Sales view instead." Always check a cube's description before querying it directly.

Link to section

How to tell them apart

# List all views curl -s -H "Authorization: Bearer $TOKEN" \ https://connect.squareup.com/reporting/v1/meta | \ jq '.cubes[] | select(.type == "view") | {name, description}' # List all cubes curl -s -H "Authorization: Bearer $TOKEN" \ https://connect.squareup.com/reporting/v1/meta | \ jq '.cubes[] | select(.type == "cube") | {name, description}'
Link to section

Fetching metadata

Link to section

Basic Request

curl -X GET "https://connect.squareup.com/reporting/v1/meta" \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \ -H "Content-Type: application/json"
Link to section

Response Structure

The metadata response is a JSON object with the following top-level structure:

{ "cubes": [ { "name": "Orders", "title": "Orders", "measures": [...], "dimensions": [...], "segments": [...] } ] }
Link to section

Understanding cubes

A cube represents a logical data model containing related measures and dimensions. Each cube corresponds to a business domain (e.g., Orders, Payments, Customers).

Link to section

Cube Structure

{ "name": "Orders", "title": "Orders", "description": "Sales order data including payments, items, and fulfillment", "measures": [...], "dimensions": [...], "segments": [...] }
Property_NameDescription
nameUnique identifier for the cube (used in queries)
titleHuman-readable display name
descriptionExplanation of what data the cube contains
measuresArray of available numeric aggregations
dimensionsArray of available grouping/filtering attributes
segmentsArray of predefined filters
Link to section

Common Views (Recommended)

ViewPurposeData Freshness
SalesOrder-level sales, revenue, tips, refunds — pre-filtered to closed orders~15 minutes
ItemSalesItem-level sales with discounts, modifiers, and category data~15 minutes
ModifierSalesModifier-level sales with modifier list metadata~15 minutes
SpeedOfServiceSpeed of service metrics and sales data~15 minutes
KDSKitchen Display System ticket and item performance~15 minutes
Link to section

Common Cubes (Advanced)

CubePurposeData Freshness
OrdersRaw order data including open/voided orders~15 minutes
ItemTransactionsRaw item transaction data~15 minutes
PaymentAndRefundsPayment and refund transaction details~15 minutes
LocationLocation reference data (name, timezone, status)N/A (reference)

Note

Use the /v1/meta endpoint or the Schema Explorer for the complete, up-to-date list of available views and cubes.

Link to section

Understanding measures

Measures are numeric values that can be aggregated (summed, averaged, counted, etc.). They represent the "what you're measuring" in your query.

Link to section

Measure Structure

{ "name": "Orders.net_sales", "title": "Net Sales", "description": "Total sales after discounts and returns, excluding tax", "type": "number", "aggType": "sum", "drillMembers": ["Orders.order_id", "Orders.sale_timestamp"], "format": "currency" }
Property_NameDescription
nameFully qualified measure name (Cube.measure)
titleHuman-readable display name
descriptionDetailed explanation of what the measure calculates
typeData type (number, string, time)
aggTypeAggregation type (sum, count, avg, min, max)
drillMembersSuggested dimensions for drill-down analysis
formatDisplay format hint (currency, percent, number)
Link to section

Common Sales Measures

From the Orders cube:

MeasureDescriptionUse Case
Orders.net_salesGross sales minus discounts/returnsPrimary revenue metric
Orders.net_sales_with_taxNet sales plus sales taxGross revenue in tax-inclusive regions
Orders.top_line_product_salesGross product sales before adjustmentsStarting point for sales funnel
Orders.discounts_amountTotal discounts appliedPromotional effectiveness
Orders.itemized_returnsValue of returned itemsReturn rate analysis
Orders.sales_tax_amountSales tax collectedTax reporting
Orders.tips_amountTips received (non-cash)Service performance
Orders.comps_amountComplimentary items valueComp tracking
Link to section

Measure Types and Aggregations

Link to section

Sum Measures

Most monetary measures use sum aggregation:

{ "name": "Orders.net_sales", "aggType": "sum" }
Link to section

Count Measures

For counting distinct entities:

{ "name": "Orders.count", "aggType": "count" }
Link to section

Average Measures

For calculating averages:

{ "name": "Orders.avg_net_sales", "aggType": "avg" }
Link to section

Understanding dimensions

Dimensions are attributes used to group, filter, or slice your data. They represent the "how you're slicing" your measures.

Link to section

Dimension Structure

{ "name": "Orders.location_id", "title": "Location ID", "description": "Unique identifier for the location where the order was placed", "type": "string", "suggestFilterValues": true }
Property_NameDescription
nameFully qualified dimension name (Cube.dimension)
titleHuman-readable display name
descriptionExplanation of what the dimension represents
typeData type (string, number, time)
suggestFilterValuesWhether the API can suggest filter values
Link to section

Dimension Types

Link to section

Categorical Dimensions

String-based attributes for grouping:

{ "name": "Orders.location_id", "type": "string" }

Common categorical dimensions:

  • Orders.location_id — Group by location
  • Orders.merchant_id — Group by merchant
  • Orders.sales_channel_id — Group by sales channel (online, in-person, etc.)
  • Orders.device_id — Group by device
Link to section

Time Dimensions

Special dimensions for time-series analysis:

{ "name": "Orders.sale_timestamp", "type": "time" }

Time dimensions support granularity:

  • day — Daily aggregation
  • week — Weekly aggregation
  • month — Monthly aggregation
  • quarter — Quarterly aggregation
  • year — Yearly aggregation
Link to section

Local Time Dimensions

For business-day alignment:

{ "name": "Orders.local_date", "type": "time" }

Use local time dimensions when you need results aligned to the location's timezone rather than UTC.

Link to section

Common Dimensions

DimensionTypeDescription
Orders.sale_timestamptimeUTC timestamp of sale
Orders.local_datetimeLocal date in location timezone
Orders.location_idstringLocation identifier
Orders.merchant_idstringMerchant identifier
Orders.sales_channel_idstringSales channel (e.g., online, in-person)
Orders.device_idstringDevice used for transaction
Orders.customer_idstringCustomer identifier
Link to section

Understanding segments

Segments are predefined filters that encapsulate common business logic. They ensure consistency across queries and simplify complex filtering.

Link to section

Segment Structure

{ "name": "Orders.closed_checks", "title": "Closed Checks", "description": "Filters to fully paid and settled orders, matching Sales Summary behavior" }
Property_NameDescription
nameFully qualified segment name (Cube.segment)
titleHuman-readable display name
descriptionExplanation of the filter logic
Link to section

Common Segments

SegmentPurpose
Orders.closed_checksFully paid/settled orders (recommended for Sales Summary parity)
Orders.open_checksOrders awaiting payment
Orders.awaiting_captureOrders awaiting payment capture
Orders.fully_paidFully paid orders
Orders.has_tipOrders that include a tip
Orders.no_tipOrders without a tip
Link to section

Why Use Segments?

Segments provide several benefits:

  1. Consistency: Ensures everyone uses the same filter logic
  2. Simplicity: Encapsulates complex conditions in a single reference
  3. Maintainability: Filter logic can be updated centrally
  4. Report Parity: Matches Square dashboard behavior

Example: Instead of manually filtering by order state:

{ "filters": [{ "member": "Orders.state", "operator": "equals", "values": ["COMPLETED"] }, { "member": "Orders.check_state", "operator": "equals", "values": ["CLOSED"] }] }

Simply use the segment:

{ "segments": ["Orders.closed_checks"] }
Link to section

Understanding meta tags

Cubes, measures, dimensions, and segments can include a meta field with additional metadata tags. These tags provide UI hints, stability information, and semantic context beyond the basic properties.

Link to section

Quick Reference

TagApplies ToPurpose
labelDimensions, Measures, SegmentsHuman-readable display label (e.g., "Net sales")
tooltipDimensions, Measures, SegmentsShort tooltip text for UI hover states
contextDimensions, Measures, SegmentsExtended context for LLMs and advanced UIs
stabilityCubes (required), Dimensions, MeasuresData quality and API stability level
deprecated_atCubes, Dimensions, MeasuresDeprecation date (ISO 8601, when stability is deprecated)
valuesDimensions, SegmentsAllowed values for enum-like fields
translation_typesDimensionsValues requiring localization
examplesCubesExample queries demonstrating cube usage
Link to section

Stability levels

The stability tag communicates the maturity and reliability of a cube or field:

ValueData QualityBreaking ChangesDescription
previewUncertain (may have missing data)Highly likelyEarly access, under active development
betaUncertain (often missing historical data)Unlikely but possibleApproaching general availability
gaVerifiedNoneGeneral Availability — production-ready
deprecatedN/AN/ASupported for 12+ months, then removed

Stability is set at the cube level and can be overridden at the field level. For example, a ga cube might have an individual measure marked as preview.

Link to section

Example: Meta tags in metadata response

{ "name": "Orders.net_sales", "title": "Net Sales", "type": "number", "aggType": "sum", "format": "currency", "meta": { "label": "Net sales", "tooltip": "Amount of gross sales minus discounts, comps, returns, refunds, tips, taxes, fees, or gift card sales.", "stability": "beta" } }
Link to section

Example: Dimension with allowed values

{ "name": "Orders.check_state", "title": "Check State", "type": "string", "meta": { "label": "Check state", "tooltip": "The payment status of the order.", "values": ["AWAITING_CAPTURE_CHECK", "CLOSED_CHECK", "OPEN_CHECK"] } }

For the complete meta tags reference with detailed examples and best practices, see the Meta Tags Reference.

Link to section

Parsing metadata programmatically

Link to section

Example: Extract All Measures from a Cube

Link to section

Example: Build a Dimension Selector

Link to section

Example: Validate Query Against Metadata

Link to section

Caching metadata

Metadata changes infrequently, so caching is recommended:

Link to section

Simple Time-Based Cache

Link to section

Best practices

Link to section

1. Cache Metadata Appropriately

  • Recommended TTL: 1-24 hours depending on your needs
  • Invalidation: Clear cache after query errors related to schema
  • Startup: Always fetch fresh metadata on application boot
Link to section

2. Build Dynamic UIs

Don't hard-code measure/dimension lists. Build them from metadata:

// Good: Dynamic const measures = metadata.cubes.Orders.measures.map(m => ({ label: m.title, value: m.name })); // Bad: Hard-coded const measures = [ { label: 'Net Sales', value: 'Orders.net_sales' }, { label: 'Tips', value: 'Orders.tips_amount' } ];
Link to section

3. Validate Before Querying

Check that your query components exist before sending to /v1/load:

# Validate first is_valid, error = validate_query(query, metadata) if not is_valid: raise ValueError(error) # Then execute results = execute_query(query)
Link to section

4. Use Segments for Report Parity

Always use Orders.closed_checks when building sales reports that should match the Square dashboard:

{ "measures": ["Orders.net_sales"], "segments": ["Orders.closed_checks"] }
Link to section

5. Document Your Dependencies

Track which measures and dimensions your application requires:

# app-requirements.yml required_measures: - Orders.net_sales - Orders.tips_amount required_dimensions: - Orders.location_id - Orders.sale_timestamp required_segments: - Orders.closed_checks
Link to section

Exploring metadata with jq

Use jq to explore metadata from the command line:

Link to section

List all views (recommended)

curl -s -H "Authorization: Bearer $TOKEN" \ https://connect.squareup.com/reporting/v1/meta | \ jq '.cubes[] | select(.type == "view") | .name'
Link to section

List all cubes

curl -s -H "Authorization: Bearer $TOKEN" \ https://connect.squareup.com/reporting/v1/meta | \ jq '.cubes[].name'
Link to section

Get all measures from Orders cube

curl -s -H "Authorization: Bearer $TOKEN" \ https://connect.squareup.com/reporting/v1/meta | \ jq '.cubes[] | select(.name == "Orders") | .measures[] | {name, title, description}'
Link to section

Find dimensions by type

curl -s -H "Authorization: Bearer $TOKEN" \ https://connect.squareup.com/reporting/v1/meta | \ jq '.cubes[] | select(.name == "Orders") | .dimensions[] | select(.type == "time") | .name'
Link to section

List all segments

curl -s -H "Authorization: Bearer $TOKEN" \ https://connect.squareup.com/reporting/v1/meta | \ jq '.cubes[] | select(.name == "Orders") | .segments[] | {name, title}'