Quels forfaits supportent les webhooks ?

Les webhooks sont disponibles sur les forfaits Pro, Business et Enterprise. Sur le forfait gratuit, les webhooks ne sont pas disponibles -- utilisez l'export manuel ou l'API publique.

Combien de fois tikento réessaie-t-il l'envoi en cas d'erreur ?

Trois tentatives avec délai exponentiel : après 1 minute, après 5 minutes, après 30 minutes. Si les trois tentatives échouent -- l'événement est marqué comme failed.

Comment vérifier la signature du webhook ?

Calculez le HMAC-SHA256 du corps de la requête avec votre webhook secret et comparez avec l'en-tête X-Tikento-Signature. Utilisez une comparaison en temps constant pour vous protéger contre les attaques temporelles.

Peut-on configurer plusieurs URL pour les webhooks ?

Oui. Dans la section Paramètres - Intégrations, vous pouvez ajouter plusieurs URL et choisir quels types d'événements envoyer à chacun d'entre eux.

Webhooks : événements et vérification de signature

Aperçu

Les webhooks permettent de recevoir des notifications sur les événements de la plateforme tikento en temps réel. Lorsqu'un événement survient (nouvelle inscription, paiement réussi, annulation d'un événement), tikento envoie une requête HTTP POST à votre URL avec les données de l'événement.

Les webhooks sont disponibles sur les forfaits Pro, Business et Enterprise.

Configuration

Ajout d'un URL de webhook

Ouvrez Paramètres dans le menu latéral.
Accédez à la section "Intégrations".
Cliquez sur "Ajouter un webhook".
Indiquez l'URL de l'endpoint (HTTPS obligatoire).
Sélectionnez les types d'événements que vous souhaitez recevoir.
Cliquez sur "Enregistrer".

Après l'enregistrement, tikento enverra une requête de test à l'URL indiqué pour vérifier la disponibilité.

Webhook secret

Lors de la création du webhook, le système génère un webhook secret -- une chaîne pour la vérification de la signature. Conservez-le en lieu sûr. Le secret n'est affiché qu'une seule fois.

Types d'événements

Événement	Description
`registration.created`	Nouvelle inscription créée
`registration.updated`	Données d'inscription mises à jour (statut, champs)
`payment.completed`	Paiement complété avec succès
`payment.refunded`	Remboursement effectué
`event.published`	Événement publié
`event.cancelled`	Événement annulé

Vous pouvez vous abonner à tous les types ou sélectionner uniquement ceux dont vous avez besoin dans les paramètres d'intégration.

Format du payload

Chaque webhook est envoyé en tant que HTTP POST avec un corps au format JSON.

En-têtes de la requête

En-tête	Description
`Content-Type`	`application/json`
`X-Tikento-Event`	Type d'événement (par exemple, `registration.created`)
`X-Tikento-Signature`	Signature HMAC-SHA256 du corps de la requête
`X-Tikento-Timestamp`	Timestamp Unix de l'envoi (secondes)
`X-Tikento-Request-Id`	Identifiant unique de la requête

Structure du corps

{
  "event": "registration.created",
  "timestamp": "2026-06-30T14:30:00Z",
  "requestId": "req_01912345abcdef",
  "data": {
    "id": "01912345-6789-7abc-def0-123456789abc",
    "event_id": "01900000-0000-7000-0000-000000000001",
    "status": "registered",
    "fields": {
      "registrant_email": "user@example.com",
      "first_name": "Ivan",
      "last_name": "Petrov"
    },
    "created_at": "2026-06-30T14:30:00Z"
  }
}

Le champ requestId est présent dans chaque webhook. Utilisez-le pour la déduplication et pour contacter le support.

Exemples de payload par type d'événement

registration.created

{
  "event": "registration.created",
  "timestamp": "2026-06-30T14:30:00Z",
  "requestId": "req_01912345abcdef",
  "data": {
    "id": "01912345-6789-7abc-def0-123456789abc",
    "event_id": "01900000-0000-7000-0000-000000000001",
    "event_slug": "tech-conference-2026",
    "status": "registered",
    "ticket_definition_id": "01900000-0000-7000-0000-000000000010",
    "fields": {
      "registrant_email": "user@example.com",
      "first_name": "Ivan",
      "last_name": "Petrov",
      "company": "Acme Corp"
    },
    "created_at": "2026-06-30T14:30:00Z"
  }
}

payment.completed

{
  "event": "payment.completed",
  "timestamp": "2026-06-30T14:31:00Z",
  "requestId": "req_01912345abcdf0",
  "data": {
    "id": "01912345-6789-7abc-def0-000000000099",
    "registration_id": "01912345-6789-7abc-def0-123456789abc",
    "amount": 5000,
    "currency": "RUB",
    "method": "card",
    "gateway": "yookassa",
    "idempotency_key": "idem_abc123",
    "completed_at": "2026-06-30T14:31:00Z"
  }
}

event.cancelled

{
  "event": "event.cancelled",
  "timestamp": "2026-06-30T15:00:00Z",
  "requestId": "req_01912345abcdf1",
  "data": {
    "id": "01900000-0000-7000-0000-000000000001",
    "slug": "tech-conference-2026",
    "title": "Tech Conference 2026",
    "cancelled_at": "2026-06-30T15:00:00Z",
    "reason": "Venue unavailable"
  }
}

Vérification de la signature

Chaque webhook est signé à l'aide de HMAC-SHA256. La vérification de la signature garantit que la requête provient d'tikento et non d'un attaquant.

Algorithme

Récupérez les valeurs des en-têtes X-Tikento-Timestamp et X-Tikento-Signature.
Formez la chaîne à signer : <timestamp>.<body>, où body est le corps brut de la requête.
Calculez le HMAC-SHA256 de cette chaîne avec votre webhook secret.
Comparez le résultat avec X-Tikento-Signature au format hexadécimal.

Exemple en Node.js

const crypto = require('crypto');

function verifySignature(body, timestamp, signature, secret) {
  const payload = `${timestamp}.${body}`;
  const expected = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');

  // Comparaison en temps constant pour se protéger contre les attaques temporelles
  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(signature)
  );
}

Exemple en Python

import hmac
import hashlib

def verify_signature(body: str, timestamp: str, signature: str, secret: str) -> bool:
    payload = f"{timestamp}.{body}"
    expected = hmac.new(
        secret.encode(),
        payload.encode(),
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

Protection contre les attaques par rejeu

Vérifiez X-Tikento-Timestamp : s'il date de plus de 5 minutes -- rejetez la requête. Cela empêche la réutilisation de webhooks interceptés.

Politique de nouvelles tentatives

Si votre endpoint ne répond pas avec un HTTP 2xx, tikento réessaie l'envoi :

Tentative	Délai
1	Immédiatement
2	Après 1 minute
3	Après 5 minutes
4	Après 30 minutes

Si les 4 tentatives (initiale + 3 réessais) échouent, l'événement est marqué comme failed. Vous verrez la liste des webhooks échoués dans la section Paramètres - Intégrations - Historique de livraison.

Ce qui est considéré comme un succès

HTTP 200, 201, 202, 204 -- la livraison est considérée comme réussie.
Timeout : la réponse doit être reçue dans les 10 secondes.

Ce qui est considéré comme une erreur

HTTP 4xx (sauf 410) -- nouvel envoi, problème possible du côté du destinataire.
HTTP 5xx -- nouvel envoi avec délai.
Timeout (pas de réponse en 10 secondes) -- nouvel envoi.
HTTP 410 (Gone) -- le webhook est automatiquement désactivé, pas de nouvelles tentatives.

Déduplication

En raison des nouvelles tentatives, votre endpoint peut recevoir le même événement plusieurs fois. Utilisez le requestId du payload pour la déduplication :

À la réception du webhook, vérifiez si vous avez déjà traité ce requestId.
Si oui -- retournez HTTP 200 sans traitement répété.
Si non -- traitez et enregistrez le requestId.

N'acceptez les webhooks que via HTTPS.
Vérifiez toujours la signature via HMAC-SHA256.
Vérifiez le timestamp pour vous protéger contre les attaques par rejeu.
Stockez le webhook secret dans les variables d'environnement, pas dans le code.