Carbone, tonight, table for two — filled in 6 minutes.
Quiet corner, vegetarian-first, before-the-theater timing. Picked up by three members; cleared at $1,400. Receipt and the booking transfer landed in Suite 1402’s name at 6:14pm.
An AT app is a web app you already know how to write — rendered inside the AppointmentTrader shell at a clean /apps/{id} URL, with a sidebar entry, theme sync, and a scoped SDK token for the active user. Read AT data, place bids, publish to the community feed, install into a user’s portal beside our own surfaces.
Drop your app id, entry URL, and menu allowlist into /config/atv2-apps.php. The host page at /apps/{id}/{subpath} renders the v2 shell, surfaces your menu in the sidebar, and embeds your entryUrl in a sandboxed iframe.
First-party apps (same origin) hit /v1/... directly with the user’s session. Third-party apps (cross-origin) request capabilities through a postMessage broker — the same bridge that gates publishing, profile reads, transaction lookups. Theme sync, navigation, and auth flow through automatically.
Once registered, your app appears as a row in the AT sidebar — alongside Home, Trending, Sellers. Users navigate into it the way they navigate into any other surface. Subpath changes flow over postMessage; the parent owns the address bar so internal navigation feels native, not iframed.
The same API surface that powers AppointmentTrader, exposed to your app with the scope you ask for and the user has granted.
The AT community newsfeed is just another endpoint. An app can compose a post, attach media, mention users, and ship it — same rate limits, same verification gates, same composer the platform uses internally. A bidding bot announces a fill. A loyalty tool celebrates a guest’s 100th transaction. An Encore widget posts the night’s recovered cover.
POST /v1/community/set_create_post
Per-session 15-second composer throttle · account verification gate · identical to the in-app composer.
Posting from an app uses the user’s identity, not the app’s. You ask, they grant, you post on their behalf. Revocable from any sidebar moment.
A user's full transaction ledger — deposits, payouts, refunds, fee receipts. Renders inside the AT shell, sidebar entry, the legacy module wrapped as an app on day one.
Buyer/seller messaging tied to live transactions. Same iframe model: legacy module re-rendered inside /apps/chat/ with no rewrite, picks up theme toggle and inline navigation for free.
A user's system-wide alert center — bid filled, transaction confirmed, message received. Subscribes to the same /v1/notification topics any third-party app can.
A hotel's internal concierge dashboard — intake form, reward calculator, member-pickup feed — rendered for the front-of-house team. Talks to the AT bidding endpoints via the SDK; pushes guest-fill receipts back into the property's PMS.
A restaurant manager's “released seats tonight” surface. Lists what Encore is filling in real-time, the diners who paid, which book entry to update. SDK-token-scoped to a single property.
A surface that doesn't exist yet — a shopping-clienteling app for a luxury house, a tee-time futures dashboard for a club, a venue-side transcript of every bid placed against a property.
The clearest fit for App Development today is partner-built internal tooling: a hotel concierge dashboard that talks to AT bidding, a restaurant Encore floor view that surfaces tonight’s recovered cover, a sales surface that lets a luxury house clientele a list of AT-active guests. The capability broker is reserved for exactly this — partner apps requesting AT-provided actions in a sandbox the platform owns.
If you’re already in the Elevé or Encore programs, an internal app is the natural next step. Your team builds the surface; we expose the data, the auth, and the install rail.
API Integration is your stack calling AT from outside — you own the UI, the users, the distribution; you just want AT data. App Development is the reverse: you ship a UI inside AT — a sidebar entry, a clean URL inside our shell, install into a user’s portal. Same endpoints under the hood; different reach. The right call when your users already live on AT or you want them to.
Anything the AT web app does, scoped by what the user has granted. Read market data, location search, public profiles. With a scoped API key plus a per-user grant: place bids, watch transactions, subscribe to webhook topics, post to the community newsfeed on the user’s behalf. Capabilities are declared in the app manifest and granted at install — users see the same scopes you ship with, and revoke from a single screen.
Yes. POST /v1/community/set_create_post with {boardId, title, body} — the same endpoint the in-app composer uses. The post arrives with the user’s name on it (your app posts on their behalf, not as itself), and the same per-session 15-second throttle and account-verification gates apply. Apps that need to ship public-feed updates are exactly what this surface was built for.
Today, registered apps live in /config/atv2-apps.php and surface as sidebar rows for everyone. The DB-backed registry with per-user enable rows is in progress — users will install from a discovery surface, scopes will be reviewed at grant time, and the sidebar entry will appear in their portal alongside Home, Trending, Sellers, and Partners. For partner-built internal tools, install is per-property and not visible to other tenants.
No. The host strips the v2 shell when serving your URL inside the iframe and wraps the body in a minimal envelope. Same index.php handles full-page mode and embed mode — you don’t even need to detect ?embed=1. We literally wrapped three legacy modules (Transactions, Chat, Notifications) as v2 apps on day one with no code changes. The bridge script is auto-injected; you only ship one if you’re cross-origin.
The host owns it. URLs always read /apps/{appId}/{subpath} — never the iframe’s real origin. Your app emits a {type:'navigated', path} postMessage when it changes routes; the parent calls history.pushState to keep the address accurate. Reloads, back-button, deep links — all native, all clean. The user never sees an iframe seam.
Free distribution. We revenue-share only on transactions an app originates — if the app drives a bid that AT fills, we split the fee; if the app is purely a tool that doesn’t move money, there’s no charge. Free tier on the API (10k calls/mo on user-scoped endpoints) covers most internal partner tools end-to-end. No SaaS, no per-seat license.
A 20-minute call with the partnerships lead. We’ll walk through the manifest, the SDK, the install path, and what your users would actually see in their sidebar.
Already in Elevé or Encore? An internal app is the natural next step. Back to Developer hub.
These are people you have bought from, sold to, or selected to follow. You can unfollow someone from their profile.
Verify your email to finish this step without losing what you started.
You are signed in
Loading this page with your account. This will only take a moment.