ID du formulaire

Comment ça marche

Chaque contrôle que traverse une soumission, dans l'ordre, et ce que chacun peut renvoyer.

Chaque envoi vers /f/<formId> traverse le même pipeline. Les contrôles peu coûteux passent en premier, donc un flood ou un formulaire inconnu ne coûte presque rien. Le premier contrôle qui échoue détermine la réponse.

Les contrôles que traverse une soumission, dans l'ordre

Avant la lecture du corps

  1. 1Garde anti-flood600 par minute et par IP, tous formulaires confondus429 rate_limited
  2. 2Recherche du formulaireFormulaires inconnus, supprimés ou désactivés404 not_found
  3. 3Limites de débit du formulaireLe préréglage du formulaire, par visiteur et par formulaire429 rate_limited
  4. 4En pauseLe formulaire est en pause dans le tableau de bord403 form_paused

Lecture de l'envoi

  1. 5Analyseurlencoded, multipart ou JSON, UTF-8, limites de taille400, 413, 415 ou 422
  2. 6Clé APISeulement si un en-tête Authorization est envoyé403 forbidden
  3. 7Domaines autorisésOrigin ou Referer comparé aux domaines du formulaireSpam, ou 403
  4. 8Vérification humaineToken Turnstile, quand la vérification est active403, ou une page de vérification

Évaluation

  1. 9ValidationSelon les champs publiés, s'il y en a422 validation_failed
  2. 10ScoreHoneypot, timing, liens, mots-clés, doublonsSpam à partir de 5
  3. 11IdempotenceUne clé répétée rejoue la première réponseRejeu, 409 ou 422
  4. 12Usage mensuelLargement au-delà de la limite de l'espace de travail429 quota_exceeded

Stockée

Soumission enregistrée

201 pour le code, 303 pour les navigateurs

  • WebhooksSignés, retentés pendant environ 3 jours
  • E-mail de notificationAux destinataires du formulaire
  • Tableau de bord et APIEn direct, immédiatement

Le spam est stocké aussi, et reçoit une réponse de succès, mais n'envoie rien.

Le rôle de chaque étape

Les limites de débit avant tout

Les limites de débit s'appliquent avant la lecture du corps. La garde anti-flood (600 par minute et par IP) passe même avant la recherche du formulaire, donc un flood n'atteint jamais la base de données. Les règles propres au formulaire s'appliquent juste après la recherche. Les requêtes refusées n'entament pas le quota. Les chiffres exacts sont sur Limites de débit.

Analyse

Le corps est analysé en urlencoded, multipart ou JSON. Le texte est décodé en UTF-8 et normalisé en NFC, les CRLF deviennent des LF et les caractères de contrôle sont supprimés. Les noms qui commencent par _ sont des instructions réservées, comme _redirect et _subject, et ne sont jamais stockés comme réponses. Voir Formulaires HTML.

Qui l'a envoyé

Un en-tête Authorization: Bearer est facultatif. Une clé secrète (ik_sk_) avec la portée submissions:write contourne le contrôle des domaines autorisés et la vérification humaine d'Ikiform. Une clé publiable (ik_pub_) ne fonctionne que depuis les domaines listés sur la clé. Sans clé, l'envoi est jugé selon son Origin.

Spam

Le spam n'est jamais une erreur. Un envoi qui échoue à la règle des domaines autorisés en mode spam, ou dont le score atteint 5 ou plus, est stocké avec le statut spam et reçoit la même réponse de succès qu'un vrai envoi : les bots n'apprennent rien. Le spam n'envoie ni webhook ni e-mail et ne compte pas dans l'usage. Voir Protection anti-spam.

Stocker et livrer

La soumission, ses livraisons de webhook et son e-mail de notification sont écrits en un seul lot dans la base de données, puis confiés à une file d'attente. La livraison des webhooks et l'e-mail ne ralentissent jamais la réponse, et une soumission n'est jamais stockée sans ses livraisons.

JSON ou redirection

Le même endpoint répond aux navigateurs avec des pages et au code avec du JSON. Ikiform décide à chaque requête :

Comment Ikiform choisit entre une réponse JSON et une redirection, de haut en bas
  1. 1Accept contient application/jsonJSON
  2. 2Le corps est du JSONJSON
  3. 3Sec-Fetch-Mode: navigateRedirection ou page
  4. 4Tout autre Sec-Fetch-Mode, comme corsJSON
  5. 5Pas de Sec-Fetch-Mode, Accept contient text/htmlRedirection ou page
  6. 6Tout le reste, comme curlJSON

La première règle qui correspond l'emporte.

En mode JSON, un succès renvoie 201 { "ok": true, "id": "sub_..." }. En mode page, un succès est une redirection 303, et les erreurs affichent une page d'erreur hébergée qui liste les problèmes par libellé de champ.

Une fois la soumission stockée

QuoiQuandDétails
WebhooksQuelques secondes après, avec de nouvelles tentatives pendant environ 3 joursWebhooks
E-mail de notificationQuelques secondes après, si les notifications sont activées pour le formulairePlafonné à 50 e-mails par formulaire et par heure (10 pour les espaces de travail de moins de 7 jours), puis un récapitulatif horaire
Tableau de bordImmédiatement, en directLe spam apparaît sous le filtre spam
API RESTImmédiatementAPI REST
Les formulaires dont les soumissions contiennent des noms de champs évoquant un mot de passe, une carte bancaire ou une phrase de récupération sont signalés, et leurs e-mails de notification sont retenus pour vérification. Ne collectez pas d'identifiants avec un backend de formulaires.

Identifiants

IdFormatRemarques
Formulairefrm_xxxxxxxxxxxxxxxxfrm_ suivi de 16 caractères aléatoires. Public : il figure dans l'URL d'action de votre formulaire.
Soumissionsub_01k7v2c9t3e8m5q4x6z0a1b2c3sub_ suivi de 26 caractères, triés par date.
Livraison de webhookdlv_...Envoyé dans webhook-id ; reste identique d'une tentative à l'autre.
Requêtereq_...Chaque réponse a un en-tête X-Request-Id. Indiquez-le quand vous contactez l'assistance.
{ "ok": true, "id": "sub_01k7v2c9t3e8m5q4x6z0a1b2c3" }