Authentication
The Qariyb API uses key-based authentication. Server-to-server requests to the REST API are authenticated with your secret key; browser widgets and Qariyb Elements are authenticated with your publishable key.
Every integration is issued a matched pair of keys from a single organization:
- Publishable key (
pk_live_…) — safe to embed in the browser. Used by widgets and Qariyb Elements via theX-Widget-Keyheader. - Secret key (
sk_live_…) — server-side only, keep it private. Used by the REST API via theAuthorization: Bearerheader.
Keys are always live. Test mode was removed: there are no pk_test_ / sk_test_ variants, and a key using those prefixes is rejected on format before any lookup.
API keys are scoped to a single organization. A key can only read and write that organization's events, checkout, and RSVP data.
Which key, which API
The key you hold decides which API you are calling. They are two separate surfaces, not two ways into the same one.
| Widgets & Qariyb Elements | REST API | |
|---|---|---|
| Key | pk_live_… publishable | sk_live_… secret |
| Header | X-Widget-Key | Authorization: Bearer |
| Base path | /api/v1/public/* | /api/v1/* |
| Runs in | The browser | Your server |
| Reference | Public events · Public checkout | Events · Checkout |
Building a custom checkout on your own website? Either surface can do it, and the choice is simply where your code runs:
- No backend, or you want the browser to talk to Qariyb directly — use the publishable key and the public endpoints. This is the same surface Qariyb Elements uses, so you get the Stripe.js flow without running a server. See Public checkout.
- You already have a backend and want checkout to run there — use the secret key and the REST endpoints, and have your own frontend talk to your server rather than to Qariyb. See Checkout.
Do not mix them. A publishable key sent to a REST endpoint is rejected with
607, and a secret key sent from a browser is a credential leak, not a
configuration mistake — it is not scoped to one event or one action, so anyone
who reads it can act as your whole organization.
Secret key authentication
Server-to-server requests to the REST API (/api/v1/*) must include your secret key in the Authorization header with the Bearer prefix:
Authenticated request
curl https://api.qariyb.com/api/v1/events \
-H "Authorization: Bearer sk_live_..." \
-H "Accept: application/json"
Alternatively, you may pass the secret key in the X-Secret-Key header:
Using X-Secret-Key
curl https://api.qariyb.com/api/v1/events \
-H "X-Secret-Key: sk_live_..." \
-H "Accept: application/json"
Always include the Accept: application/json header to ensure you receive JSON responses.
Creating API keys
API keys are created through the Qariyb developer dashboard:
- Log in to your Qariyb organizer account
- Navigate to Settings → Developer → API keys
- Click Create API Key
- Give the key a descriptive name
- Copy and securely store the secret key
Creating a key issues a matched pair: a publishable key (pk_live_…) and a secret key (sk_live_…). The secret key is displayed once at creation and cannot be revealed later — Qariyb stores only a hash. If you lose it, rotate the key to generate a new secret.
Key security
Treat your secret key like a password. Never commit it to version control or expose it in client-side code. Only the publishable key is safe for the browser.
Best practices for key security:
- Store secret keys in environment variables
- Never expose the secret key in browser or mobile client code
- Rotate keys periodically
- Rotate immediately if a secret key may have been exposed
Rate limiting
Rate limits are per API key, counted per minute. Each key carries its own
rate_limit_per_minute value, which defaults to 120:
| Surface | Limiter | Default | Counted by |
|---|---|---|---|
REST API (/api/v1/*) | api | 120 / min | API key |
Widget reads (/api/v1/public/*) | widget | 120 / min | API key + client IP |
| Widget checkout & RSVP writes | widget-checkout | 60 / min | API key + client IP |
Checkout and RSVP writes are deliberately budgeted at half the key's read
limit, because they create carts and orders rather than just reading. Raising a
key's rate_limit_per_minute raises both proportionally.
Rate limit headers are included in throttled responses:
Rate limit headers
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 98
On a 429 the response also carries Retry-After (seconds) and
X-RateLimit-Reset (Unix timestamp).
When you exceed the rate limit, you will receive a 429 Too Many Requests response:
429 Response
{
"success": false,
"code": 206,
"message": "Too many requests. Please try again later."
}
Widget key authentication
The public widget API (/api/v1/public/*) uses the publishable key. It is designed for embedding checkout widgets on third-party websites and does not require user authentication.
Include your publishable key in the X-Widget-Key header:
Widget key request
curl https://api.qariyb.com/api/v1/public/events/01HWX9KPQR \
-H "X-Widget-Key: pk_live_..." \
-H "Accept: application/json"
You can also pass it as a widget_key query parameter when a header cannot be set:
Widget key as query param
curl "https://api.qariyb.com/api/v1/public/events/01HWX9KPQR?widget_key=pk_live_..."
The publishable key is managed alongside the secret key through the Developer dashboard under API keys. Each integration has:
- Publishable key (
pk_live_*) — safe for client-side use - Secret key (
sk_live_*) — for the server-side REST API only - Domain restrictions — optionally restrict which domains can use the publishable key
Widget API rate limits: 120 requests/minute for reads, 60 requests/minute for checkout and RSVP writes — both at the key's default. Unlike the REST API, the widget limiters also key on the caller's IP address, so one busy visitor cannot exhaust the whole organization's budget.
Key permissions
API keys are scoped to the organization that created them. This means:
- A key can only access events owned or managed by that organization
- The secret key grants full REST API access for that organization
- The publishable key is limited to public read and checkout/RSVP endpoints