Crea la mia prenotazione

API di prenotazione

La stessa porta che attraversa la nostra dashboard.

Non esiste una versione separata e ridotta di Tiqory per le integrazioni. Un plugin WordPress, una connessione di reseller o il nostro stesso pannello di amministrazione chiamano esattamente lo stesso motore, tramite una chiave delimitata esattamente a ciò di cui ha bisogno.

  • 5 capacità products.read, checkout.create, leads.create, support.create e feedback.create, concesse indipendentemente per ogni chiave
  • Da 10 a 10.000/min Ogni chiave imposta il proprio limite di frequenza, isolato da qualsiasi altra chiave sullo stesso account
  • Mostrato una sola volta Il segreto completo appare una sola volta; Tiqory conserva solo il suo hash e un prefisso di ricerca

Quattro pezzi del controllo degli accessi.

Ognuno restringe ciò che una data integrazione può effettivamente fare, senza restringere ciò che la piattaforma stessa può fare.

01

Una chiave con nome per canale

"Web principale", "App mobile", "Agenzia Roma": tante chiavi quanti sono i canali, ognuna nominata per ciò che è, così che una fuga o un errore riconducano a una sola integrazione, mai a tutto l'account.

02

Capacità delimitate, non una chiave universale

Una chiave riceve esattamente le capacità di cui ha bisogno: leggere un prodotto, creare un checkout, inviare un lead, mai un accesso generale a tutto ciò che l'API può fare.

03

Pubblica dove aiuta, protetta dove non aiuta

Ogni organizzazione decide, per ogni capacità, se un browser può chiamarla direttamente o se deve passare da un server in possesso di una chiave. Lead, supporto e feedback ne richiedono sempre una.

04

Rotazione e revoca istantanee

Una chiave compromessa viene ruotata, e ogni chiamante che usa ancora il vecchio segreto smette di funzionare dalla richiesta successiva, senza alcuna scadenza di token da attendere.

Come si risolve

Come viene autorizzata una chiamata, passo dopo passo

Cinque passaggi, ogni volta che una richiesta porta con sé una chiave API.

  1. 1

    La chiave viene autenticata

    La chiave in chiaro arriva come prefix.secret. Il prefisso individua la riga, poi il segreto viene confrontato con il suo hash memorizzato tramite un controllo a tempo costante, mai un'uguaglianza semplice.

  2. 2

    La capacità viene verificata

    L'azione richiesta deve comparire esplicitamente nell'elenco concesso a quella chiave. Se manca, viene restituito lo stesso errore generico, che la chiave esista o meno.

  3. 3

    Si applica il limite proprio della chiave

    Il traffico su quella chiave viene conteggiato rispetto al proprio limite di frequenza configurato, isolato da qualsiasi altra chiave sullo stesso account. Il traffico pubblico senza chiave viene invece conteggiato per indirizzo IP.

  4. 4

    Ogni interrogazione gira delimitata, automaticamente

    Una volta autenticata, la chiamata opera esclusivamente all'interno dell'organizzazione di quella chiave. Non esiste percorso da una chiave al catalogo di un altro tenant, nemmeno indovinando un id interno.

  5. 5

    La chiamata viene registrata

    L'ultimo utilizzo e l'IP chiamante si aggiornano a ogni richiesta riuscita, così una chiave inattiva o dimenticata diventa visibile molto prima che qualcuno pensi a cercarla.

L'API, così com'è

Una chiamata, l'intero payload del negozio

Un prodotto cercato tramite il suo alias pubblico restituisce le sue opzioni, i tipi di biglietto, le date disponibili, i prezzi risolti e la capienza residua, già corretti per la valuta e il paese della richiesta.

GET /api/v1/products/city-food-tour
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
{
  "data": {
    "name": "City Food Tour",
    "alias": "city-food-tour",
    "currency": "EUR",
    "options": [
      {
        "code": "general",
        "next_slot": "2026-08-14T10:00:00+02:00",
        "remaining": 12,
        "price": {
          "amount": 42.5,
          "currency": "EUR"
        }
      }
    ]
  }
}
200 Prodotto risolto

Il dettaglio che quasi nessuno spiega

Una chiave sbagliata e il prodotto di qualcun altro sembrano identici

Un prodotto che appartiene a un'altra organizzazione e un prodotto che semplicemente non esiste restituiscono entrambi lo stesso identico "non trovato", mai un errore di permesso che confermerebbe che il prodotto esiste altrove. Una chiave non valida o revocata riceve un errore distinto tutto suo, ma nessuna risposta rivela mai se la risorsa richiesta appartenga a un altro tenant.

Domande frequenti

Ruotala. La rotazione emette immediatamente un nuovo prefisso e un nuovo segreto e invalida la coppia precedente, così ogni chiamante che usa ancora il segreto trapelato inizia a fallire dalla richiesta successiva, senza alcun ritardo di propagazione da attendere.

No. Ogni interrogazione autenticata da una chiave gira delimitata alla propria organizzazione. Un prodotto appartenente a qualcun altro restituisce lo stesso "non trovato" di uno che non esiste affatto.

No. products.read e checkout.create possono girare direttamente da un browser se l'organizzazione le lascia pubbliche. leads.create, support.create e feedback.create richiedono sempre una chiave, perché esistono proprio per essere chiamate da un server controllato dall'organizzazione.

Un valore predefinito ragionevole per ogni capacità, conteggiato per indirizzo IP: generoso per la navigazione, più stretto per creare un checkout o inviare un lead. Una chiave sovrascrive quel valore predefinito con il proprio limite configurato, da 10 a 10.000 richieste al minuto.

Una risposta 429 con un header Retry-After, oltre al limite e al numero di richieste rimanenti, così un'integrazione può rallentare automaticamente invece di indovinare quando riprovare.

Più prenotazioni. Più canali. La stessa calma.

Tiqory mantiene disponibilità, prezzi, pagamenti e accessi allineati mentre la tua operazione cresce. Dicci dove vuoi arrivare: ti mostriamo come farlo senza ricominciare da zero.