AFNOR API Integration

The AFNOR API, formally the French standard XP Z12-013, is one common interface that every Plateforme Agréée (PA, formerly PDP) can offer. Software that implements it once can connect to any platform offering it, without further development. That is what this channel is for: rather than supporting each platform’s own API one at a time, the module speaks the standard and you point it at a platform that implements it.

The module ships one AFNOR entry, SUPER PDP (AFNOR API). Other platforms are added as they are verified. If you are interested in a specific platform, reach out to contact@nomu.agency.

Everything below applies to the module from version 1.11.0, and to the French regulation. See France Regulations for who has to send e-invoices and from when.

Which of the two providers to pick

The module lists SUPER PDP twice, once for its own JSON API and once for the AFNOR API. Both reach the same platform and the same account, and the platform shares the same data between them, so nothing is lost by starting with one and moving to the other.

SUPER PDPSUPER PDP (AFNOR API)
InterfaceThe platform’s own JSON APIThe XP Z12-013 standard
Works with another platformNoYes, once that platform is added to the module
The connection test reportsThe company and the environment your credentials belong toOnly that the credentials were accepted
The customer’s addressChecked before the invoice is acceptedChecked by the platform after acceptance

Pick the AFNOR provider when you want the standard rather than one vendor’s interface. Pick SUPER PDP when that platform is the only one you use and you want the extra feedback.

What you need

RequirementNotes
The module installed and workingYou can already download an e-invoice from an order
An account with a platform that offers the AFNOR APISUPER PDP is the one in the module’s list today
A client ID and client secret from that platformIssued by the platform, not by the standard
The PHP curl extensionThe connection test reports it if missing
Outbound HTTPS to api.superpdp.techAsk your host whether outgoing connections are filtered
Your company’s SIRENEntered on the module’s Seller settings card
Your customers’ SIRENOnly invoices addressed to an identified business are sent

The standard covers sending invoices, not signing up. Every platform runs its own account creation, its own identity checks and its own credentials. The setup below is therefore SUPER PDP’s procedure. Another platform has its own, and only the module fields stay the same.

Create an account and get credentials

The AFNOR API of SUPER PDP uses the same account and the same kind of OAuth application as the platform’s own API, so the setup does not change:

  1. Create the account at superpdp.tech, through Connexion then Créer un compte. Two fictitious sandbox companies, Burger Queen and Tricatel, are created with it.
  2. Go to Applications, click Nouvelle application, pick the company, then click Créer.
  3. Copy the client_id and the client_secret at once. The secret is shown one time.

SUPER PDP Integration describes both steps in full, including what to do when you move from the sandbox to production.

The module authenticates with OAuth 2.1 client credentials, the grant the standard describes for software reaching its own account. Sandbox and production are told apart by the credentials you use, not by a setting.

Enter the credentials in PrestaShop

Go to Modules → Module Manager → Prestashop E-invoicing 2026 → Configure, and scroll to the PDP settings card.

FieldWhat to enter
Send to PDPTurn on. Nothing is sent while this is off
PDP ProviderSUPER PDP (AFNOR API)
PDP Client IDThe client_id from the previous step
PDP Client SecretThe client_secret from the previous step

Click Save.

The secret is stored encrypted and is never sent back to your browser, so the field looks empty after saving. Leaving it empty keeps the stored secret. Type a value only when you want to replace it.

There is no field for the platform’s address. The base URL of every supported platform is built into the module, because your credentials and every invoice you issue travel to that address. It is not something a back office field should be able to redirect.

Test the connection

On the PDP settings card, click Test PDP Connection. The test uses the values shown in the form, so you can try credentials before saving them. An empty secret field falls back to the stored secret.

The test does two things: it exchanges your credentials for a token, and it calls the platform’s health check. On success you get a green alert, Connected to SUPER PDP (AFNOR API). Credentials accepted. On failure you get a red alert with the reason.

Note what success does not tell you. The standard has no operation that describes the account behind the credentials, so the module cannot name your company or say whether you are on the sandbox or in production. Keep track of which application’s credentials you pasted.

MessageMeaning
A client ID and a client secret are required.One of the two fields is empty
HTTP 401: Client authentication failed (...)Wrong client ID or secret, or the application was deleted
HTTP 503 or HTTP 500The credentials were accepted but the service is not answering. Check status.superpdp.tech
The platform could not be reached.No outbound connection to the platform
The PHP curl extension is not installed or enabled.Ask your host to enable curl

Send a test invoice from the sandbox

The walk-through is the same as for the platform’s own API: an invoice from Burger Queen, your shop, to Tricatel, your customer.

  1. Configure the module with the Burger Queen application credentials, and set the seller SIREN to Burger Queen’s number.
  2. On a test customer’s invoice address, fill the SIREN and Suffix fields with Tricatel’s sandbox e-invoicing address. Sandbox addresses have the technical form 315143296_XXX, so 315143296 goes in the SIREN field and the XXX part in the suffix. In production the address is normally the customer’s plain SIREN.
  3. Place an order for that customer and generate its invoice, by moving the order to a status that creates one, for example Payment accepted.
  4. The invoice is submitted at that moment, and the order gets a stored result.
  5. Confirm it in your platform account.

That last step matters more on this channel than on the other one. The platform answers that the submission has been accepted for processing, and acceptance is not validation: the checks against the official rules, the directory lookup and the delivery to your customer all happen afterwards. An invoice the module records as sent can still be refused a moment later, and only your platform account shows it.

Retrying a failed invoice

There is no automatic retry. When sending is enabled, every row in Orders carries a Send to PDP action that resubmits all invoices of that order and replaces the previous result. The loop is:

  1. Read the failure reason, from the flash message or from Advanced Parameters → Logs, searching for ExportPeppol.
  2. Correct the cause, usually the SIREN or the suffix on the customer’s invoice address.
  3. Click Send to PDP on the order.

An invoice refused after acceptance still counts as sent in PrestaShop, so for that case the resend starts from what you see in the platform account.