Zum Hauptinhalt springen
Produits pris en charge
Exige l'un des produits suivants ou un produit supérieur.
Content Hub
Content HubEntreprise
Dernière modification : 26 septembre 2025

Remarque :

Cette page contient des informations de référence pour les fonctions sans serveur créées à l’aide du gestionnaire de conception. Historiquement, il s’agit de la façon originale de créer des fonctions sans serveur pour vos pages CMS et elle est toujours prise en charge. Cependant, à l’avenir, il est recommandé de créer et de déployer des fonctions sans serveur avec des projets développeur HubSpot. Les fonctions sans serveur basées sur des projets peuvent inclure des dépendances tierces et avoir un accès plus direct à l’authentification via des jetons d’accès d’application privée.
Dans cet article, découvrez les fichiers contenus dans un dossier .functions sans serveur ainsi que les commandes d’ILC que vous pouvez utiliser avec les fonctions sans serveur. Pour un aperçu de haut niveau des fonctions sans serveur, consultez la présentation des fonctions sans serveur. Pour plus d’informations sur la création de fonctions sans serveur avec des projets pour les modules et partials rendus JavaScript, consultez la documentation relative aux projets de développement.

Serverless.json

Dans le dossier .functions, le fichier serverless.json stocke la configuration de la fonction sans serveur. Ce fichier est obligatoire et mappe vos fonctions à leurs points de terminaison.
{
  "runtime": "nodejs20.x",
  "version": "1.0",
  "environment": {
    "globalConfigKey": "some-value"
  },
  "secrets": [
    "secretName"
  ],
  "endpoints": {
    "events": {
      "file": "function1.js",
      "method": "GET"
    },
    "events/update": {
      "method": "POST",
      "file": "action2.js",
      "environment": {
        "CONFIG_KEY": "some-other-value"
      },
      "secrets": [
        "googleKeyName",
        "otherkeyname"
      ]
    }
  }
}
cléTypeDescription
runtimeChaîneL’environnement d’exécution. Prend en charge Node.js v20 (nodejs20.x).
versionChaîneLa version du schéma de la fonction sans serveur HubSpot. (Version actuelle 1.0)
environmentObjetLes variables de configuration transmises à la fonction d’exécution en tant que variables d’environnement au moment de l’exécution. Vous pouvez utiliser cela pour ajouter une logique permettant d’utiliser une version de test d’une API au lieu de la véritable API, en fonction d’une variable d’environnement.
secretsTableauUn tableau contenant les noms des secrets que votre fonction sans serveur utilisera à des fins d’authentification. Ne stockez pas les secrets directement dans ce fichier. Indiquez seulement leurs noms.
endpointsObjetLes points de terminaison définissent les chemins qui sont exposés et leur correspondance avec des fichiers JavaScript spécifiques dans votre dossier de fonctions. Découvrez-en davantage sur les points de terminaison ci-dessous.
HubSpot ne prendra plus en charge le nœud 18 au-delà du 1er octobre 2025. Au-delà de cette date, les fonctions sans serveur dont le runtime est inférieur à v20 ne pourront plus être déployées.\

Remarque :

N’attribuez pas le même nom à vos secrets et à vos variables d’environnement. Cela entraînera des conflits lors du renvoi de leurs valeurs dans la fonction.

Points de terminaison

Chaque point de terminaison peut avoir ses propres variables d’environnement et secrets. Les variables spécifiées en dehors des points de terminaison doivent être utilisées pour les paramètres de configuration qui s’appliquent à toutes les fonctions et à tous les points de terminaison.
"events/update": {
      "method": "POST",
      "file": "action2.js",
      "environment": {
        "configKey": "some-other-value"
      },
      "secrets": ["googleAPIKeyName","otherKeyName"]
    }
cléTypeDescription
methodChaîne ou tableau de chaînesLa ou les méthodes HTTP que le point de terminaison prend en charge. La valeur par défaut est GET.
fileChaîneLe chemin d’accès au fichier de fonction JavaScript avec l’implémentation pour le point de terminaison.
Le point de terminaison peut être appelé en appelant une URL de l’un des domaines connectés au compte HubSpot, y compris les sous-domaines par défaut .hs-sites.com, avec la structure d’URL suivante : https://{domainName}/_hcms/api/{endpoint-name/path}?portalid={hubId}.
ParamètreDescription
domainNameUn domaine connecté au compte HubSpot.
/_hcms/api/Le chemin d’accès réservé aux fonctions sans serveur. Tous les points de terminaison se trouvent à l’intérieur de ce chemin.
endpoint-name/pathLe nom ou le chemin d’accès du point de terminaison que vous avez spécifié dans le fichier serverless.json.
portalidUn paramètre de requête facultatif contenant votre ID de compte HubSpot. En fournissant ces informations dans la requête, vous pourrez tester vos fonctions dans les aperçus de modules et de modèles.
Par exemple, si website.com et subdomain.brand.com sont connectés au compte, vous pouvez appeler la fonction à l’aide de https://website.com/_hcms/api/{endpoint-name/path} ou https://subdomain.brand.com/_hcms/api/{endpoint-name/path}.

Fichier de fonction

Outre le fichier de configuration serverless.json, le dossier .functions contiendra également un fichier JavaScript Node.js qui définit la fonction. Vous pouvez également utiliser la bibliothèque de requêtes pour effectuer une requête HTTP vers les API de HubSpot et d’autres API. Par exemple :
// Require axios library, to make API requests.
const axios = require('axios');
// Environment variables from your serverless.json
// process.env.globalConfigKey

exports.main = (context, sendResponse) => {
  // your code called when the function is executed

  // context.params
  // context.body
  // context.accountId
  // context.limits

  // secrets created using the CLI are available in the environment variables.
  // process.env.secretName

  //sendResponse is what you will send back to services hitting your serverless function.
  sendResponse({ body: { message: 'my response' }, statusCode: 200 });
};

Objet contextuel

L’objet contextuel contient des informations contextuelles sur l’exécution de la fonction, stockées dans les paramètres suivants.
ParamètreDescription
accountIdL’ID du compte HubSpot contenant la fonction.
bodyRenseigné si la requête est envoyée en tant que POST avec un type de contenu application/json.
contactSi la requête provient d’un contact intégré dans des cookies, l’objet de contact sera renseigné avec un ensemble de propriétés de contact de base ainsi que les informations suivantes :
  • vid : l’ID visiteur du contact.
  • isLoggedIn : lorsque vous utilisez le contrôle d’accès au CMS, la valeur sera définie sur true si le contact est connecté au domaine.
  • listMemberships : un tableau d’ID de listes de contacts dont ce contact est membre.
headersContient les en-têtes envoyés par le client qui atteint votre point de terminaison.
paramsRenseigné avec les valeurs de la chaîne de requête ainsi que les valeurs HTML Form-POST. Celles-ci sont structurées comme une carte avec des chaînes de caractères comme clés et un tableau de chaînes de caractères pour chaque valeur.context.params.yourvalue
limitsRenvoie le degré de rapprochement quant aux limites associées aux fonctions sans serveur.
  • executionsRemaining : le nombre d’exécutions par minute restantes.
  • timeRemaining : le temps d’exécution autorisé restant.

En-têtes

Si vous avez besoin de connaître les en-têtes du client qui atteint votre point de terminaison, vous pouvez y accéder via context.headers, de la même manière que vous accéderiez aux informations via context.body. Vous trouverez ci-dessous certains des en-têtes courants fournis par HubSpot. Pour obtenir la liste complète, consultez la documentation des en-têtes HTTP de MDN.
en-têteDescription
acceptIndique quels types de contenu, exprimés en types MIME, le client comprend. Voir MDN.
accept-encodingCommunique le codage du contenu que le client comprend. Voir MDN.
accept-languageIndique la langue et les paramètres régionaux préférés. Voir MDN.
cache-controlContient des directives pour la mise en cache. Voir MDN.
connectionIndique si la connexion réseau reste ouverte. Voir MDN.
cookieContient les cookies envoyés par le client. Voir MDN.
hostCommunique le nom de domaine et le numéro de port TCP d’un serveur en écoute. Voir MDN.
true-client-ipAdresse IP de l’utilisateur final. Consultez Cloudflare true-client-ip.
upgrade-insecure-requestsCommunique la préférence du client pour une réponse chiffrée et authentifiée. Voir MDN.
user-agentChaîne définie par le fournisseur identifiant l’application, le système d’exploitation, le fournisseur de l’application et la version. Voir MDN.
x-forwarded-forIdentifie l’adresse IP d’origine d’un client via un proxy ou un équilibreur de charge. Voir MDN.

Rediriger en envoyant un en-tête

Vous pouvez effectuer une redirection depuis votre fonction sans serveur en envoyant une réponse avec un en-tête de localisation et un statusCode 301.
sendResponse({
  statusCode: 301,
  headers: {
    Location: 'https://www.example.com',
  },
});

Définir des cookies à partir de votre point de terminaison

Depuis votre fonction sans serveur, vous pouvez indiquer au client (navigateur web) de définir un cookie.
exports.main = (context, sendResponse) => {
    sendResponse({
      body: { ... },
      'Set-Cookie': 'myCookie1=12345; expires=...; Max-Age=...',
      statusCode: 200
    });
  }

Définir plusieurs valeurs pour un seul en-tête

Pour les en-têtes qui prennent en charge plusieurs valeurs, vous pouvez utiliser multiValueHeaders pour transmettre les valeurs. Par exemple, vous pouvez demander au navigateur d’installer plusieurs cookies.
exports.main = (context, sendResponse) => {
  sendResponse({
    body: { ... },
    multiValueHeaders: {
      'Set-Cookie': [
        'myCookie1=12345; expires=...; Max-Age=...',
        'myCookie2=56789; expires=...; Max-Age=...'
       ]
    },
    statusCode: 200
  });
}

Secrets

Lorsque vous devez authentifier une requête de fonction sans serveur, vous utiliserez des secrets pour stocker des valeurs telles que des clés d’API ou des jetons d’accès à des applications privées. À l’aide de l’ILC, vous pouvez ajouter des secrets à votre compte HubSpot pour stocker ces valeurs, auxquelles vous pourrez accéder ultérieurement via des variables d’environnement (process.env.secretName). Les secrets sont gérés via l’ILC de HubSpot à l’aide des commandes suivantes : Une fois ajoutés par le biais de l’ILC, les secrets peuvent être disponibles pour des fonctions en incluant un tableau de secrets contenant le nom du secret. Cela vous permet de stocker votre code de fonction dans le système de contrôle de version et d’utiliser des secrets sans les diffuser. Cependant, vous ne devez jamais renvoyer la valeur de votre secret par le biais du journal de la console ou comme réponse, sous peine de diffuser le secret dans les journaux ou dans les interfaces qui exécutent votre fonction sans serveur.

Remarque :

En raison de la mise en cache, il peut s’écouler environ une minute pour que les valeurs secrètes se mettent à jour. Si vous venez de mettre à jour un secret mais que vous voyez toujours l’ancienne valeur, vérifiez à nouveau au bout d’une minute environ.

Utilisation de fonctions sans serveur avec l’élément de formulaire

Lors de la soumission des fonctions sans serveur, utilisez JavaScript pour gérer la soumission du formulaire et utilisez l’en-tête "contentType" : "application/json" dans votre requête. N’utilisez pas l’attribut action des éléments <form>.

CORS

Le partage des ressources entre origines multiples (CORS) est une fonction de sécurité du navigateur. Par défaut, les navigateurs limitent les requêtes d’origines multiples initiées par JavaScript. Cela permet d’éviter qu’un code malveillant exécuté sur un autre domaine n’affecte votre site. Il s’agit de la règle d’origine unique. Comme l’envoi et la récupération de données à partir d’autres serveurs sont parfois nécessaires, le serveur externe peut fournir des en-têtes HTTP qui indiquent les origines autorisées à lire les informations dans un navigateur. Vous ne devriez pas rencontrer de problèmes CORS en appelant votre fonction sans serveur dans vos pages hébergées par HubSpot. Si c’est le cas, vérifiez que vous utilisez le bon protocole.
Vous rencontrez cette erreur CORS ? « Access to fetch at [your function url] from origin [page making request] has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled. »Votre requête a-t-elle une origine différente de celle du site qui l’appelle ?
  • Si le nom de domaine est différent, oui.
  • Si vous utilisez un protocole différent (http, https), oui.
Si vous utilisez un protocole différent, il suffit de modifier le protocole en conséquence et le problème sera résolu.Pour l’instant, vous ne pouvez pas modifier l’en-tête Access-Control-Allow-Origin de HubSpot.Voir MDN pour obtenir des informations plus détaillées sur la résolution des erreurs CORS.

Requêtes GET

Les requêtes GET peuvent effectuer des requêtes CORS selon le client. Les requêtes GET n’écrivent rien, elles ne font que renvoyer des données.

Packs préchargés

Les fonctions sans serveur de HubSpot sont actuellement préchargées avec les packs suivants : Pour utiliser la dernière version prise en charge d’un pack préchargé ou pour utiliser un pack nouvellement ajouté :
  1. Clonez ou copiez votre fichier de fonction.
  2. Modifiez le point de terminaison de votre fonction dans le fichier serverless.json pour qu’il pointe vers votre nouveau fichier de fonction. Vous pouvez supprimer l’ancienne version en toute sécurité.
Si vous souhaitez inclure des packs en dehors de l’ensemble de packs préchargés, vous pouvez utiliser webpack pour combiner vos modules de nœud et faire en sorte que vos fichiers groupés soient vos fichiers de fonction.

Limites d’utilisation

Les fonctions sans serveur sont destinées à être rapides avec un objectif restreint. Pour permettre des appels et des réponses rapides, les fonctions sans serveur de HubSpot sont soumises aux limites suivantes :
  • 50 secrets par compte
  • 128 Mo de mémoire.
  • Pas plus de 100 points de terminaison par compte HubSpot.
  • contentType application/json Doit être utilisé lors de l’appel d’une fonction.
  • Les journaux des fonctions sans serveur sont conservés pendant 90 jours.
  • 6 Mo sur une charge utile d’invocation AWS Lambda.
Limites d’exécution
  • Chaque fonction a un temps d’exécution maximum de 10 secondes.
  • Chaque compte est limité à 600 secondes d’exécution totale par minute.
Cela signifie que l’une ou l’autre de ces situations peut se produire :
  • 60 exécutions de fonctions qui prennent chacune 10 secondes.
  • 6 000 exécutions de fonctions qui prennent 100 millisecondes.
Les fonctions qui dépassent ces limites de temps envoient un message d’erreur. Le nombre d’exécutions et les limites de temps renverront une réponse 429. Le temps d’exécution de chaque fonction est inclus dans les journaux des fonctions sans serveur. Pour éviter d’atteindre ces limites, les données relatives aux limites sont fournies automatiquement selon le contexte de la fonction pendant l’exécution. Vous pouvez vous en servir pour influencer votre demande afin de respecter ces limites. Par exemple, si votre application exige que votre point de terminaison soit interrogé, vous pouvez renvoyer avec vos données une variable pour influencer la fréquence de l’interrogation. Ainsi, lorsque le trafic est élevé, vous pouvez ralentir le taux d’interrogation pour éviter de dépasser les limites, puis le réaugmenter lorsque le trafic est faible.