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.
API di prenotazione
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.
Ognuno restringe ciò che una data integrazione può effettivamente fare, senza restringere ciò che la piattaforma stessa può fare.
"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.
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.
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.
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
Cinque passaggi, ogni volta che una richiesta porta con sé una chiave API.
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.
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.
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.
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.
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'è
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.
{
"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"
}
}
]
}
}Il dettaglio che quasi nessuno spiega
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.
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.
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.