Skip to content

Which key to use

You are building Key Header Endpoints
A website that sells trips Website key, tp_pk_… Tp-Publishable-Key: tp_pk_… /v1/public/*
A link from a seller’s own system Secret key, tp_sk_… Authorization: Bearer tp_sk_… /v1/*

Every key belongs to one seller, or for a website key, to one of the seller’s sites. The API takes the seller, the site, its languages and its currencies from the key and never from your request, so there is no seller id to send and no way to read another seller’s trips or bookings.

A website key names one site, which tourpingo calls a storefront. It reads the site’s catalog and books on it; it can’t change anything else.

  • It is not a secret: it identifies the site, like a shop’s address.
  • To try the API before you have a site, use the demo seller’s key, which every example on this site runs with.
  • From your server it always works. From a browser, it works only on the addresses the site lists as its allowed origins, none at first, so a copied key can’t power someone else’s site.
  • An owner or admin makes, rotates and revokes website keys in the portal’s settings, under API keys, Website keys, and lists the site’s allowed origins there. A rotated key keeps working for 24 hours by default, so your site can switch to the new one.
  • Keep it in your configuration, not in your code, so staging and your live site can use different keys.

A secret key is for a seller’s own systems: importing trips, copying bookings into accounts, and the like.

  • An owner or admin makes it in the portal’s settings, under API keys, ticking only the scopes it needs. It is shown once.
  • It acts for the person who made it, with the scopes it was given, and only while their role allows. It stops working when it is revoked or when that person leaves the team.
  • Never put it in a browser, an app or a repository.
The seller's pending bookings, with a secret key
Terminal window
curl "https://api.stg.vacationpackagesoman.com/v1/bookings?status=pending&limit=20" \
-H "Authorization: Bearer $TP_SECRET_KEY"
Answer: 200 OK
{
"data": [
{
"ref": "TP-7KQM-2XWD",
"status": "pending",
"start": "2026-12-02",
"pax": 2,
"product_id": "6c2a1d4f-9e3b-4a7c-8d52-3f8b0e1c7a24",
"trip": "Abu Dhabi city tour, full day",
"option": "Private car",
"channel": "direct",
"total": {
"amount": 32000,
"currency": "USD"
},
"lead_name": "Amina Yusuf",
"expires_at": "2026-10-04T09:00:00.000Z",
"payment_status": "unpaid",
"details": {
"status": "not_needed",
"due_at": null,
"needed": 0,
"complete": 0,
"overdue": false
},
"created_at": "2026-10-02T09:00:00.000Z"
}
],
"next_cursor": null,
"total": 1
}

A secret key without the permission an endpoint needs gets 403 NotPermitted, with the permission it lacks.

When a traveller signs in on a site (by an emailed link or a passkey), the API sets a traveller session cookie. Your server passes it on with the website key, as it got it, and the traveller’s own bookings open without a token. A staff session never works in its place.