Browser and Server Usage

Browser and storefront calls

A publishable key can run these methods straight from the browser:

• org.info()
• categories.list(), services.list(), inventory.list(), inventory.getGroup()
• availability.calendar(), availability.items(), pricing.quote()
• bookings.create({ ..., asRequest: true })
• saleItems.list(), saleItems.get(), and saleLines on quotes and booking requests, while the organization sells to customers

The public API accepts browser requests from any origin, so there is no domain to register. The SDK sends only the Authorization, Accept, and Content-Type headers on its own. If you add custom headers, browsers block the request; see Request Options.

Server calls

Use a secret key from a trusted server for:

• org.summary(), inventory.status()
• Regular bookings: bookings.create() without asRequest, bookings.list(), bookings.get(), bookings.addNote()
• clients.lookup(), clients.create()
• sales.list(), sales.get(), sales.create()
• All reports
• adjustment and allowOutsideWorkingHours on bookings, and supplier-sourced subrental products

Secret keys belong in server environment variables. Do not give them a prefix that exposes values to browser bundles, such as NEXT_PUBLIC_ or NUXT_PUBLIC_.

Frameworks

Use @requiply/api-sdk directly. A common setup creates two clients:

// lib/requiply.ts
import { RequiplyClient } from '@requiply/api-sdk';

// Safe to ship to the browser.
export const storefront = new RequiplyClient({
  apiKey: 'rq_pk_live_...',
});

// Import only from server code: route handlers, server actions, Nuxt server/ routes.
export const createServerClient = () =>
  new RequiplyClient({ apiKey: process.env.REQUIPLY_SECRET_KEY! });

Keep the server client in a module only server code imports. If a secret-key client is created in a browser anyway, the SDK throws a TypeError instead of sending the key.

Payment providers

bookings.create() and sales.create() accept payOnPickup, stripe, wayforpay, monobank, and liqpay. An online method needs an active payment integration for that provider; the response then carries a paymentUrl to send the customer to (bookings also return paymentRedirect, which can be a form post).