Get comprehensive store information
Returns comprehensive store metadata and configuration in a single API call. Designed for LLMs and AI agents to quickly understand store context without making multiple API calls.
Purpose: This endpoint consolidates store metadata that would normally require 10+ separate API calls:
- Store basic info (name, currencies, timezone)
- Catalog overview (products, categories, collections, brands, specifications)
- Pricing configuration (dynamic pricing, customer tiers, rules)
- Active promotions (types, counts)
- Payment methods (providers, configurations)
- Shipping zones (delivery fees, free thresholds)
- CMS content (posts, lookbooks)
- Feature flags (enabled capabilities)
Use Cases:
- AI agents understanding store capabilities before making recommendations
- Admin dashboards showing store overview
- Integration setup wizards checking store configuration
- Mobile apps caching store metadata on startup
- Third-party tools discovering available features
Performance:
- Cached for 5 minutes (300 seconds)
- Parallel data fetching for all sections
- Optional section filtering to reduce payload size
- Typical response time: 50-150ms (cached: 10-20ms)
Selective Loading:
Use the sections parameter to request only specific data sections, reducing payload size
by 50-80% when you don’t need all information.
Single-store only. This endpoint describes one store. A marketplace operator key has no
single store here and receives 403 — use GET /v1/marketplace/info for the marketplace’s own
information, or GET /v1/marketplace/info?store_id=<merchant> for one merchant within it.
Authorizations
API Key Authentication
Use your API key in the Authorization header:
Key Types:
Secret Keys (Server-Side Only):
- Format:
tybrite_sk_live_*(production) ortybrite_sk_test_*(sandbox) - Full read/write access to all endpoints
- ⚠️ NEVER expose in client-side code or public repositories
- Required for: write operations, authentication, payment verification, AI recommendations
Publishable Keys (Client-Safe):
- Format:
tybrite_pk_live_*(production) ortybrite_pk_test_*(sandbox) - Read-only access (GET requests only, plus POST semantic search)
- ✅ Safe for client-side JavaScript, mobile apps, and public code
- Allowed for: browsing products, search, CMS content, pricing queries
Endpoint-Specific Requirements:
- Authentication endpoints (
/v1/auth/*): Secret key required - Payment verification (
POST /v1/payments/verify): Secret key required - AI Recommendations (
POST /v1/recommendations): Secret key required - Semantic Search (
POST /v1/search): Both key types allowed (read-only operation) - All write operations: Secret key required
- All read operations: Both key types allowed
Using a publishable key for restricted operations returns 403 Forbidden.
Query Parameters
Comma-separated list of sections to include in the response. Omit to return all sections.
Available Sections:
catalog- Products, categories, collections, brands, specificationspricing- Dynamic pricing configuration and rulespromotions- Active promotions and typespayments- Payment providers and methodsshipping- Delivery zones and feescms- CMS posts and lookbooksfeatures- Feature flags and capabilities
Note: The store section is always included regardless of this parameter.
Examples:
sections=catalog,features- Only catalog and featuressections=payments,shipping- Only payment and shipping info- Omit parameter - All sections included
Payload Size Reduction:
- Full response: ~15-25KB
catalogonly: ~8-12KB (50% reduction)features,payments: ~2-3KB (85% reduction)
SDK Usage:
"catalog,features"
Control cache behavior. Set to false to bypass cache and fetch fresh data.
Default: true (use cache if available)
Cache Duration: 5 minutes (300 seconds)
When to Bypass Cache:
- After updating store configuration
- After adding/removing products or categories
- After changing payment or shipping settings
- When you need real-time data
Cache Headers:
X-Cache: HIT- Response served from cacheX-Cache: MISS- Response fetched from databaseCache-Control: public, max-age=300- Browser/CDN caching
SDK Usage:
Response
Store information retrieved successfully
Basic store information (always included)
Catalog overview (optional, included when requested)
Pricing configuration (optional, included when requested)
Promotions overview (optional, included when requested)
Payment configuration (optional, included when requested)
Shipping configuration (optional, included when requested)
CMS content overview (optional, included when requested)
Feature flags (optional, included when requested). Each flag is a boolean answering "should the storefront show this capability right now?" — use them to decide which UI to render.
What true / false mean. A flag is true only when the capability is BOTH available to the store AND has data/config to surface. false is deliberately broad — it can mean any of: the store's plan doesn't include the feature, the plan includes it but it isn't set up/has no data yet, or both. A false flag therefore does NOT tell you why it's off; treat it simply as "don't render this yet."
Two kinds of flag:
-
Plan-gated —
ai_recommendations,semantic_search,multi_currency,dynamic_pricing,cms,lookbooks,returns.truerequires the store's plan to include the feature AND it to be configured. By plan: Starter includes none of these; Growth adds content pages/lookbooks (cms,lookbooks) andreturns; Premium and Enterprise add smart search & recommendations (ai_recommendations,semantic_search),dynamic_pricing, andmulti_currency. -
Data-presence (every plan) —
gift_cards,promotions,messaging,specifications,collections. Not plan-gated at all;truesimply means the store currently has at least one of that item (e.g.gift_cards: true= the store has issued one or more gift cards).falsemeans none exist yet, not that the feature is forbidden.
Indicates whether this store is part of a marketplace, so a storefront can adapt its experience accordingly.

