Sell an allocation as a partner

You have Partner access because an organizer assigned your organization part of one event. You do not receive a copy of the chart or a separate stock of seats. Your buyers use the organizer’s existing event and chart, restricted to the inventory assigned to you.

When one of your seats is held or sold, availability changes everywhere immediately. The organizer remains the owner of the event, checkout rules, payments, bookings, tickets, and customer support unless your commercial agreement says otherwise.

Choose how you will sell

Option 1: sell with a Hosted buyer link

This option requires no integration work from your team.

It is available only when:

• the organizer sells the event through SeatLayer checkout;
• the assigned channel uses Hosted link access; and
• your Partner access permission includes Create buyer links.

In your Partner access context:

1. Open Distribution.
2. Select the event allocation.
3. Choose Create buyer link.
4. Give the link an internal label that your team will recognize.
5. Set its expiry, maximum redemptions, seats per buyer, and buyer-session duration.
6. Copy the complete URL when it is revealed. It is shown only once.
7. Send that URL through your own approved email, CRM, package page, or support channel.

The buyer opens the organizer’s existing event and chart with your allocation already applied. Seats outside the permitted scope do not reveal their private state. Completed sales retain your channel attribution in organizer and partner reports.

Treat the URL like an invitation. Anyone who receives it can attempt to redeem access within its limits. Revoke it from Distribution if it is forwarded to the wrong audience.

Option 2: put the chart in your own system

Use this when your buyers should stay on your website or app.

This is a coordinated integration between your system and the organizer’s backend. Partner access does not issue an organizer secret key or direct booking authority.

The supported boundary today is:

1. Your website authenticates your buyer.
2. Your backend asks the organizer’s backend for scoped SeatLayer buyer access.
3. The organizer validates your contract and buyer reference.
4. The organizer’s backend mints a short-lived session for your assigned channel and your exact production origin.
5. Your page mounts the SeatLayer buyer SDK with that short-lived token.
6. The buyer selects seats and creates a hold.
7. Your checkout sends the order and hold reference to the organizer’s agreed booking endpoint.
8. The organizer verifies the hold and price, completes the SeatLayer booking, and returns the confirmed booking reference.

The organizer’s secret key stays on the organizer’s server. Never request it, put it in your application, or ask buyers to send a channel id from the browser. A channel id is a label, not authorization.

Information to exchange before development

Ask the organizer for:

• the event id and SeatLayer publishable key used by the buyer SDK;
• your production and test origins;
• the organizer endpoint that issues scoped buyer-access tokens;
• the organizer endpoint that accepts your checkout and hold reference;
• the buyer and partner reference format used for reconciliation;
• maximum seats per buyer and session duration;
• who owns payment capture, refunds, tickets, and customer support;
• test-event access and a non-production payment path; and
• webhook or status-callback behavior after a booking succeeds or fails.

Give the organizer:

• your test and production domain names;
• how your users authenticate;
• the stable buyer and order references you will send;
• your retry/idempotency behavior;
• the person responsible for checkout failures and reconciliation; and
• the date you need test and production access.

Browser integration shape

The organizer supplies the event id and publishable key. Your page obtains a short-lived token from your own backend; your backend obtains it through the organizer-approved broker flow.

const chart = new seatlayer.SeatingChart({
  container: "#seat-map",
  event: "ev_supplied_by_organizer",
  buyerAccessTokenProvider: async ({ reason }) => {
    const response = await fetch("/api/seatlayer-access", {
      method: "POST",
      credentials: "include",
      headers: { "content-type": "application/json" },
      body: JSON.stringify({ reason }),
    });

    if (!response.ok) throw new Error("Could not establish seat access");
    return response.json(); // { token, expiresAt }
  },
});

await chart.render();

Keep the token in memory only. Do not store it in local storage, put it in a query string, or write it to analytics and exception logs.

The full organizer-side implementation is in Private and partner sales.

Monitor and reconcile

Use Allocations to see the exact seats and statuses currently assigned to you. Use Reports to review allocation, attributed sales, sell-through, and download the scoped CSV.

Your reports do not expose sibling channels, organizer credentials, buyer identity, booking references, or organizer settings. Agree your own reconciliation keys with the organizer before selling.

Before you go live

• The correct event, channel, quantity, pricing, and access dates are visible.
• You know whether you are using a Hosted link or your own integrated checkout.
• Your test path cannot create a real customer charge.
• Buyer-link limits or SDK session limits match your agreement.
• Payment, booking, ticket, refund, and support ownership are written down.
• A successful test sale appears in both partner and organizer reports.
• An out-of-scope seat cannot be selected.
• Expired/revoked access and sold-out inventory have clear buyer messages.
• Your team knows how to revoke a link, return free inventory, and request more.

Related

• Private and partner sales — organizer and developer implementation
• Sales channels — allocation, roles, permissions, and lifecycle
• Buyer SDK setup
• Holds and checkout