Skip to content

Dernière mise à jour : 2026-10-04

Payload CMS et webhooks ​

auto-post.io publie les articles générés vers un projet Payload CMS via son API REST. Les webhooks natifs entrants du produit servent à la facturation (Stripe). Les webhooks de contenu personnalisés ne sont pas un type de destination actif dans le catalogue de l’app ; l’exemple ci-dessous concerne uniquement un pipeline externe.

Intégration Payload CMS ​

Ce qu’il vous faut ​

Avant de connecter Payload CMS, préparez :

  • Une URL de base publique de l’API REST Payload
  • Un compte utilisateur Payload pouvant accéder aux collections configurées
  • Le slug de la collection d’authentification, en général users
  • Le slug de la collection posts
  • Des slugs optionnels pour catégories et médias

Connecter Payload CMS ​

  1. Ouvrez Sites web, puis choisissez Ajouter un site.
  2. Sélectionnez Payload CMS comme plateforme.
  3. Saisissez le nom du site et l’URL publique.
  4. Saisissez l’URL de l’API Payload, l’e-mail, le mot de passe, le slug d’authentification et le slug des posts.
  5. Ajoutez les slugs catégories et médias si votre projet les utilise.
  6. Sélectionnez Continuer. auto-post.io se connecte, lit un article exemple et suggère un mapping de champs.
  7. Relisez le mapping suggéré et validez la connexion.

La connexion stocke les identifiants nécessaires pour obtenir un JWT Payload. Les jetons sont rafraîchis ou recréés lorsque les requêtes suivantes l’exigent.

Mapping des champs ​

Le mapping relie les champs auto-post.io aux champs de votre collection posts Payload :

  • Titre
  • Slug
  • Contenu
  • Date de publication
  • Catégories
  • Image à la une
  • Image Open Graph
  • Titre, description et mots-clés SEO
  • URL publique de l’article

Les champs imbriqués sont pris en charge avec des chemins en points tels que seo.title. Utilisez la suggestion IA comme point de départ, puis vérifiez chaque champ avant d’enregistrer.

Le rich text Payload est envoyé en JSON Lexical par défaut. Choisissez le format HTML uniquement si votre collection attend du HTML.

Collections et endpoints Payload ​

L’exemple suivant montre la forme minimale de collection attendue. Les noms de champs peuvent différer selon le mapping configuré dans auto-post.io.

js
// payload/collections/Posts.js
import { lexicalEditor } from '@payloadcms/richtext-lexical';

export const Posts = {
  slug: 'posts',
  access: {
    create: ({ req }) => Boolean(req.user),
    read: () => true,
    update: ({ req }) => Boolean(req.user),
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'content', type: 'richText', editor: lexicalEditor() },
    { name: 'publishedAt', type: 'date' },
    { name: 'categories', type: 'relationship', relationTo: 'categories', hasMany: true },
    { name: 'featuredImage', type: 'upload', relationTo: 'media' },
  ],
};

auto-post.io utilise ces endpoints REST Payload. Remplacez https://cms.example.com/api et les slugs par vos valeurs :

bash
# Connexion et JWT
curl -X POST "https://cms.example.com/api/users/login" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","password":"YOUR_PASSWORD"}'

# Créer un post
curl -X POST "https://cms.example.com/api/posts" \
  -H "Authorization: JWT YOUR_JWT" \
  -H "Content-Type: application/json" \
  -d '{"title":"A generated article","slug":"a-generated-article","content":{"root":{"type":"root","children":[],"direction":null,"format":"","indent":0,"version":1}},"_status":"draft"}'

# Mettre à jour un post existant
curl -X PATCH "https://cms.example.com/api/posts/123" \
  -H "Authorization: JWT YOUR_JWT" \
  -H "Content-Type: application/json" \
  -d '{"title":"An updated article","_status":"published"}'

Pour les images à la une, configurez une collection média et assurez-vous que le champ d’upload accepte le nom multipart configuré dans auto-post.io (file par défaut) :

bash
curl -X POST "https://cms.example.com/api/media" \
  -H "Authorization: JWT YOUR_JWT" \
  -F "[email protected]"

Comportement de publication ​

Lorsqu’une campagne génère un article pour un site Payload :

  • Le brouillon est envoyé avec _status à draft
  • Le contenu publié est envoyé avec _status à published
  • Les documents Payload existants sont mis à jour au lieu d’être dupliqués lorsque l’ID est connu
  • Les catégories sont synchronisées depuis la collection catégories configurée
  • Les images à la une sont téléversées vers la collection média lorsque le champ est mappé
  • L’URL publique de l’article vient du champ URL configuré, d’une URL renvoyée, ou du modèle de chemin configuré

Voir Gestion des campagnes pour configurer les campagnes qui publient vers Payload CMS.

Webhooks (facturation et exemples externes) ​

Webhook natif actif : Stripe ​

L’endpoint webhook produit utilisé en production est la facturation Stripe sur /webhook/stripe. Il gère les événements d’abonnement et de paiement de votre compte auto-post.io. Vous ne le configurez pas pour la publication de contenu.

Webhooks de contenu personnalisés (exemple externe uniquement) ​

Il n’existe pas de catalogue actif dans l’app ni de route personnalisée pour envoyer les articles générés vers des URL webhook arbitraires. Si vous avez besoin d’une étape de livraison personnalisée, construisez-la en dehors d’auto-post.io (par exemple en lisant le contenu publié depuis Payload, WordPress ou un autre CMS connecté).

La forme JSON ci-dessous est un exemple de contrat que vous pouvez implémenter sur votre propre serveur. Ce n’est pas un payload sortant garanti d’auto-post.io aujourd’hui.

json
{
  "event": "article.published",
  "idempotencyKey": "article-123-published",
  "article": {
    "title": "A generated article",
    "slug": "a-generated-article",
    "content": "<p>Article content</p>",
    "status": "published",
    "publishedAt": "2026-09-10T19:20:00Z",
    "featuredImage": "https://cdn.example.com/articles/a-generated-article.jpg"
  }
}

Si vous adoptez un contrat similaire de votre côté :

  • Authentifiez et validez chaque requête
  • Rejetez les payloads invalides avec 4xx
  • Rendez idempotencyKey unique avant d’écrire le contenu
  • Renvoyez 2xx seulement après acceptation de la requête

Dépannage ​

La connexion échoue ​

  • Confirmez que l’URL API pointe vers l’API REST Payload, pas seulement le frontend public
  • Vérifiez le slug d’authentification et les identifiants
  • Confirmez que la collection posts existe et est lisible par l’utilisateur
  • Vérifiez que l’API est joignable depuis Internet

Les articles sont rejetés ​

  • Vérifiez que les noms de champs mappés correspondent à la collection Payload
  • Confirmez le type du champ contenu et le format rich text choisi
  • Vérifiez les champs requis, formats de relations et permissions média
  • Relisez les règles d’accès create/update de la collection

Images manquantes ​

  • Configurez un slug de collection média
  • Vérifiez le champ image à la une ou Open Graph mappé
  • Confirmez que la collection média accepte le champ d’upload configuré

Documentation associée ​

Dernière mise à jour : 2026-10-04