Connecter Super PDP

Super PDP est une Plateforme Agréée française orientée API-first, immatriculée auprès de la DGFiP sous le n°0040. Authentification par OAuth 2.0 client_credentials, hébergement France.

1. Créer votre compte Super PDP

1. Rendez-vous sur superpdp.tech/app/users/create et créez votre compte.
2. Validez votre email puis renseignez votre SIRET pour l'onboarding entreprise.
3. Dans le tableau de bord, ouvrez API > Credentials et générez une paire client_id / client_secret.

2. Enregistrer les identifiants dans Facturino

La connexion d'une PA se gère depuis l'interface Facturino — les identifiants sensibles ne transitent jamais par l'API publique.

1. Connectez-vous à Facturino, puis ouvrez Paramètres → Facturation électronique.
2. Sélectionnez Super PDP dans la liste des PA disponibles.
3. Renseignez client_id et client_secret, puis cliquez sur Connecter.

Les identifiants sont chiffrés au repos avec AES-256-GCM avant écriture. Facturino ne renvoie jamais le client_secret en clair après enregistrement.

3. Tester la connexion

Depuis le même écran Paramètres → Facturation électronique, cliquez sur Tester la connexion. Facturino interroge Super PDP via le flux OAuth 2.0 et affiche le statut connecté ainsi que la date de dernière vérification. En cas d'échec, le message précise la cause (pa_credentials_invalid, pa_unreachable…).

4. Configurer le webhook entrant

Au moment de la connexion, Facturino génère un secret HMAC unique par entreprise et l'affiche une seule fois. Copiez-le sans tarder puis, dans Super PDP, ouvrez API → Webhooks et créez un endpoint :

• URL : https://facturino.com/api/v1/webhooks/pa-flow/{companyId}
• Signing secret : le secret affiché par Facturino
• Algorithme : HMAC-SHA256, encodage hexadécimal

5. Émettre votre première facture

Créez une facture, finalisez-la puis envoyez-la à la PA :

curl -X POST https://facturino.com/api/v1/invoices/inv_xxx/send \
  -H "Authorization: Bearer fac_test_..."

Suivez le cycle de vie via le webhook ou par polling sur GET /v1/invoices/{id}. Les statuts deposited → transmitted → available sont relevés auprès de Super PDP une minute après l'envoi, puis toutes les quinze minutes ; sending reste affiché tant que la plateforme n'a pas confirmé le dépôt.

Contrôler puis reprendre une déclaration refusée

Pour les ventes agrégées aux particuliers (flux 10.3), le connecteur envoie un multipart avec flowInfo en JSON et file en XML FRR, vers /afnor-flow/v1/flows. La syntaxe est FRR, le profil CIUS, la règle de traitement B2C. Une décade du 1er au 10 septembre 2026 porte les dates XML 20260901 et 20260910, jamais le libellé 2026-09-D1. Les dates exactes sont requises lorsqu’une période est une décade.

Le contrat AFNOR 1.3.0 publié par Super PDP admet ces valeurs de syntaxe, profil et traitement. Il nomme le flux 10.3 AggregatedCustomerTransactionReport dans les métadonnées retournées ; flowType, également envoyé aujourd’hui, n’est pas déclaré dans le schéma d’entrée FlowInfo. Ce schéma n’interdit pas les propriétés supplémentaires : son acceptation effective et le profil attendu pour ce compte doivent être confirmés par la réponse de la plateforme, sans les déduire d’un simple HTTP 400.

Les montants XML ont au plus deux décimales et 19 positions au total, signe éventuel compris et point décimal exclu (DGFiP, annexe 7, G1.14). Le générateur vérifie les lignes et les totaux avant émission. Les schémas XSD seuls ne vérifient pas toutes ces règles métier.

1. Relire GET /v1/ereporting/declarations/{id} : vérifier l’état, la période, les lignes et paRejectionReason. Un résultat encore à rapprocher impose de rechercher le dépôt existant avant toute nouvelle tentative.
2. Pour une déclaration définitivement rejetée, appeler POST /v1/ereporting/declarations/{id}/retry sans modifier les faits d’origine. La réponse donne l’identifiant de la nouvelle tentative ; l’ancienne déclaration et son refus sont conservés.
3. Soumettre cette nouvelle tentative par POST /v1/ereporting/declarations/{nouvelId}/submit, puis la relire. Conserver la réponse, le request_id, les identifiants de tentative et le motif. Si les faits sont erronés, corriger les documents sources selon le parcours de régularisation ; le rejeu ne corrige pas leur contenu.

Un ancien motif perdu ne peut pas être reconstruit à partir de « Unknown error ». La lecture du flux existant peut fournir un motif ; à défaut, seule une nouvelle réponse le permettra. La conservation de ces réponses métier n’autorise pas à publier des jetons ou des données personnelles dans les journaux.

Sources contrôlées le 11/09/2026 : contrat AFNOR Flow 1.3.0 de Super PDP et spécifications externes DGFiP 3.2, annexes 6 et 7 du 30/04/2026. Cette vérification documentaire et les tests locaux ne constituent pas une preuve d’acceptation par la plateforme.

Ressources

• superpdp.tech — site officiel Super PDP
• superpdp.tech/documentation — documentation développeur Super PDP
• Créer un compte développeur
• Webhooks Facturino — signature HMAC, retries, idempotence
• Codes d'erreur PA — pa_credentials_invalid, pa_unreachable…