Embedding PepoSmart in Your Portal

This guide is for teams who already run their own software portal and want their users to book meetings without leaving it. Because your portal already knows who the user is, you can carry their name and email straight into the booking flow so they never retype it.

Two ways to integrate

Embed the PepoSmart booking page in an iframe and let it handle the calendar, timezones and confirmations for you — fastest to ship. Or go headless with the REST API and build your own picker inside your portal. Most portals want the embed.

Option 1: Embed the booking page

Every booking page is a normal, framable URL. There are no X-Frame-Options or CSP frame-ancestors restrictions, so it can be embedded on any domain.

https://app.peposmart.com/book/{username}/{eventId}

You can generate a ready-made snippet from inside the app: open an event, choose Add to website, and pick inline, popup widget, or popup text. The dialog gives you the HTML with your colours already applied.

Inline embed

<!-- PepoSmart inline embed begin -->
<div style="min-width:320px;height:700px;">
  <iframe
    src="https://app.peposmart.com/book/jordan/evt_123"
    width="100%"
    height="100%"
    frameborder="0"
    style="border:0;"
    title="Book a meeting"></iframe>
</div>
<!-- PepoSmart inline embed end -->

Give it enough height

The booking page renders a calendar, a time list and a form. Below roughly 700px the iframe scrolls internally, which feels cramped on desktop. 700–900px is a good range; on mobile, let it fill the viewport.

Matching your portal's look

Append these query parameters to the booking URL. Colours are hex without the leading #.

Parameter	Example	Effect
`bg`	`ffffff`	Page background colour
`text`	`0f172a`	Body text colour
`primary`	`2563eb`	Buttons, selected time slot, accents
`hide_details`	`1`	Hides the left-hand event summary panel — useful when your portal already shows the meeting title and duration

https://app.peposmart.com/book/jordan/evt_123
  ?bg=ffffff
  &text=0f172a
  &primary=2563eb
  &hide_details=1

Prefilling the attendee's name and email

Status: not yet available — please contact us before building against it

The booking page does not currently read name or email from the URL. The parameters below describe the planned behaviour so you can design around it. It is a small change on our side; tell us you need it and we will confirm a date. Until then, embedded users type their own details, or you can use the REST API, which accepts the attendee today.

Once shipped, your portal will append the details it already holds, and the booking form will open with those fields filled in:

https://app.peposmart.com/book/jordan/evt_123
  ?name=Jane%20Doe
  &email=jane%40acme.com

Always URL-encode the values — @ becomes %40 and spaces become %20. In JavaScript, let URLSearchParams do it for you:

const params = new URLSearchParams({
  name: currentUser.fullName,
  email: currentUser.email,
  primary: "2563eb",
  hide_details: "1",
});

const src = `https://app.peposmart.com/book/jordan/evt_123?${params}`;
document.querySelector("#peposmart-frame").src = src;

Important: prefill is convenience, not authentication

Anything in a URL is visible and editable by the person in the browser. A user can open the iframe URL, change the email, and book as somebody else. That is usually fine — it is the same trade-off every scheduling embed makes — but you should decide deliberately.

If the booked identity has to be trusted

Use the REST API instead. Your backend holds the API key, asserts who the user is, and creates the booking server-to-server — the browser never gets to choose the attendee. We can also add a signed-parameter mode to the embed (your backend HMAC-signs the name and email so the page rejects tampered values); ask us if you need it.

Option 2: Popup instead of inline

If you would rather keep your own page and open scheduling over it, the Add to website dialog also produces a floating-button widget and a text-link version. Both open the same booking URL in a modal iframe, so every query parameter above applies unchanged.

Which option should you choose?

Consideration	Embed	REST API
Build effort	Paste an iframe	Build your own calendar UI
Timezones, slot logic, double-booking	Handled for you	Handled for you (server-side validation)
Look and feel	Colour parameters	Entirely yours
Attendee identity is trustworthy	No — user can edit	Yes — asserted by your backend
Paid event types	Supported	Not supported — redirect to the booking page

Our recommendation

Start with the inline embed plus prefill. It is the smallest amount of code on your side, and bookings made this way behave exactly like any other booking — calendar invites, reminders, video links and AI meeting notes all work normally. Move to the REST API only if you need your own UI or a tamper-proof attendee identity.

Next steps

Read the REST API reference for the headless route and for looking up event types programmatically.
See Events & Booking to set up the event type your portal will point at.
Need signed prefill, a higher rate limit, or multiple host accounts? Contact support.