factpulse 3.0.10 → 3.0.13

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (476) hide show
  1. checksums.yaml +4 -4
  2. data/CHANGELOG.md +3 -3
  3. data/Gemfile.lock +3 -3
  4. data/LICENSE +1 -1
  5. data/docs/AFNORAcknowledgement.md +20 -0
  6. data/docs/AFNORAcknowledgementDetail.md +24 -0
  7. data/docs/AFNORAddressEdit.md +30 -0
  8. data/docs/AFNORAddressPatch.md +30 -0
  9. data/docs/AFNORAddressPut.md +30 -0
  10. data/docs/AFNORAddressRead.md +32 -0
  11. data/docs/{ValidationErrorLocInner.md → AFNORAlgorithm.md} +2 -2
  12. data/docs/AFNORContainsOperator.md +15 -0
  13. data/docs/AFNORCreateDirectoryLineBody.md +20 -0
  14. data/docs/AFNORCreateDirectoryLineBodyAddressingInformation.md +24 -0
  15. data/docs/AFNORCreateDirectoryLineBodyPeriod.md +20 -0
  16. data/docs/AFNORCreateRoutingCodeBody.md +32 -0
  17. data/docs/AFNORDestination.md +4 -2
  18. data/docs/AFNORDiffusionStatus.md +15 -0
  19. data/docs/AFNORDirectoryLineField.md +15 -0
  20. data/docs/AFNORDirectoryLinePayloadHistoryLegalUnitFacilityRoutingCode.md +32 -0
  21. data/docs/AFNORDirectoryLinePayloadHistoryLegalUnitFacilityRoutingCodePlatform.md +20 -0
  22. data/docs/AFNORDirectoryLinePayloadHistoryLegalUnitFacilityRoutingCodeRoutingCode.md +28 -0
  23. data/docs/AFNORDirectoryLinePost201Response.md +22 -0
  24. data/docs/AFNORDirectoryLineSearchPost200Response.md +22 -0
  25. data/docs/AFNOREntityType.md +15 -0
  26. data/docs/AFNORError.md +26 -0
  27. data/docs/AFNORFacilityAdministrativeStatus.md +15 -0
  28. data/docs/AFNORFacilityNature.md +15 -0
  29. data/docs/AFNORFacilityPayloadHistory.md +34 -0
  30. data/docs/AFNORFacilityPayloadHistoryUleB2gAdditionalData.md +28 -0
  31. data/docs/AFNORFacilityPayloadIncluded.md +32 -0
  32. data/docs/AFNORFacilityType.md +15 -0
  33. data/docs/AFNORFlow.md +38 -0
  34. data/docs/AFNORFlowAckStatus.md +15 -0
  35. data/docs/AFNORFlowDirection.md +15 -0
  36. data/docs/AFNORFlowInfo.md +28 -0
  37. data/docs/AFNORFlowProfile.md +15 -0
  38. data/docs/AFNORFlowSyntax.md +15 -0
  39. data/docs/AFNORFlowType.md +15 -0
  40. data/docs/AFNORFullFlowInfo.md +32 -0
  41. data/docs/AFNORLegalUnitAdministrativeStatus.md +15 -0
  42. data/docs/AFNORLegalUnitPayloadHistory.md +24 -0
  43. data/docs/AFNORLegalUnitPayloadIncluded.md +24 -0
  44. data/docs/AFNORLegalUnitPayloadIncludedNoSiren.md +22 -0
  45. data/docs/AFNORPDPPAApi.md +5 -5
  46. data/docs/AFNORPDPPADirectoryServiceApi.md +278 -178
  47. data/docs/AFNORPDPPAFlowServiceApi.md +39 -27
  48. data/docs/AFNORPlatformStatus.md +15 -0
  49. data/docs/AFNORProcessingRule.md +15 -0
  50. data/docs/AFNORReasonCode.md +49 -0
  51. data/docs/AFNORReasonCodeEnum.md +15 -0
  52. data/docs/AFNORRecipientPlatformType.md +15 -0
  53. data/docs/AFNORResult.md +7 -1
  54. data/docs/AFNORRoutingCodeAdministrativeStatus.md +15 -0
  55. data/docs/AFNORRoutingCodeField.md +15 -0
  56. data/docs/AFNORRoutingCodePayloadHistoryLegalUnitFacility.md +34 -0
  57. data/docs/AFNORRoutingCodePost201Response.md +22 -0
  58. data/docs/AFNORRoutingCodeSearch.md +28 -0
  59. data/docs/AFNORRoutingCodeSearchFilters.md +30 -0
  60. data/docs/AFNORRoutingCodeSearchFiltersAdministrativeStatus.md +20 -0
  61. data/docs/AFNORRoutingCodeSearchFiltersRoutingCodeName.md +20 -0
  62. data/docs/AFNORRoutingCodeSearchFiltersRoutingIdentifier.md +20 -0
  63. data/docs/AFNORRoutingCodeSearchPost200Response.md +22 -0
  64. data/docs/AFNORRoutingCodeSearchSortingInner.md +20 -0
  65. data/docs/AFNORSearchDirectoryLine.md +26 -0
  66. data/docs/AFNORSearchDirectoryLineFilters.md +26 -0
  67. data/docs/AFNORSearchDirectoryLineFiltersAddressingIdentifier.md +20 -0
  68. data/docs/AFNORSearchDirectoryLineFiltersAddressingSuffix.md +20 -0
  69. data/docs/AFNORSearchDirectoryLineSortingInner.md +20 -0
  70. data/docs/AFNORSearchFlowContent.md +22 -0
  71. data/docs/AFNORSearchFlowFilters.md +30 -0
  72. data/docs/AFNORSearchFlowParams.md +20 -0
  73. data/docs/AFNORSearchSiren.md +26 -0
  74. data/docs/AFNORSearchSirenFilters.md +24 -0
  75. data/docs/AFNORSearchSirenFiltersAdministrativeStatus.md +20 -0
  76. data/docs/AFNORSearchSirenFiltersBusinessName.md +20 -0
  77. data/docs/AFNORSearchSirenFiltersEntityType.md +20 -0
  78. data/docs/AFNORSearchSirenFiltersSiren.md +20 -0
  79. data/docs/AFNORSearchSirenSortingInner.md +20 -0
  80. data/docs/AFNORSearchSiret.md +28 -0
  81. data/docs/AFNORSearchSiretFilters.md +34 -0
  82. data/docs/AFNORSearchSiretFiltersAddressLines.md +20 -0
  83. data/docs/AFNORSearchSiretFiltersAdministrativeStatus.md +20 -0
  84. data/docs/AFNORSearchSiretFiltersCountrySubdivision.md +20 -0
  85. data/docs/AFNORSearchSiretFiltersFacilityType.md +20 -0
  86. data/docs/AFNORSearchSiretFiltersLocality.md +20 -0
  87. data/docs/AFNORSearchSiretFiltersName.md +20 -0
  88. data/docs/AFNORSearchSiretFiltersPostalCode.md +20 -0
  89. data/docs/AFNORSearchSiretFiltersSiret.md +20 -0
  90. data/docs/AFNORSearchSiretSortingInner.md +20 -0
  91. data/docs/AFNORSirenField.md +15 -0
  92. data/docs/AFNORSirenSearchPost200Response.md +22 -0
  93. data/docs/AFNORSiretField.md +15 -0
  94. data/docs/AFNORSiretSearchPost200Response.md +22 -0
  95. data/docs/AFNORSortingOrder.md +15 -0
  96. data/docs/AFNORStrictOperator.md +15 -0
  97. data/docs/AFNORUpdatePatchDirectoryLineBody.md +18 -0
  98. data/docs/AFNORUpdatePatchRoutingCodeBody.md +24 -0
  99. data/docs/AFNORUpdatePutRoutingCodeBody.md +24 -0
  100. data/docs/AFNORWebhookCallbackContent.md +18 -0
  101. data/docs/AcceptLanguage.md +15 -0
  102. data/docs/AggregatedPaymentInput.md +22 -0
  103. data/docs/AggregatedTransactionInput.md +32 -0
  104. data/docs/AllowanceCharge.md +3 -3
  105. data/docs/AllowanceChargeReasonCode.md +15 -0
  106. data/docs/Amount1.md +15 -0
  107. data/docs/Buyercountry.md +15 -0
  108. data/docs/ChorusProApi.md +5 -3
  109. data/docs/{FactureElectroniqueRestApiSchemasChorusProChorusProCredentials.md → ChorusProCredentials.md} +2 -2
  110. data/docs/ConvertValidationFailedResponse.md +5 -5
  111. data/docs/CountryCode.md +15 -0
  112. data/docs/CreateAggregatedReportRequest.md +34 -0
  113. data/docs/CreateEReportingRequest.md +36 -0
  114. data/docs/Currency.md +15 -0
  115. data/docs/CurrencyCode.md +15 -0
  116. data/docs/DirectoryLineInclude.md +15 -0
  117. data/docs/DocType.md +15 -0
  118. data/docs/DocumentConversionApi.md +12 -86
  119. data/docs/DownloadsApi.md +295 -0
  120. data/docs/EReportingApi.md +782 -0
  121. data/docs/EReportingFlowType.md +15 -0
  122. data/docs/ElectronicAddress.md +2 -2
  123. data/docs/EnrichedInvoiceInfo.md +6 -6
  124. data/docs/FactureElectroniqueModelsInvoiceTypeCode.md +15 -0
  125. data/docs/FactureElectroniqueRestApiSchemasConvertValidationError.md +32 -0
  126. data/docs/FlowSummary.md +2 -2
  127. data/docs/GenerateAggregatedReportResponse.md +30 -0
  128. data/docs/GenerateEReportingResponse.md +26 -0
  129. data/docs/GetChorusProIdRequest.md +1 -1
  130. data/docs/GetInvoiceRequest.md +1 -1
  131. data/docs/GetInvoiceResponse.md +2 -2
  132. data/docs/GetStructureRequest.md +1 -1
  133. data/docs/GetStructureResponse.md +2 -2
  134. data/docs/HealthApi.md +1 -1
  135. data/docs/IncomingInvoice.md +1 -1
  136. data/docs/InvoiceInput.md +48 -0
  137. data/docs/InvoiceLine.md +4 -0
  138. data/docs/InvoiceNote.md +1 -1
  139. data/docs/InvoicePaymentInput.md +26 -0
  140. data/docs/InvoiceProcessingApi.md +41 -17
  141. data/docs/InvoiceTypeCodeOutput.md +15 -0
  142. data/docs/InvoicingFramework.md +1 -1
  143. data/docs/LineSubType.md +15 -0
  144. data/docs/LocationInner.md +15 -0
  145. data/docs/PDFXMLVerificationApi.md +17 -9
  146. data/docs/PaymentAmountByRate.md +20 -0
  147. data/docs/ProcessingRule.md +15 -0
  148. data/docs/Rate.md +15 -0
  149. data/docs/Rate1.md +15 -0
  150. data/docs/ReportPeriod.md +20 -0
  151. data/docs/ReportSender.md +22 -0
  152. data/docs/RoutingCodeInclude.md +15 -0
  153. data/docs/SearchServicesResponse.md +3 -3
  154. data/docs/SearchStructureRequest.md +1 -1
  155. data/docs/Sellercountry.md +15 -0
  156. data/docs/SimplifiedInvoiceData.md +9 -1
  157. data/docs/SiretInclude.md +15 -0
  158. data/docs/SubmitAggregatedReportRequest.md +28 -0
  159. data/docs/SubmitEReportingRequest.md +28 -0
  160. data/docs/SubmitEReportingResponse.md +32 -0
  161. data/docs/SubmitInvoiceRequest.md +1 -1
  162. data/docs/SupplementaryAttachment.md +5 -5
  163. data/docs/TaxBreakdownInput.md +22 -0
  164. data/docs/TaxDueDateType.md +15 -0
  165. data/docs/Taxableamount.md +15 -0
  166. data/docs/Taxamount.md +15 -0
  167. data/docs/Taxamount1.md +15 -0
  168. data/docs/Taxamount2.md +15 -0
  169. data/docs/Taxexclusiveamount.md +15 -0
  170. data/docs/Taxexclusiveamount1.md +15 -0
  171. data/docs/TransactionCategory.md +15 -0
  172. data/docs/TransmissionTypeCode.md +15 -0
  173. data/docs/UserApi.md +1 -1
  174. data/docs/ValidateEReportingRequest.md +18 -0
  175. data/docs/ValidateEReportingResponse.md +28 -0
  176. data/docs/ValidationError.md +1 -1
  177. data/docs/ValidationInfo.md +1 -1
  178. data/factpulse.gemspec +4 -4
  179. data/lib/factpulse/api/afnorpdppa_api.rb +6 -6
  180. data/lib/factpulse/api/afnorpdppa_directory_service_api.rb +210 -123
  181. data/lib/factpulse/api/afnorpdppa_flow_service_api.rb +57 -24
  182. data/lib/factpulse/api/chorus_pro_api.rb +6 -4
  183. data/lib/factpulse/api/document_conversion_api.rb +13 -85
  184. data/lib/factpulse/api/downloads_api.rb +280 -0
  185. data/lib/factpulse/api/e_reporting_api.rb +774 -0
  186. data/lib/factpulse/api/health_api.rb +2 -2
  187. data/lib/factpulse/api/invoice_processing_api.rb +47 -14
  188. data/lib/factpulse/api/pdfxml_verification_api.rb +22 -10
  189. data/lib/factpulse/api/user_api.rb +2 -2
  190. data/lib/factpulse/api_client.rb +2 -2
  191. data/lib/factpulse/api_error.rb +2 -2
  192. data/lib/factpulse/api_model_base.rb +2 -2
  193. data/lib/factpulse/configuration.rb +10 -6
  194. data/lib/factpulse/models/accept_language.rb +40 -0
  195. data/lib/factpulse/models/acknowledgment_status.rb +2 -2
  196. data/lib/factpulse/models/additional_document.rb +2 -2
  197. data/lib/factpulse/models/afnor_acknowledgement.rb +216 -0
  198. data/lib/factpulse/models/afnor_acknowledgement_detail.rb +267 -0
  199. data/lib/factpulse/models/afnor_address_edit.rb +353 -0
  200. data/lib/factpulse/models/afnor_address_patch.rb +386 -0
  201. data/lib/factpulse/models/afnor_address_put.rb +435 -0
  202. data/lib/factpulse/models/afnor_address_read.rb +382 -0
  203. data/lib/factpulse/models/afnor_algorithm.rb +43 -0
  204. data/lib/factpulse/models/afnor_contains_operator.rb +39 -0
  205. data/lib/factpulse/models/afnor_create_directory_line_body.rb +156 -0
  206. data/lib/factpulse/models/afnor_create_directory_line_body_addressing_information.rb +294 -0
  207. data/lib/factpulse/models/afnor_create_directory_line_body_period.rb +175 -0
  208. data/lib/factpulse/models/afnor_create_routing_code_body.rb +412 -0
  209. data/lib/factpulse/models/afnor_credentials.rb +2 -2
  210. data/lib/factpulse/models/afnor_destination.rb +19 -23
  211. data/lib/factpulse/models/afnor_diffusion_status.rb +40 -0
  212. data/lib/factpulse/models/afnor_directory_line_field.rb +44 -0
  213. data/lib/factpulse/models/afnor_directory_line_payload_history_legal_unit_facility_routing_code.rb +312 -0
  214. data/lib/factpulse/models/afnor_directory_line_payload_history_legal_unit_facility_routing_code_platform.rb +178 -0
  215. data/lib/factpulse/models/afnor_directory_line_payload_history_legal_unit_facility_routing_code_routing_code.rb +308 -0
  216. data/lib/factpulse/models/afnor_directory_line_post201_response.rb +187 -0
  217. data/lib/factpulse/models/afnor_directory_line_search_post200_response.rb +168 -0
  218. data/lib/factpulse/models/afnor_entity_type.rb +40 -0
  219. data/lib/factpulse/models/{convert_error_response.rb → afnor_error.rb} +51 -61
  220. data/lib/factpulse/models/afnor_facility_administrative_status.rb +40 -0
  221. data/lib/factpulse/models/afnor_facility_nature.rb +40 -0
  222. data/lib/factpulse/models/afnor_facility_payload_history.rb +323 -0
  223. data/lib/factpulse/models/afnor_facility_payload_history_ule_b2g_additional_data.rb +198 -0
  224. data/lib/factpulse/models/afnor_facility_payload_included.rb +314 -0
  225. data/lib/factpulse/models/afnor_facility_type.rb +40 -0
  226. data/lib/factpulse/models/afnor_flow.rb +315 -0
  227. data/lib/factpulse/models/afnor_flow_ack_status.rb +41 -0
  228. data/lib/factpulse/models/afnor_flow_direction.rb +40 -0
  229. data/lib/factpulse/models/afnor_flow_info.rb +293 -0
  230. data/lib/factpulse/models/afnor_flow_profile.rb +41 -0
  231. data/lib/factpulse/models/afnor_flow_syntax.rb +43 -0
  232. data/lib/factpulse/models/afnor_flow_type.rb +51 -0
  233. data/lib/factpulse/models/afnor_full_flow_info.rb +339 -0
  234. data/lib/factpulse/models/afnor_health_check_response.rb +2 -2
  235. data/lib/factpulse/models/afnor_legal_unit_administrative_status.rb +40 -0
  236. data/lib/factpulse/models/afnor_legal_unit_payload_history.rb +247 -0
  237. data/lib/factpulse/models/afnor_legal_unit_payload_included.rb +247 -0
  238. data/lib/factpulse/models/afnor_legal_unit_payload_included_no_siren.rb +207 -0
  239. data/lib/factpulse/models/afnor_platform_status.rb +40 -0
  240. data/lib/factpulse/models/afnor_processing_rule.rb +44 -0
  241. data/lib/factpulse/models/afnor_reason_code.rb +105 -0
  242. data/lib/factpulse/models/afnor_reason_code_enum.rb +53 -0
  243. data/lib/factpulse/models/afnor_recipient_platform_type.rb +40 -0
  244. data/lib/factpulse/models/afnor_result.rb +37 -7
  245. data/lib/factpulse/models/afnor_routing_code_administrative_status.rb +40 -0
  246. data/lib/factpulse/models/afnor_routing_code_field.rb +46 -0
  247. data/lib/factpulse/models/afnor_routing_code_payload_history_legal_unit_facility.rb +366 -0
  248. data/lib/factpulse/models/afnor_routing_code_post201_response.rb +228 -0
  249. data/lib/factpulse/models/afnor_routing_code_search.rb +224 -0
  250. data/lib/factpulse/models/afnor_routing_code_search_filters.rb +201 -0
  251. data/lib/factpulse/models/afnor_routing_code_search_filters_administrative_status.rb +178 -0
  252. data/lib/factpulse/models/afnor_routing_code_search_filters_routing_code_name.rb +209 -0
  253. data/lib/factpulse/models/afnor_routing_code_search_filters_routing_identifier.rb +209 -0
  254. data/lib/factpulse/models/afnor_routing_code_search_post200_response.rb +168 -0
  255. data/lib/factpulse/models/afnor_routing_code_search_sorting_inner.rb +179 -0
  256. data/lib/factpulse/models/afnor_search_directory_line.rb +191 -0
  257. data/lib/factpulse/models/afnor_search_directory_line_filters.rb +183 -0
  258. data/lib/factpulse/models/afnor_search_directory_line_filters_addressing_identifier.rb +198 -0
  259. data/lib/factpulse/models/afnor_search_directory_line_filters_addressing_suffix.rb +198 -0
  260. data/lib/factpulse/models/afnor_search_directory_line_sorting_inner.rb +179 -0
  261. data/lib/factpulse/models/afnor_search_flow_content.rb +168 -0
  262. data/lib/factpulse/models/afnor_search_flow_filters.rb +250 -0
  263. data/lib/factpulse/models/afnor_search_flow_params.rb +195 -0
  264. data/lib/factpulse/models/afnor_search_siren.rb +191 -0
  265. data/lib/factpulse/models/afnor_search_siren_filters.rb +174 -0
  266. data/lib/factpulse/models/afnor_search_siren_filters_administrative_status.rb +178 -0
  267. data/lib/factpulse/models/afnor_search_siren_filters_business_name.rb +198 -0
  268. data/lib/factpulse/models/afnor_search_siren_filters_entity_type.rb +178 -0
  269. data/lib/factpulse/models/afnor_search_siren_filters_siren.rb +209 -0
  270. data/lib/factpulse/models/afnor_search_siren_sorting_inner.rb +179 -0
  271. data/lib/factpulse/models/afnor_search_siret.rb +224 -0
  272. data/lib/factpulse/models/afnor_search_siret_filters.rb +219 -0
  273. data/lib/factpulse/models/afnor_search_siret_filters_address_lines.rb +198 -0
  274. data/lib/factpulse/models/afnor_search_siret_filters_administrative_status.rb +178 -0
  275. data/lib/factpulse/models/afnor_search_siret_filters_country_subdivision.rb +198 -0
  276. data/lib/factpulse/models/afnor_search_siret_filters_facility_type.rb +178 -0
  277. data/lib/factpulse/models/afnor_search_siret_filters_locality.rb +198 -0
  278. data/lib/factpulse/models/afnor_search_siret_filters_name.rb +198 -0
  279. data/lib/factpulse/models/afnor_search_siret_filters_postal_code.rb +209 -0
  280. data/lib/factpulse/models/afnor_search_siret_filters_siret.rb +209 -0
  281. data/lib/factpulse/models/afnor_search_siret_sorting_inner.rb +179 -0
  282. data/lib/factpulse/models/afnor_siren_field.rb +43 -0
  283. data/lib/factpulse/models/afnor_siren_search_post200_response.rb +168 -0
  284. data/lib/factpulse/models/afnor_siret_field.rb +52 -0
  285. data/lib/factpulse/models/afnor_siret_search_post200_response.rb +168 -0
  286. data/lib/factpulse/models/afnor_sorting_order.rb +40 -0
  287. data/lib/factpulse/models/afnor_strict_operator.rb +39 -0
  288. data/lib/factpulse/models/afnor_update_patch_directory_line_body.rb +148 -0
  289. data/lib/factpulse/models/afnor_update_patch_routing_code_body.rb +258 -0
  290. data/lib/factpulse/models/afnor_update_put_routing_code_body.rb +289 -0
  291. data/lib/factpulse/models/afnor_webhook_callback_content.rb +148 -0
  292. data/lib/factpulse/models/aggregated_payment_input.rb +213 -0
  293. data/lib/factpulse/models/aggregated_transaction_input.rb +349 -0
  294. data/lib/factpulse/models/allowance_charge.rb +27 -5
  295. data/lib/factpulse/models/allowance_charge_reason_code.rb +76 -0
  296. data/lib/factpulse/models/allowance_reason_code.rb +2 -2
  297. data/lib/factpulse/models/allowance_total_amount.rb +2 -2
  298. data/lib/factpulse/models/amount.rb +3 -3
  299. data/lib/factpulse/models/amount1.rb +104 -0
  300. data/lib/factpulse/models/amount_due.rb +2 -2
  301. data/lib/factpulse/models/api_error.rb +2 -2
  302. data/lib/factpulse/models/api_profile.rb +4 -3
  303. data/lib/factpulse/models/async_task_status.rb +2 -2
  304. data/lib/factpulse/models/base_amount.rb +2 -2
  305. data/lib/factpulse/models/bounding_box_schema.rb +2 -2
  306. data/lib/factpulse/models/buyercountry.rb +104 -0
  307. data/lib/factpulse/models/celery_status.rb +2 -2
  308. data/lib/factpulse/models/certificate_info_response.rb +2 -2
  309. data/lib/factpulse/models/charge_total_amount.rb +2 -2
  310. data/lib/factpulse/models/{facture_electronique_rest_api_schemas_chorus_pro_chorus_pro_credentials.rb → chorus_pro_credentials.rb} +5 -5
  311. data/lib/factpulse/models/chorus_pro_destination.rb +2 -2
  312. data/lib/factpulse/models/chorus_pro_result.rb +2 -2
  313. data/lib/factpulse/models/contact.rb +2 -2
  314. data/lib/factpulse/models/convert_resume_request.rb +2 -2
  315. data/lib/factpulse/models/convert_success_response.rb +2 -2
  316. data/lib/factpulse/models/convert_validation_failed_response.rb +7 -2
  317. data/lib/factpulse/models/country_code.rb +208 -0
  318. data/lib/factpulse/models/create_aggregated_report_request.rb +310 -0
  319. data/lib/factpulse/models/create_e_reporting_request.rb +337 -0
  320. data/lib/factpulse/models/currency.rb +104 -0
  321. data/lib/factpulse/models/currency_code.rb +91 -0
  322. data/lib/factpulse/models/delivery_party.rb +2 -2
  323. data/lib/factpulse/models/destination.rb +2 -2
  324. data/lib/factpulse/models/directory_line_include.rb +42 -0
  325. data/lib/factpulse/models/doc_type.rb +42 -0
  326. data/lib/factpulse/models/document_type_info.rb +2 -2
  327. data/lib/factpulse/models/e_reporting_flow_type.rb +42 -0
  328. data/lib/factpulse/models/electronic_address.rb +4 -2
  329. data/lib/factpulse/models/enriched_invoice_info.rb +8 -2
  330. data/lib/factpulse/models/error_level.rb +2 -2
  331. data/lib/factpulse/models/error_source.rb +2 -2
  332. data/lib/factpulse/models/extraction_info.rb +2 -2
  333. data/lib/factpulse/models/factur_x_invoice.rb +2 -2
  334. data/lib/factpulse/models/factur_xpdf_info.rb +2 -2
  335. data/lib/factpulse/models/facture_electronique_models_invoice_type_code.rb +54 -0
  336. data/lib/factpulse/models/facture_electronique_rest_api_schemas_convert_validation_error.rb +294 -0
  337. data/lib/factpulse/models/facture_electronique_rest_api_schemas_processing_chorus_pro_credentials.rb +2 -2
  338. data/lib/factpulse/models/field_status.rb +2 -2
  339. data/lib/factpulse/models/file_info.rb +2 -2
  340. data/lib/factpulse/models/files_info.rb +2 -2
  341. data/lib/factpulse/models/flow_direction.rb +2 -2
  342. data/lib/factpulse/models/flow_profile.rb +2 -2
  343. data/lib/factpulse/models/flow_summary.rb +4 -2
  344. data/lib/factpulse/models/flow_syntax.rb +2 -2
  345. data/lib/factpulse/models/flow_type.rb +12 -4
  346. data/lib/factpulse/models/generate_aggregated_report_response.rb +330 -0
  347. data/lib/factpulse/models/generate_certificate_request.rb +2 -2
  348. data/lib/factpulse/models/generate_certificate_response.rb +2 -2
  349. data/lib/factpulse/models/generate_e_reporting_response.rb +274 -0
  350. data/lib/factpulse/models/get_chorus_pro_id_request.rb +3 -3
  351. data/lib/factpulse/models/get_chorus_pro_id_response.rb +2 -2
  352. data/lib/factpulse/models/get_invoice_request.rb +3 -3
  353. data/lib/factpulse/models/get_invoice_response.rb +4 -2
  354. data/lib/factpulse/models/get_structure_request.rb +3 -3
  355. data/lib/factpulse/models/get_structure_response.rb +4 -2
  356. data/lib/factpulse/models/global_allowance_amount.rb +2 -2
  357. data/lib/factpulse/models/gross_unit_price.rb +2 -2
  358. data/lib/factpulse/models/http_validation_error.rb +2 -2
  359. data/lib/factpulse/models/incoming_invoice.rb +3 -36
  360. data/lib/factpulse/models/incoming_supplier.rb +2 -2
  361. data/lib/factpulse/models/invoice_format.rb +2 -2
  362. data/lib/factpulse/models/invoice_input.rb +446 -0
  363. data/lib/factpulse/models/invoice_line.rb +23 -3
  364. data/lib/factpulse/models/invoice_line_allowance_amount.rb +2 -2
  365. data/lib/factpulse/models/invoice_note.rb +3 -2
  366. data/lib/factpulse/models/invoice_payment_input.rb +267 -0
  367. data/lib/factpulse/models/invoice_references.rb +2 -2
  368. data/lib/factpulse/models/invoice_status.rb +2 -2
  369. data/lib/factpulse/models/invoice_totals.rb +2 -2
  370. data/lib/factpulse/models/invoice_totals_prepayment.rb +2 -2
  371. data/lib/factpulse/models/invoice_type_code.rb +8 -19
  372. data/lib/factpulse/models/invoice_type_code_output.rb +54 -0
  373. data/lib/factpulse/models/invoicing_framework.rb +3 -2
  374. data/lib/factpulse/models/invoicing_framework_code.rb +2 -2
  375. data/lib/factpulse/models/line_net_amount.rb +2 -2
  376. data/lib/factpulse/models/line_sub_type.rb +41 -0
  377. data/lib/factpulse/models/line_total_amount.rb +2 -2
  378. data/lib/factpulse/models/{validation_error_loc_inner.rb → location_inner.rb} +3 -3
  379. data/lib/factpulse/models/mandatory_note_schema.rb +2 -2
  380. data/lib/factpulse/models/manual_rate.rb +2 -2
  381. data/lib/factpulse/models/manual_vat_rate.rb +2 -2
  382. data/lib/factpulse/models/missing_field.rb +2 -2
  383. data/lib/factpulse/models/operation_nature.rb +2 -2
  384. data/lib/factpulse/models/output_format.rb +2 -2
  385. data/lib/factpulse/models/page_dimensions_schema.rb +2 -2
  386. data/lib/factpulse/models/payee.rb +2 -2
  387. data/lib/factpulse/models/payment_amount_by_rate.rb +191 -0
  388. data/lib/factpulse/models/payment_card.rb +2 -2
  389. data/lib/factpulse/models/payment_means.rb +2 -2
  390. data/lib/factpulse/models/pdf_validation_result_api.rb +2 -2
  391. data/lib/factpulse/models/pdp_credentials.rb +2 -2
  392. data/lib/factpulse/models/percentage.rb +2 -2
  393. data/lib/factpulse/models/postal_address.rb +2 -2
  394. data/lib/factpulse/models/price_allowance_amount.rb +2 -2
  395. data/lib/factpulse/models/price_basis_quantity.rb +2 -2
  396. data/lib/factpulse/models/processing_options.rb +2 -2
  397. data/lib/factpulse/models/processing_rule.rb +44 -0
  398. data/lib/factpulse/models/product_characteristic.rb +2 -2
  399. data/lib/factpulse/models/product_classification.rb +2 -2
  400. data/lib/factpulse/models/quantity.rb +2 -2
  401. data/lib/factpulse/models/rate.rb +104 -0
  402. data/lib/factpulse/models/rate1.rb +104 -0
  403. data/lib/factpulse/models/recipient.rb +2 -2
  404. data/lib/factpulse/models/report_period.rb +193 -0
  405. data/lib/factpulse/models/report_sender.rb +221 -0
  406. data/lib/factpulse/models/rounding_amount.rb +2 -2
  407. data/lib/factpulse/models/routing_code_include.rb +40 -0
  408. data/lib/factpulse/models/scheme_id.rb +10 -3
  409. data/lib/factpulse/models/search_flow_request.rb +2 -2
  410. data/lib/factpulse/models/search_flow_response.rb +2 -2
  411. data/lib/factpulse/models/search_services_response.rb +5 -2
  412. data/lib/factpulse/models/search_structure_request.rb +3 -3
  413. data/lib/factpulse/models/search_structure_response.rb +2 -2
  414. data/lib/factpulse/models/sellercountry.rb +104 -0
  415. data/lib/factpulse/models/signature_info.rb +2 -2
  416. data/lib/factpulse/models/signature_info_api.rb +2 -2
  417. data/lib/factpulse/models/signature_parameters.rb +2 -2
  418. data/lib/factpulse/models/simplified_invoice_data.rb +69 -7
  419. data/lib/factpulse/models/siret_include.rb +39 -0
  420. data/lib/factpulse/models/structure_info.rb +2 -2
  421. data/lib/factpulse/models/structure_parameters.rb +2 -2
  422. data/lib/factpulse/models/structure_service.rb +2 -2
  423. data/lib/factpulse/models/submission_mode.rb +2 -2
  424. data/lib/factpulse/models/submit_aggregated_report_request.rb +216 -0
  425. data/lib/factpulse/models/submit_complete_invoice_request.rb +2 -2
  426. data/lib/factpulse/models/submit_complete_invoice_response.rb +2 -2
  427. data/lib/factpulse/models/submit_e_reporting_request.rb +216 -0
  428. data/lib/factpulse/models/submit_e_reporting_response.rb +306 -0
  429. data/lib/factpulse/models/submit_flow_request.rb +2 -2
  430. data/lib/factpulse/models/submit_flow_response.rb +2 -2
  431. data/lib/factpulse/models/submit_gross_amount.rb +2 -2
  432. data/lib/factpulse/models/submit_invoice_request.rb +3 -3
  433. data/lib/factpulse/models/submit_invoice_response.rb +2 -2
  434. data/lib/factpulse/models/submit_net_amount.rb +2 -2
  435. data/lib/factpulse/models/submit_vat_amount.rb +2 -2
  436. data/lib/factpulse/models/supplementary_attachment.rb +7 -2
  437. data/lib/factpulse/models/supplier.rb +2 -2
  438. data/lib/factpulse/models/task_response.rb +2 -2
  439. data/lib/factpulse/models/tax_breakdown_input.rb +217 -0
  440. data/lib/factpulse/models/tax_due_date_type.rb +44 -0
  441. data/lib/factpulse/models/tax_representative.rb +2 -2
  442. data/lib/factpulse/models/taxable_amount.rb +2 -2
  443. data/lib/factpulse/models/taxableamount0.rb +104 -0
  444. data/lib/factpulse/models/taxamount.rb +104 -0
  445. data/lib/factpulse/models/taxamount1.rb +104 -0
  446. data/lib/factpulse/models/taxamount2.rb +104 -0
  447. data/lib/factpulse/models/taxexclusiveamount.rb +104 -0
  448. data/lib/factpulse/models/taxexclusiveamount1.rb +104 -0
  449. data/lib/factpulse/models/total_gross_amount.rb +2 -2
  450. data/lib/factpulse/models/total_net_amount.rb +2 -2
  451. data/lib/factpulse/models/total_vat_amount.rb +2 -2
  452. data/lib/factpulse/models/transaction_category.rb +42 -0
  453. data/lib/factpulse/models/transmission_type_code.rb +40 -0
  454. data/lib/factpulse/models/unit_net_price.rb +2 -2
  455. data/lib/factpulse/models/unit_of_measure.rb +2 -2
  456. data/lib/factpulse/models/validate_e_reporting_request.rb +166 -0
  457. data/lib/factpulse/models/validate_e_reporting_response.rb +271 -0
  458. data/lib/factpulse/models/validation_error.rb +3 -3
  459. data/lib/factpulse/models/validation_error_detail.rb +2 -2
  460. data/lib/factpulse/models/validation_error_response.rb +2 -2
  461. data/lib/factpulse/models/validation_info.rb +3 -3
  462. data/lib/factpulse/models/validation_success_response.rb +2 -2
  463. data/lib/factpulse/models/vat_accounting_code.rb +2 -2
  464. data/lib/factpulse/models/vat_amount.rb +2 -2
  465. data/lib/factpulse/models/vat_category.rb +2 -2
  466. data/lib/factpulse/models/vat_line.rb +2 -2
  467. data/lib/factpulse/models/vat_point_date_code.rb +2 -2
  468. data/lib/factpulse/models/vat_rate.rb +2 -2
  469. data/lib/factpulse/models/verification_success_response.rb +2 -2
  470. data/lib/factpulse/models/verified_field_schema.rb +2 -2
  471. data/lib/factpulse/version.rb +3 -3
  472. data/lib/factpulse.rb +143 -6
  473. metadata +291 -17
  474. data/docs/ConvertErrorResponse.md +0 -26
  475. data/docs/ConvertPendingInputResponse.md +0 -32
  476. data/lib/factpulse/models/convert_pending_input_response.rb +0 -322
@@ -1,10 +1,10 @@
1
1
  =begin
2
2
  #FactPulse REST API
3
3
 
4
- # REST API for electronic invoicing in France: Factur-X, AFNOR PDP/PA, electronic signatures. ## 🎯 Main Features ### 📄 Factur-X Invoice Generation - **Formats**: XML only or PDF/A-3 with embedded XML - **Profiles**: MINIMUM, BASIC, EN16931, EXTENDED - **Standards**: EN 16931 (EU directive 2014/55), ISO 19005-3 (PDF/A-3), CII (UN/CEFACT) - **🆕 Simplified Format**: Generation from SIRET + auto-enrichment (Chorus Pro API + Business Search) ### ✅ Validation and Compliance - **XML Validation**: Schematron (45 to 210+ rules depending on profile) - **PDF Validation**: PDF/A-3, Factur-X XMP metadata, electronic signatures - **VeraPDF**: Strict PDF/A validation (146+ ISO 19005-3 rules) - **Asynchronous Processing**: Celery support for heavy validations (VeraPDF) ### 📡 AFNOR PDP/PA Integration (XP Z12-013) - **Flow Submission**: Send invoices to Partner Dematerialization Platforms - **Flow Search**: View submitted invoices - **Download**: Retrieve PDF/A-3 with XML - **Directory Service**: Company search (SIREN/SIRET) - **Multi-client**: Support for multiple PDP configs per user (stored credentials or zero-storage) ### ✍️ PDF Electronic Signature - **Standards**: PAdES-B-B, PAdES-B-T (RFC 3161 timestamping), PAdES-B-LT (long-term archival) - **eIDAS Levels**: SES (self-signed), AdES (commercial CA), QES (QTSP) - **Validation**: Cryptographic integrity and certificate verification - **Certificate Generation**: Self-signed X.509 certificates for testing ### 🔄 Asynchronous Processing - **Celery**: Asynchronous generation, validation and signing - **Polling**: Status tracking via `/tasks/{task_id}/status` - **No timeout**: Ideal for large files or heavy validations ## 🔒 Authentication All requests require a **JWT token** in the Authorization header: ``` Authorization: Bearer YOUR_JWT_TOKEN ``` ### How to obtain a JWT token? #### 🔑 Method 1: `/api/token/` API (Recommended) **URL:** `https://www.factpulse.fr/api/token/` This method is **recommended** for integration in your applications and CI/CD workflows. **Prerequisites:** Having set a password on your account **For users registered via email/password:** - You already have a password, use it directly **For users registered via OAuth (Google/GitHub):** - You must first set a password at: https://www.factpulse.fr/accounts/password/set/ - Once the password is created, you can use the API **Request example:** ```bash curl -X POST https://www.factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\" }' ``` **Optional `client_uid` parameter:** To select credentials for a specific client (PA/PDP, Chorus Pro, signing certificates), add `client_uid`: ```bash curl -X POST https://www.factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\", \"client_uid\": \"550e8400-e29b-41d4-a716-446655440000\" }' ``` The `client_uid` will be included in the JWT and allow the API to automatically use: - AFNOR/PDP credentials configured for this client - Chorus Pro credentials configured for this client - Electronic signature certificates configured for this client **Response:** ```json { \"access\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\", // Access token (validity: 30 min) \"refresh\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\" // Refresh token (validity: 7 days) } ``` **Advantages:** - ✅ Full automation (CI/CD, scripts) - ✅ Programmatic token management - ✅ Refresh token support for automatic access renewal - ✅ Easy integration in any language/tool #### 🖥️ Method 2: Dashboard Generation (Alternative) **URL:** https://www.factpulse.fr/dashboard/ This method is suitable for quick tests or occasional use via the graphical interface. **How it works:** - Log in to the dashboard - Use the \"Generate Test Token\" or \"Generate Production Token\" buttons - Works for **all** users (OAuth and email/password), without requiring a password **Token types:** - **Test Token**: 24h validity, 1000 calls/day quota (free) - **Production Token**: 7 days validity, quota based on your plan **Advantages:** - ✅ Quick for API testing - ✅ No password required - ✅ Simple visual interface **Disadvantages:** - ❌ Requires manual action - ❌ No refresh token - ❌ Less suited for automation ### 📚 Full Documentation For more information on authentication and API usage: https://www.factpulse.fr/documentation-api/
4
+ # REST API for electronic invoicing in France: Factur-X, AFNOR PDP/PA, electronic signatures. ## 🎯 Main Features ### 📄 Factur-X Invoice Generation - **Formats**: XML only or PDF/A-3 with embedded XML - **Profiles**: MINIMUM, BASIC, EN16931, EXTENDED - **Standards**: EN 16931 (EU directive 2014/55), ISO 19005-3 (PDF/A-3), CII (UN/CEFACT) - **🆕 Simplified Format**: Generation from SIRET + auto-enrichment (Chorus Pro API + Business Search) ### ✅ Validation and Compliance - **XML Validation**: Schematron (45 to 210+ rules depending on profile) - **PDF Validation**: PDF/A-3, Factur-X XMP metadata, electronic signatures - **VeraPDF**: Strict PDF/A validation (146+ ISO 19005-3 rules) - **Asynchronous Processing**: Celery support for heavy validations (VeraPDF) ### 📡 AFNOR PDP/PA Integration (XP Z12-013) - **Flow Submission**: Send invoices to Partner Dematerialization Platforms - **Flow Search**: View submitted invoices - **Download**: Retrieve PDF/A-3 with XML - **Directory Service**: Company search (SIREN/SIRET) - **Multi-client**: Support for multiple PDP configs per user (stored credentials or zero-storage) ### ✍️ PDF Electronic Signature - **Standards**: PAdES-B-B, PAdES-B-T (RFC 3161 timestamping), PAdES-B-LT (long-term archival) - **eIDAS Levels**: SES (self-signed), AdES (commercial CA), QES (QTSP) - **Validation**: Cryptographic integrity and certificate verification - **Certificate Generation**: Self-signed X.509 certificates for testing ### 🔄 Asynchronous Processing - **Celery**: Asynchronous generation, validation and signing - **Polling**: Status tracking via `/tasks/{task_id}/status` - **No timeout**: Ideal for large files or heavy validations ## 🔒 Authentication All requests require a **JWT token** in the Authorization header: ``` Authorization: Bearer YOUR_JWT_TOKEN ``` ### How to obtain a JWT token? #### 🔑 Method 1: `/api/token/` API (Recommended) **URL:** `https://factpulse.fr/api/token/` This method is **recommended** for integration in your applications and CI/CD workflows. **Prerequisites:** Having set a password on your account **For users registered via email/password:** - You already have a password, use it directly **For users registered via OAuth (Google/GitHub):** - You must first set a password at: https://factpulse.fr/accounts/password/set/ - Once the password is created, you can use the API **Request example:** ```bash curl -X POST https://factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\" }' ``` **Optional `client_uid` parameter:** To select credentials for a specific client (PA/PDP, Chorus Pro, signing certificates), add `client_uid`: ```bash curl -X POST https://factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\", \"client_uid\": \"550e8400-e29b-41d4-a716-446655440000\" }' ``` The `client_uid` will be included in the JWT and allow the API to automatically use: - AFNOR/PDP credentials configured for this client - Chorus Pro credentials configured for this client - Electronic signature certificates configured for this client **Response:** ```json { \"access\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\", // Access token (validity: 30 min) \"refresh\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\" // Refresh token (validity: 7 days) } ``` **Advantages:** - ✅ Full automation (CI/CD, scripts) - ✅ Programmatic token management - ✅ Refresh token support for automatic access renewal - ✅ Easy integration in any language/tool #### 🖥️ Method 2: Dashboard Generation (Alternative) **URL:** https://factpulse.fr/api/dashboard/ This method is suitable for quick tests or occasional use via the graphical interface. **How it works:** - Log in to the dashboard - Use the \"Generate Test Token\" or \"Generate Production Token\" buttons - Works for **all** users (OAuth and email/password), without requiring a password **Token types:** - **Test Token**: 24h validity, 1000 calls/day quota (free) - **Production Token**: 7 days validity, quota based on your plan **Advantages:** - ✅ Quick for API testing - ✅ No password required - ✅ Simple visual interface **Disadvantages:** - ❌ Requires manual action - ❌ No refresh token - ❌ Less suited for automation ### 📚 Full Documentation For more information on authentication and API usage: https://factpulse.fr/documentation-api/
5
5
 
6
6
  The version of the OpenAPI document: 1.0.0
7
-
7
+ Contact: contact@factpulse.fr
8
8
  Generated by: https://openapi-generator.tech
9
9
  Generator version: 7.19.0-SNAPSHOT
10
10
 
@@ -1,10 +1,10 @@
1
1
  =begin
2
2
  #FactPulse REST API
3
3
 
4
- # REST API for electronic invoicing in France: Factur-X, AFNOR PDP/PA, electronic signatures. ## 🎯 Main Features ### 📄 Factur-X Invoice Generation - **Formats**: XML only or PDF/A-3 with embedded XML - **Profiles**: MINIMUM, BASIC, EN16931, EXTENDED - **Standards**: EN 16931 (EU directive 2014/55), ISO 19005-3 (PDF/A-3), CII (UN/CEFACT) - **🆕 Simplified Format**: Generation from SIRET + auto-enrichment (Chorus Pro API + Business Search) ### ✅ Validation and Compliance - **XML Validation**: Schematron (45 to 210+ rules depending on profile) - **PDF Validation**: PDF/A-3, Factur-X XMP metadata, electronic signatures - **VeraPDF**: Strict PDF/A validation (146+ ISO 19005-3 rules) - **Asynchronous Processing**: Celery support for heavy validations (VeraPDF) ### 📡 AFNOR PDP/PA Integration (XP Z12-013) - **Flow Submission**: Send invoices to Partner Dematerialization Platforms - **Flow Search**: View submitted invoices - **Download**: Retrieve PDF/A-3 with XML - **Directory Service**: Company search (SIREN/SIRET) - **Multi-client**: Support for multiple PDP configs per user (stored credentials or zero-storage) ### ✍️ PDF Electronic Signature - **Standards**: PAdES-B-B, PAdES-B-T (RFC 3161 timestamping), PAdES-B-LT (long-term archival) - **eIDAS Levels**: SES (self-signed), AdES (commercial CA), QES (QTSP) - **Validation**: Cryptographic integrity and certificate verification - **Certificate Generation**: Self-signed X.509 certificates for testing ### 🔄 Asynchronous Processing - **Celery**: Asynchronous generation, validation and signing - **Polling**: Status tracking via `/tasks/{task_id}/status` - **No timeout**: Ideal for large files or heavy validations ## 🔒 Authentication All requests require a **JWT token** in the Authorization header: ``` Authorization: Bearer YOUR_JWT_TOKEN ``` ### How to obtain a JWT token? #### 🔑 Method 1: `/api/token/` API (Recommended) **URL:** `https://www.factpulse.fr/api/token/` This method is **recommended** for integration in your applications and CI/CD workflows. **Prerequisites:** Having set a password on your account **For users registered via email/password:** - You already have a password, use it directly **For users registered via OAuth (Google/GitHub):** - You must first set a password at: https://www.factpulse.fr/accounts/password/set/ - Once the password is created, you can use the API **Request example:** ```bash curl -X POST https://www.factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\" }' ``` **Optional `client_uid` parameter:** To select credentials for a specific client (PA/PDP, Chorus Pro, signing certificates), add `client_uid`: ```bash curl -X POST https://www.factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\", \"client_uid\": \"550e8400-e29b-41d4-a716-446655440000\" }' ``` The `client_uid` will be included in the JWT and allow the API to automatically use: - AFNOR/PDP credentials configured for this client - Chorus Pro credentials configured for this client - Electronic signature certificates configured for this client **Response:** ```json { \"access\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\", // Access token (validity: 30 min) \"refresh\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\" // Refresh token (validity: 7 days) } ``` **Advantages:** - ✅ Full automation (CI/CD, scripts) - ✅ Programmatic token management - ✅ Refresh token support for automatic access renewal - ✅ Easy integration in any language/tool #### 🖥️ Method 2: Dashboard Generation (Alternative) **URL:** https://www.factpulse.fr/dashboard/ This method is suitable for quick tests or occasional use via the graphical interface. **How it works:** - Log in to the dashboard - Use the \"Generate Test Token\" or \"Generate Production Token\" buttons - Works for **all** users (OAuth and email/password), without requiring a password **Token types:** - **Test Token**: 24h validity, 1000 calls/day quota (free) - **Production Token**: 7 days validity, quota based on your plan **Advantages:** - ✅ Quick for API testing - ✅ No password required - ✅ Simple visual interface **Disadvantages:** - ❌ Requires manual action - ❌ No refresh token - ❌ Less suited for automation ### 📚 Full Documentation For more information on authentication and API usage: https://www.factpulse.fr/documentation-api/
4
+ # REST API for electronic invoicing in France: Factur-X, AFNOR PDP/PA, electronic signatures. ## 🎯 Main Features ### 📄 Factur-X Invoice Generation - **Formats**: XML only or PDF/A-3 with embedded XML - **Profiles**: MINIMUM, BASIC, EN16931, EXTENDED - **Standards**: EN 16931 (EU directive 2014/55), ISO 19005-3 (PDF/A-3), CII (UN/CEFACT) - **🆕 Simplified Format**: Generation from SIRET + auto-enrichment (Chorus Pro API + Business Search) ### ✅ Validation and Compliance - **XML Validation**: Schematron (45 to 210+ rules depending on profile) - **PDF Validation**: PDF/A-3, Factur-X XMP metadata, electronic signatures - **VeraPDF**: Strict PDF/A validation (146+ ISO 19005-3 rules) - **Asynchronous Processing**: Celery support for heavy validations (VeraPDF) ### 📡 AFNOR PDP/PA Integration (XP Z12-013) - **Flow Submission**: Send invoices to Partner Dematerialization Platforms - **Flow Search**: View submitted invoices - **Download**: Retrieve PDF/A-3 with XML - **Directory Service**: Company search (SIREN/SIRET) - **Multi-client**: Support for multiple PDP configs per user (stored credentials or zero-storage) ### ✍️ PDF Electronic Signature - **Standards**: PAdES-B-B, PAdES-B-T (RFC 3161 timestamping), PAdES-B-LT (long-term archival) - **eIDAS Levels**: SES (self-signed), AdES (commercial CA), QES (QTSP) - **Validation**: Cryptographic integrity and certificate verification - **Certificate Generation**: Self-signed X.509 certificates for testing ### 🔄 Asynchronous Processing - **Celery**: Asynchronous generation, validation and signing - **Polling**: Status tracking via `/tasks/{task_id}/status` - **No timeout**: Ideal for large files or heavy validations ## 🔒 Authentication All requests require a **JWT token** in the Authorization header: ``` Authorization: Bearer YOUR_JWT_TOKEN ``` ### How to obtain a JWT token? #### 🔑 Method 1: `/api/token/` API (Recommended) **URL:** `https://factpulse.fr/api/token/` This method is **recommended** for integration in your applications and CI/CD workflows. **Prerequisites:** Having set a password on your account **For users registered via email/password:** - You already have a password, use it directly **For users registered via OAuth (Google/GitHub):** - You must first set a password at: https://factpulse.fr/accounts/password/set/ - Once the password is created, you can use the API **Request example:** ```bash curl -X POST https://factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\" }' ``` **Optional `client_uid` parameter:** To select credentials for a specific client (PA/PDP, Chorus Pro, signing certificates), add `client_uid`: ```bash curl -X POST https://factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\", \"client_uid\": \"550e8400-e29b-41d4-a716-446655440000\" }' ``` The `client_uid` will be included in the JWT and allow the API to automatically use: - AFNOR/PDP credentials configured for this client - Chorus Pro credentials configured for this client - Electronic signature certificates configured for this client **Response:** ```json { \"access\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\", // Access token (validity: 30 min) \"refresh\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\" // Refresh token (validity: 7 days) } ``` **Advantages:** - ✅ Full automation (CI/CD, scripts) - ✅ Programmatic token management - ✅ Refresh token support for automatic access renewal - ✅ Easy integration in any language/tool #### 🖥️ Method 2: Dashboard Generation (Alternative) **URL:** https://factpulse.fr/api/dashboard/ This method is suitable for quick tests or occasional use via the graphical interface. **How it works:** - Log in to the dashboard - Use the \"Generate Test Token\" or \"Generate Production Token\" buttons - Works for **all** users (OAuth and email/password), without requiring a password **Token types:** - **Test Token**: 24h validity, 1000 calls/day quota (free) - **Production Token**: 7 days validity, quota based on your plan **Advantages:** - ✅ Quick for API testing - ✅ No password required - ✅ Simple visual interface **Disadvantages:** - ❌ Requires manual action - ❌ No refresh token - ❌ Less suited for automation ### 📚 Full Documentation For more information on authentication and API usage: https://factpulse.fr/documentation-api/
5
5
 
6
6
  The version of the OpenAPI document: 1.0.0
7
-
7
+ Contact: contact@factpulse.fr
8
8
  Generated by: https://openapi-generator.tech
9
9
  Generator version: 7.19.0-SNAPSHOT
10
10
 
@@ -20,13 +20,16 @@ module FactPulse
20
20
  @api_client = api_client
21
21
  end
22
22
  # Generate a Factur-X invoice
23
- # Generates an electronic invoice in Factur-X format compliant with European standards. ## Applied Standards - **Factur-X** (France): FNFE-MPE standard (Forum National de la Facture Électronique) - **ZUGFeRD** (Germany): German format compatible with Factur-X - **EN 16931**: European semantic standard for electronic invoicing - **ISO 19005-3** (PDF/A-3): Long-term electronic archiving - **Cross Industry Invoice (CII)**: UN/CEFACT XML syntax ## 🆕 New: Simplified format with auto-enrichment (P0.1) You can now create an invoice by providing only: - An invoice number - A sender SIRET + **IBAN** (required) - A recipient SIRET - Invoice lines (description, quantity, net price) **Simplified format example**: ```json { \"number\": \"FACT-2025-001\", \"sender\": { \"siret\": \"92019522900017\", \"iban\": \"FR7630001007941234567890185\" }, \"recipient\": {\"siret\": \"35600000000048\"}, \"lines\": [ {\"description\": \"Service\", \"quantity\": 10, \"unitPrice\": 100.00, \"vatRate\": 20.0} ] } ``` **⚠️ Required fields (simplified format)**: - `number`: Unique invoice number - `sender.siret`: Sender's SIRET (14 digits) - `sender.iban`: Bank account IBAN (no public API to retrieve it) - `recipient.siret`: Recipient's SIRET - `lines[]`: At least one invoice line **What happens automatically with `auto_enrich=True`**: - ✅ Name enrichment from Chorus Pro API - ✅ Address enrichment from Business Search API (free, public) - ✅ Automatic intra-EU VAT calculation (FR + key + SIREN) - ✅ Chorus Pro ID retrieval for electronic invoicing - ✅ Net/VAT/Gross totals calculation - ✅ Date generation (today + 30-day due date) - ✅ Multi-rate VAT handling **Supported identifiers**: - SIRET (14 digits): Specific establishment ⭐ Recommended - SIREN (9 digits): Company (auto-selection of headquarters) - Special types: UE_HORS_FRANCE, RIDET, TAHITI, etc. ## Checks performed during generation ### 1. Data validation (Pydantic) - Data types (amounts as Decimal, ISO 8601 dates) - Formats (14-digit SIRET, 9-digit SIREN, IBAN) - Required fields per profile - Amount consistency (Net + VAT = Gross) ### 2. CII-compliant XML generation - Serialization according to Cross Industry Invoice XSD schema - Correct UN/CEFACT namespaces - Hierarchical structure respected - UTF-8 encoding without BOM ### 3. Schematron validation - Business rules for selected profile (MINIMUM, BASIC, EN16931, EXTENDED) - Element cardinality (required, optional, repeatable) - Calculation rules (totals, VAT, discounts) - European EN 16931 compliance ### 4. PDF/A-3 conversion (if output_format='pdf') - Source PDF conversion to PDF/A-3 via Ghostscript - Factur-X XML embedding in PDF - Compliant XMP metadata - ICC sRGB color profile - Removal of forbidden elements (JavaScript, forms) ## How it works 1. **Submission**: Invoice is queued in Celery for asynchronous processing 2. **Immediate return**: You receive a `task_id` (HTTP 202 Accepted) 3. **Tracking**: Use the `/tasks/{task_id}/status` endpoint to track progress ## Output formats - **xml**: Generates only Factur-X XML (recommended for testing) - **pdf**: Generates PDF/A-3 with embedded XML (requires `source_pdf`) ## Factur-X profiles - **MINIMUM**: Minimal data (simplified invoice) - **BASIC**: Basic information (SMEs) - **EN16931**: European standard (recommended, compliant with directive 2014/55/EU) - **EXTENDED**: All available data (large accounts) ## What you get After successful processing (status `completed`): - **XML only**: Base64-encoded Factur-X compliant XML file - **PDF/A-3**: PDF with embedded XML, ready for sending/archiving - **Metadata**: Profile, Factur-X version, file size - **Validation**: Schematron compliance confirmation ## Validation Data is automatically validated according to detected format. On error, a 422 status is returned with invalid field details.
24
- # @param invoice_data [String] Invoice data in JSON format. Two formats accepted: 1. **Classic format**: Complete FactureFacturX structure (all fields) 2. **Simplified format** (🆕 P0.1): Minimal structure with auto-enrichment Format is detected automatically!
23
+ # Generates an electronic invoice in Factur-X format compliant with European standards. ## Applied Standards - **Factur-X** (France): FNFE-MPE standard (Forum National de la Facture Électronique) - **ZUGFeRD** (Germany): German format compatible with Factur-X - **EN 16931**: European semantic standard for electronic invoicing - **ISO 19005-3** (PDF/A-3): Long-term electronic archiving - **Cross Industry Invoice (CII)**: UN/CEFACT XML syntax ## 🆕 New: Simplified format with auto-enrichment (P0.1) You can now create an invoice by providing only: - An invoice number - A supplier SIRET + **IBAN** (required) - A recipient SIRET - Invoice lines (description, quantity, net price) **Simplified format example**: ```json { \"number\": \"FACT-2025-001\", \"supplier\": { \"siret\": \"92019522900017\", \"iban\": \"FR7630001007941234567890185\" }, \"recipient\": {\"siret\": \"35600000000048\"}, \"lines\": [ {\"description\": \"Service\", \"quantity\": 10, \"unitPrice\": 100.00, \"vatRate\": 20.0} ] } ``` **⚠️ Required fields (simplified format)**: - `number`: Unique invoice number - `supplier.siret`: Supplier's SIRET (14 digits) - `supplier.iban`: Bank account IBAN (no public API to retrieve it) - `recipient.siret`: Recipient's SIRET - `lines[]`: At least one invoice line **What happens automatically with `auto_enrich=True`**: - ✅ Name enrichment from Chorus Pro API - ✅ Address enrichment from Business Search API (free, public) - ✅ Automatic intra-EU VAT calculation (FR + key + SIREN) - ✅ Chorus Pro ID retrieval for electronic invoicing - ✅ Net/VAT/Gross totals calculation - ✅ Date generation (today + 30-day due date) - ✅ Multi-rate VAT handling **Supported identifiers**: - SIRET (14 digits): Specific establishment ⭐ Recommended - SIREN (9 digits): Company (auto-selection of headquarters) - Special types: UE_HORS_FRANCE, RIDET, TAHITI, etc. ## Checks performed during generation ### 1. Data validation (Pydantic) - Data types (amounts as Decimal, ISO 8601 dates) - Formats (14-digit SIRET, 9-digit SIREN, IBAN) - Required fields per profile - Amount consistency (Net + VAT = Gross) ### 2. CII-compliant XML generation - Serialization according to Cross Industry Invoice XSD schema - Correct UN/CEFACT namespaces - Hierarchical structure respected - UTF-8 encoding without BOM ### 3. Schematron validation - Business rules for selected profile (MINIMUM, BASIC, EN16931, EXTENDED) - Element cardinality (required, optional, repeatable) - Calculation rules (totals, VAT, discounts) - European EN 16931 compliance ### 4. PDF/A-3 conversion (if output_format='pdf') - Source PDF conversion to PDF/A-3 via Ghostscript - Factur-X XML embedding in PDF - Compliant XMP metadata - ICC sRGB color profile - Removal of forbidden elements (JavaScript, forms) ## How it works 1. **Submission**: Invoice is queued in Celery for asynchronous processing 2. **Immediate return**: You receive a `task_id` (HTTP 202 Accepted) 3. **Tracking**: Use the `/tasks/{task_id}/status` endpoint to track progress ## Webhook notification (recommended) Instead of polling, you can receive a webhook notification when the task completes: ``` callback_url=https://your-server.com/webhook ``` The webhook will POST a JSON payload with: - `event_type`: `generation.completed` or `generation.failed` - `data.task_id`: The Celery task ID - `data.content_b64` or `data.xml_content`: The generated content - `X-Webhook-Signature` header for HMAC verification See `/docs/WEBHOOKS.md` for full documentation. ## Output formats - **xml**: Generates only Factur-X XML (recommended for testing) - **pdf**: Generates PDF/A-3 with embedded XML (requires `source_pdf`) ## Factur-X profiles - **MINIMUM**: Minimal data (simplified invoice) - **BASIC**: Basic information (SMEs) - **EN16931**: European standard (recommended, compliant with directive 2014/55/EU) - **EXTENDED**: All available data (large accounts) ## What you get After successful processing (status `completed`): - **XML only**: Base64-encoded Factur-X compliant XML file - **PDF/A-3**: PDF with embedded XML, ready for sending/archiving - **Metadata**: Profile, Factur-X version, file size - **Validation**: Schematron compliance confirmation ## Validation Data is automatically validated according to detected format. On error, a 422 status is returned with invalid field details.
24
+ # @param invoice_data [String] Invoice data in JSON format. Two formats accepted: 1. **Classic format**: Complete FacturXInvoice structure (all fields) 2. **Simplified format** (🆕 P0.1): Minimal structure with auto-enrichment Format is detected automatically!
25
25
  # @param [Hash] opts the optional parameters
26
26
  # @option opts [APIProfile] :profile Factur-X profile: MINIMUM, BASIC, EN16931 or EXTENDED.
27
27
  # @option opts [OutputFormat] :output_format Output format: 'xml' (XML only) or 'pdf' (Factur-X PDF with embedded XML).
28
28
  # @option opts [Boolean] :auto_enrich 🆕 Enable auto-enrichment from SIRET/SIREN (simplified format only) (default to true)
29
29
  # @option opts [File] :source_pdf
30
+ # @option opts [String] :callback_url
31
+ # @option opts [String] :webhook_mode Webhook content delivery: 'inline' (base64 in payload) or 'download_url' (temporary URL, 1h TTL) (default to 'inline')
32
+ # @option opts [Boolean] :skip_br_fr
30
33
  # @return [TaskResponse]
31
34
  def generate_invoice_api_v1_processing_generate_invoice_post(invoice_data, opts = {})
32
35
  data, _status_code, _headers = generate_invoice_api_v1_processing_generate_invoice_post_with_http_info(invoice_data, opts)
@@ -34,13 +37,16 @@ module FactPulse
34
37
  end
35
38
 
36
39
  # Generate a Factur-X invoice
37
- # Generates an electronic invoice in Factur-X format compliant with European standards. ## Applied Standards - **Factur-X** (France): FNFE-MPE standard (Forum National de la Facture Électronique) - **ZUGFeRD** (Germany): German format compatible with Factur-X - **EN 16931**: European semantic standard for electronic invoicing - **ISO 19005-3** (PDF/A-3): Long-term electronic archiving - **Cross Industry Invoice (CII)**: UN/CEFACT XML syntax ## 🆕 New: Simplified format with auto-enrichment (P0.1) You can now create an invoice by providing only: - An invoice number - A sender SIRET + **IBAN** (required) - A recipient SIRET - Invoice lines (description, quantity, net price) **Simplified format example**: ```json { \"number\": \"FACT-2025-001\", \"sender\": { \"siret\": \"92019522900017\", \"iban\": \"FR7630001007941234567890185\" }, \"recipient\": {\"siret\": \"35600000000048\"}, \"lines\": [ {\"description\": \"Service\", \"quantity\": 10, \"unitPrice\": 100.00, \"vatRate\": 20.0} ] } ``` **⚠️ Required fields (simplified format)**: - `number`: Unique invoice number - `sender.siret`: Sender's SIRET (14 digits) - `sender.iban`: Bank account IBAN (no public API to retrieve it) - `recipient.siret`: Recipient's SIRET - `lines[]`: At least one invoice line **What happens automatically with `auto_enrich=True`**: - ✅ Name enrichment from Chorus Pro API - ✅ Address enrichment from Business Search API (free, public) - ✅ Automatic intra-EU VAT calculation (FR + key + SIREN) - ✅ Chorus Pro ID retrieval for electronic invoicing - ✅ Net/VAT/Gross totals calculation - ✅ Date generation (today + 30-day due date) - ✅ Multi-rate VAT handling **Supported identifiers**: - SIRET (14 digits): Specific establishment ⭐ Recommended - SIREN (9 digits): Company (auto-selection of headquarters) - Special types: UE_HORS_FRANCE, RIDET, TAHITI, etc. ## Checks performed during generation ### 1. Data validation (Pydantic) - Data types (amounts as Decimal, ISO 8601 dates) - Formats (14-digit SIRET, 9-digit SIREN, IBAN) - Required fields per profile - Amount consistency (Net + VAT = Gross) ### 2. CII-compliant XML generation - Serialization according to Cross Industry Invoice XSD schema - Correct UN/CEFACT namespaces - Hierarchical structure respected - UTF-8 encoding without BOM ### 3. Schematron validation - Business rules for selected profile (MINIMUM, BASIC, EN16931, EXTENDED) - Element cardinality (required, optional, repeatable) - Calculation rules (totals, VAT, discounts) - European EN 16931 compliance ### 4. PDF/A-3 conversion (if output_format='pdf') - Source PDF conversion to PDF/A-3 via Ghostscript - Factur-X XML embedding in PDF - Compliant XMP metadata - ICC sRGB color profile - Removal of forbidden elements (JavaScript, forms) ## How it works 1. **Submission**: Invoice is queued in Celery for asynchronous processing 2. **Immediate return**: You receive a `task_id` (HTTP 202 Accepted) 3. **Tracking**: Use the `/tasks/{task_id}/status` endpoint to track progress ## Output formats - **xml**: Generates only Factur-X XML (recommended for testing) - **pdf**: Generates PDF/A-3 with embedded XML (requires `source_pdf`) ## Factur-X profiles - **MINIMUM**: Minimal data (simplified invoice) - **BASIC**: Basic information (SMEs) - **EN16931**: European standard (recommended, compliant with directive 2014/55/EU) - **EXTENDED**: All available data (large accounts) ## What you get After successful processing (status `completed`): - **XML only**: Base64-encoded Factur-X compliant XML file - **PDF/A-3**: PDF with embedded XML, ready for sending/archiving - **Metadata**: Profile, Factur-X version, file size - **Validation**: Schematron compliance confirmation ## Validation Data is automatically validated according to detected format. On error, a 422 status is returned with invalid field details.
38
- # @param invoice_data [String] Invoice data in JSON format. Two formats accepted: 1. **Classic format**: Complete FactureFacturX structure (all fields) 2. **Simplified format** (🆕 P0.1): Minimal structure with auto-enrichment Format is detected automatically!
40
+ # Generates an electronic invoice in Factur-X format compliant with European standards. ## Applied Standards - **Factur-X** (France): FNFE-MPE standard (Forum National de la Facture Électronique) - **ZUGFeRD** (Germany): German format compatible with Factur-X - **EN 16931**: European semantic standard for electronic invoicing - **ISO 19005-3** (PDF/A-3): Long-term electronic archiving - **Cross Industry Invoice (CII)**: UN/CEFACT XML syntax ## 🆕 New: Simplified format with auto-enrichment (P0.1) You can now create an invoice by providing only: - An invoice number - A supplier SIRET + **IBAN** (required) - A recipient SIRET - Invoice lines (description, quantity, net price) **Simplified format example**: ```json { \"number\": \"FACT-2025-001\", \"supplier\": { \"siret\": \"92019522900017\", \"iban\": \"FR7630001007941234567890185\" }, \"recipient\": {\"siret\": \"35600000000048\"}, \"lines\": [ {\"description\": \"Service\", \"quantity\": 10, \"unitPrice\": 100.00, \"vatRate\": 20.0} ] } ``` **⚠️ Required fields (simplified format)**: - `number`: Unique invoice number - `supplier.siret`: Supplier's SIRET (14 digits) - `supplier.iban`: Bank account IBAN (no public API to retrieve it) - `recipient.siret`: Recipient's SIRET - `lines[]`: At least one invoice line **What happens automatically with `auto_enrich=True`**: - ✅ Name enrichment from Chorus Pro API - ✅ Address enrichment from Business Search API (free, public) - ✅ Automatic intra-EU VAT calculation (FR + key + SIREN) - ✅ Chorus Pro ID retrieval for electronic invoicing - ✅ Net/VAT/Gross totals calculation - ✅ Date generation (today + 30-day due date) - ✅ Multi-rate VAT handling **Supported identifiers**: - SIRET (14 digits): Specific establishment ⭐ Recommended - SIREN (9 digits): Company (auto-selection of headquarters) - Special types: UE_HORS_FRANCE, RIDET, TAHITI, etc. ## Checks performed during generation ### 1. Data validation (Pydantic) - Data types (amounts as Decimal, ISO 8601 dates) - Formats (14-digit SIRET, 9-digit SIREN, IBAN) - Required fields per profile - Amount consistency (Net + VAT = Gross) ### 2. CII-compliant XML generation - Serialization according to Cross Industry Invoice XSD schema - Correct UN/CEFACT namespaces - Hierarchical structure respected - UTF-8 encoding without BOM ### 3. Schematron validation - Business rules for selected profile (MINIMUM, BASIC, EN16931, EXTENDED) - Element cardinality (required, optional, repeatable) - Calculation rules (totals, VAT, discounts) - European EN 16931 compliance ### 4. PDF/A-3 conversion (if output_format='pdf') - Source PDF conversion to PDF/A-3 via Ghostscript - Factur-X XML embedding in PDF - Compliant XMP metadata - ICC sRGB color profile - Removal of forbidden elements (JavaScript, forms) ## How it works 1. **Submission**: Invoice is queued in Celery for asynchronous processing 2. **Immediate return**: You receive a `task_id` (HTTP 202 Accepted) 3. **Tracking**: Use the `/tasks/{task_id}/status` endpoint to track progress ## Webhook notification (recommended) Instead of polling, you can receive a webhook notification when the task completes: ``` callback_url=https://your-server.com/webhook ``` The webhook will POST a JSON payload with: - `event_type`: `generation.completed` or `generation.failed` - `data.task_id`: The Celery task ID - `data.content_b64` or `data.xml_content`: The generated content - `X-Webhook-Signature` header for HMAC verification See `/docs/WEBHOOKS.md` for full documentation. ## Output formats - **xml**: Generates only Factur-X XML (recommended for testing) - **pdf**: Generates PDF/A-3 with embedded XML (requires `source_pdf`) ## Factur-X profiles - **MINIMUM**: Minimal data (simplified invoice) - **BASIC**: Basic information (SMEs) - **EN16931**: European standard (recommended, compliant with directive 2014/55/EU) - **EXTENDED**: All available data (large accounts) ## What you get After successful processing (status `completed`): - **XML only**: Base64-encoded Factur-X compliant XML file - **PDF/A-3**: PDF with embedded XML, ready for sending/archiving - **Metadata**: Profile, Factur-X version, file size - **Validation**: Schematron compliance confirmation ## Validation Data is automatically validated according to detected format. On error, a 422 status is returned with invalid field details.
41
+ # @param invoice_data [String] Invoice data in JSON format. Two formats accepted: 1. **Classic format**: Complete FacturXInvoice structure (all fields) 2. **Simplified format** (🆕 P0.1): Minimal structure with auto-enrichment Format is detected automatically!
39
42
  # @param [Hash] opts the optional parameters
40
43
  # @option opts [APIProfile] :profile Factur-X profile: MINIMUM, BASIC, EN16931 or EXTENDED.
41
44
  # @option opts [OutputFormat] :output_format Output format: 'xml' (XML only) or 'pdf' (Factur-X PDF with embedded XML).
42
45
  # @option opts [Boolean] :auto_enrich 🆕 Enable auto-enrichment from SIRET/SIREN (simplified format only) (default to true)
43
46
  # @option opts [File] :source_pdf
47
+ # @option opts [String] :callback_url
48
+ # @option opts [String] :webhook_mode Webhook content delivery: 'inline' (base64 in payload) or 'download_url' (temporary URL, 1h TTL) (default to 'inline')
49
+ # @option opts [Boolean] :skip_br_fr
44
50
  # @return [Array<(TaskResponse, Integer, Hash)>] TaskResponse data, response status code and response headers
45
51
  def generate_invoice_api_v1_processing_generate_invoice_post_with_http_info(invoice_data, opts = {})
46
52
  if @api_client.config.debugging
@@ -73,6 +79,9 @@ module FactPulse
73
79
  form_params['output_format'] = opts[:'output_format'] if !opts[:'output_format'].nil?
74
80
  form_params['auto_enrich'] = opts[:'auto_enrich'] if !opts[:'auto_enrich'].nil?
75
81
  form_params['source_pdf'] = opts[:'source_pdf'] if !opts[:'source_pdf'].nil?
82
+ form_params['callback_url'] = opts[:'callback_url'] if !opts[:'callback_url'].nil?
83
+ form_params['webhook_mode'] = opts[:'webhook_mode'] if !opts[:'webhook_mode'].nil?
84
+ form_params['skip_br_fr'] = opts[:'skip_br_fr'] if !opts[:'skip_br_fr'].nil?
76
85
 
77
86
  # http body (model)
78
87
  post_body = opts[:debug_body]
@@ -101,7 +110,7 @@ module FactPulse
101
110
  end
102
111
 
103
112
  # Generate a self-signed X.509 test certificate
104
- # Generates a self-signed X.509 certificate for PDF electronic signature testing. **⚠️ WARNING: TEST certificate only!** This certificate is: - ✅ Suitable for testing and development - ✅ Compatible with PDF signing (PAdES) - ✅ Compliant with eIDAS **SES** level (Simple Electronic Signature) - ❌ **NEVER usable in production** - ❌ **Not recognized** by browsers and PDF readers - ❌ **No legal value** ## eIDAS levels - **SES** (Simple): Self-signed certificate ← Generated by this endpoint - **AdES** (Advanced): Commercial CA certificate (Let's Encrypt, etc.) - **QES** (Qualified): Qualified certificate from QTSP (CertEurope, Universign, etc.) ## Usage Once generated, the certificate can be: 1. **Saved in Django** (recommended): - Django Admin > Signing Certificates - Upload `certificate_pem` and `private_key_pem` 2. **Used directly**: - Sign a PDF with `/sign-pdf` - The certificate will be automatically used ## Example call ```bash curl -X POST \"https://www.factpulse.fr/api/v1/processing/generate-test-certificate\" \\ -H \"Authorization: Bearer eyJ0eXAi...\" \\ -H \"Content-Type: application/json\" \\ -d '{ \"cn\": \"Test Client XYZ\", \"organization\": \"Client XYZ Ltd\", \"email\": \"contact@xyz.com\", \"validity_days\": 365 }' ``` ## Use cases - PDF signature testing in development - Electronic signature POC - Training and demos - Automated integration tests ## Technical compliance Certificate generated with: - RSA key 2048 or 4096 bits - SHA-256 algorithm - Key Usage extensions: `digitalSignature`, `contentCommitment` (non-repudiation) - Extended Key Usage extensions: `codeSigning`, `emailProtection` - Validity: 1 day to 10 years (configurable) - Format: PEM (certificate and key) - Optional: PKCS#12 (.p12)
113
+ # Generates a self-signed X.509 certificate for PDF electronic signature testing. **⚠️ WARNING: TEST certificate only!** This certificate is: - ✅ Suitable for testing and development - ✅ Compatible with PDF signing (PAdES) - ✅ Compliant with eIDAS **SES** level (Simple Electronic Signature) - ❌ **NEVER usable in production** - ❌ **Not recognized** by browsers and PDF readers - ❌ **No legal value** ## eIDAS levels - **SES** (Simple): Self-signed certificate ← Generated by this endpoint - **AdES** (Advanced): Commercial CA certificate (Let's Encrypt, etc.) - **QES** (Qualified): Qualified certificate from QTSP (CertEurope, Universign, etc.) ## Usage Once generated, the certificate can be: 1. **Saved in Django** (recommended): - Django Admin > Signing Certificates - Upload `certificate_pem` and `private_key_pem` 2. **Used directly**: - Sign a PDF with `/sign-pdf` - The certificate will be automatically used ## Example call ```bash curl -X POST \"https://factpulse.fr/api/v1/processing/generate-test-certificate\" \\ -H \"Authorization: Bearer eyJ0eXAi...\" \\ -H \"Content-Type: application/json\" \\ -d '{ \"cn\": \"Test Client XYZ\", \"organization\": \"Client XYZ Ltd\", \"email\": \"contact@xyz.com\", \"validity_days\": 365 }' ``` ## Use cases - PDF signature testing in development - Electronic signature POC - Training and demos - Automated integration tests ## Technical compliance Certificate generated with: - RSA key 2048 or 4096 bits - SHA-256 algorithm - Key Usage extensions: `digitalSignature`, `contentCommitment` (non-repudiation) - Extended Key Usage extensions: `codeSigning`, `emailProtection` - Validity: 1 day to 10 years (configurable) - Format: PEM (certificate and key) - Optional: PKCS#12 (.p12)
105
114
  # @param generate_certificate_request [GenerateCertificateRequest]
106
115
  # @param [Hash] opts the optional parameters
107
116
  # @return [GenerateCertificateResponse]
@@ -111,7 +120,7 @@ module FactPulse
111
120
  end
112
121
 
113
122
  # Generate a self-signed X.509 test certificate
114
- # Generates a self-signed X.509 certificate for PDF electronic signature testing. **⚠️ WARNING: TEST certificate only!** This certificate is: - ✅ Suitable for testing and development - ✅ Compatible with PDF signing (PAdES) - ✅ Compliant with eIDAS **SES** level (Simple Electronic Signature) - ❌ **NEVER usable in production** - ❌ **Not recognized** by browsers and PDF readers - ❌ **No legal value** ## eIDAS levels - **SES** (Simple): Self-signed certificate ← Generated by this endpoint - **AdES** (Advanced): Commercial CA certificate (Let&#39;s Encrypt, etc.) - **QES** (Qualified): Qualified certificate from QTSP (CertEurope, Universign, etc.) ## Usage Once generated, the certificate can be: 1. **Saved in Django** (recommended): - Django Admin &gt; Signing Certificates - Upload &#x60;certificate_pem&#x60; and &#x60;private_key_pem&#x60; 2. **Used directly**: - Sign a PDF with &#x60;/sign-pdf&#x60; - The certificate will be automatically used ## Example call &#x60;&#x60;&#x60;bash curl -X POST \&quot;https://www.factpulse.fr/api/v1/processing/generate-test-certificate\&quot; \\ -H \&quot;Authorization: Bearer eyJ0eXAi...\&quot; \\ -H \&quot;Content-Type: application/json\&quot; \\ -d &#39;{ \&quot;cn\&quot;: \&quot;Test Client XYZ\&quot;, \&quot;organization\&quot;: \&quot;Client XYZ Ltd\&quot;, \&quot;email\&quot;: \&quot;contact@xyz.com\&quot;, \&quot;validity_days\&quot;: 365 }&#39; &#x60;&#x60;&#x60; ## Use cases - PDF signature testing in development - Electronic signature POC - Training and demos - Automated integration tests ## Technical compliance Certificate generated with: - RSA key 2048 or 4096 bits - SHA-256 algorithm - Key Usage extensions: &#x60;digitalSignature&#x60;, &#x60;contentCommitment&#x60; (non-repudiation) - Extended Key Usage extensions: &#x60;codeSigning&#x60;, &#x60;emailProtection&#x60; - Validity: 1 day to 10 years (configurable) - Format: PEM (certificate and key) - Optional: PKCS#12 (.p12)
123
+ # Generates a self-signed X.509 certificate for PDF electronic signature testing. **⚠️ WARNING: TEST certificate only!** This certificate is: - ✅ Suitable for testing and development - ✅ Compatible with PDF signing (PAdES) - ✅ Compliant with eIDAS **SES** level (Simple Electronic Signature) - ❌ **NEVER usable in production** - ❌ **Not recognized** by browsers and PDF readers - ❌ **No legal value** ## eIDAS levels - **SES** (Simple): Self-signed certificate ← Generated by this endpoint - **AdES** (Advanced): Commercial CA certificate (Let&#39;s Encrypt, etc.) - **QES** (Qualified): Qualified certificate from QTSP (CertEurope, Universign, etc.) ## Usage Once generated, the certificate can be: 1. **Saved in Django** (recommended): - Django Admin &gt; Signing Certificates - Upload &#x60;certificate_pem&#x60; and &#x60;private_key_pem&#x60; 2. **Used directly**: - Sign a PDF with &#x60;/sign-pdf&#x60; - The certificate will be automatically used ## Example call &#x60;&#x60;&#x60;bash curl -X POST \&quot;https://factpulse.fr/api/v1/processing/generate-test-certificate\&quot; \\ -H \&quot;Authorization: Bearer eyJ0eXAi...\&quot; \\ -H \&quot;Content-Type: application/json\&quot; \\ -d &#39;{ \&quot;cn\&quot;: \&quot;Test Client XYZ\&quot;, \&quot;organization\&quot;: \&quot;Client XYZ Ltd\&quot;, \&quot;email\&quot;: \&quot;contact@xyz.com\&quot;, \&quot;validity_days\&quot;: 365 }&#39; &#x60;&#x60;&#x60; ## Use cases - PDF signature testing in development - Electronic signature POC - Training and demos - Automated integration tests ## Technical compliance Certificate generated with: - RSA key 2048 or 4096 bits - SHA-256 algorithm - Key Usage extensions: &#x60;digitalSignature&#x60;, &#x60;contentCommitment&#x60; (non-repudiation) - Extended Key Usage extensions: &#x60;codeSigning&#x60;, &#x60;emailProtection&#x60; - Validity: 1 day to 10 years (configurable) - Format: PEM (certificate and key) - Optional: PKCS#12 (.p12)
115
124
  # @param generate_certificate_request [GenerateCertificateRequest]
116
125
  # @param [Hash] opts the optional parameters
117
126
  # @return [Array<(GenerateCertificateResponse, Integer, Hash)>] GenerateCertificateResponse data, response status code and response headers
@@ -170,7 +179,7 @@ module FactPulse
170
179
 
171
180
  # Get task generation status
172
181
  # Retrieves the progress status of an invoice generation task. ## Possible states The `status` field uses the `CeleryStatus` enum with values: - **PENDING, STARTED, SUCCESS, FAILURE, RETRY** See the `CeleryStatus` schema documentation for details. ## Business result When `status=\"SUCCESS\"`, the `result` field contains: - `status`: \"SUCCESS\" or \"ERROR\" (business result) - `content_b64`: Base64 encoded content (if success) - `errorCode`, `errorMessage`, `details`: AFNOR format (if business error) ## Usage Poll this endpoint every 2-3 seconds until `status` is `SUCCESS` or `FAILURE`.
173
- # @param task_id [String]
182
+ # @param task_id [String] Celery task ID returned by async endpoints (UUID format)
174
183
  # @param [Hash] opts the optional parameters
175
184
  # @return [AsyncTaskStatus]
176
185
  def get_task_status_api_v1_processing_tasks_task_id_status_get(task_id, opts = {})
@@ -180,7 +189,7 @@ module FactPulse
180
189
 
181
190
  # Get task generation status
182
191
  # Retrieves the progress status of an invoice generation task. ## Possible states The &#x60;status&#x60; field uses the &#x60;CeleryStatus&#x60; enum with values: - **PENDING, STARTED, SUCCESS, FAILURE, RETRY** See the &#x60;CeleryStatus&#x60; schema documentation for details. ## Business result When &#x60;status&#x3D;\&quot;SUCCESS\&quot;&#x60;, the &#x60;result&#x60; field contains: - &#x60;status&#x60;: \&quot;SUCCESS\&quot; or \&quot;ERROR\&quot; (business result) - &#x60;content_b64&#x60;: Base64 encoded content (if success) - &#x60;errorCode&#x60;, &#x60;errorMessage&#x60;, &#x60;details&#x60;: AFNOR format (if business error) ## Usage Poll this endpoint every 2-3 seconds until &#x60;status&#x60; is &#x60;SUCCESS&#x60; or &#x60;FAILURE&#x60;.
183
- # @param task_id [String]
192
+ # @param task_id [String] Celery task ID returned by async endpoints (UUID format)
184
193
  # @param [Hash] opts the optional parameters
185
194
  # @return [Array<(AsyncTaskStatus, Integer, Hash)>] AsyncTaskStatus data, response status code and response headers
186
195
  def get_task_status_api_v1_processing_tasks_task_id_status_get_with_http_info(task_id, opts = {})
@@ -322,6 +331,8 @@ module FactPulse
322
331
  # Signs an uploaded PDF asynchronously via a Celery task. **Difference with /sign-pdf**: - `/sign-pdf`: Synchronous signature (blocking until completion) - `/sign-pdf-async`: Asynchronous signature (returns immediately with task_id) **Async advantages**: - No timeout for large files - No blocking of FastAPI worker - Progress tracking via task_id - Ideal for batch processing **Supported standards**: PAdES-B-B, PAdES-B-T (timestamping), PAdES-B-LT (long-term archiving). **⚠️ Legal disclaimer**: Same as /sign-pdf (see that endpoint's documentation).
323
332
  # @param pdf_file [File] PDF file to sign (processed asynchronously)
324
333
  # @param [Hash] opts the optional parameters
334
+ # @option opts [String] :callback_url
335
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
325
336
  # @option opts [String] :reason
326
337
  # @option opts [String] :location
327
338
  # @option opts [String] :contact
@@ -338,6 +349,8 @@ module FactPulse
338
349
  # Signs an uploaded PDF asynchronously via a Celery task. **Difference with /sign-pdf**: - &#x60;/sign-pdf&#x60;: Synchronous signature (blocking until completion) - &#x60;/sign-pdf-async&#x60;: Asynchronous signature (returns immediately with task_id) **Async advantages**: - No timeout for large files - No blocking of FastAPI worker - Progress tracking via task_id - Ideal for batch processing **Supported standards**: PAdES-B-B, PAdES-B-T (timestamping), PAdES-B-LT (long-term archiving). **⚠️ Legal disclaimer**: Same as /sign-pdf (see that endpoint&#39;s documentation).
339
350
  # @param pdf_file [File] PDF file to sign (processed asynchronously)
340
351
  # @param [Hash] opts the optional parameters
352
+ # @option opts [String] :callback_url
353
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
341
354
  # @option opts [String] :reason
342
355
  # @option opts [String] :location
343
356
  # @option opts [String] :contact
@@ -372,6 +385,8 @@ module FactPulse
372
385
  # form parameters
373
386
  form_params = opts[:form_params] || {}
374
387
  form_params['pdf_file'] = pdf_file
388
+ form_params['callback_url'] = opts[:'callback_url'] if !opts[:'callback_url'].nil?
389
+ form_params['webhook_mode'] = opts[:'webhook_mode'] if !opts[:'webhook_mode'].nil?
375
390
  form_params['reason'] = opts[:'reason'] if !opts[:'reason'].nil?
376
391
  form_params['location'] = opts[:'location'] if !opts[:'location'].nil?
377
392
  form_params['contact'] = opts[:'contact'] if !opts[:'contact'].nil?
@@ -474,9 +489,11 @@ module FactPulse
474
489
  end
475
490
 
476
491
  # Submit a complete invoice (asynchronous with Celery)
477
- # Asynchronous version of the `/invoices/submit-complete` endpoint using Celery for background processing. **Automated workflow (same as synchronous version):** 1. **Auto-enrichment** (optional): retrieves data via public APIs and Chorus Pro/AFNOR 2. **Factur-X PDF generation**: creates a PDF/A-3 with embedded XML 3. **Electronic signature** (optional): signs the PDF with a certificate 4. **Submission**: sends to the chosen destination (Chorus Pro or AFNOR PDP) **Supported destinations:** - **Chorus Pro**: French B2G platform (invoices to public sector) - **AFNOR PDP**: Partner Dematerialization Platforms **Differences with synchronous version:** - ✅ **Non-blocking**: Returns immediately with a `task_id` (HTTP 202 Accepted) - ✅ **Background processing**: Invoice is processed by a Celery worker - ✅ **Progress tracking**: Use `/tasks/{task_id}/status` to track status - ✅ **Ideal for high volumes**: Allows processing many invoices in parallel **How to use:** 1. **Submission**: Call this endpoint with your invoice data 2. **Immediate return**: You receive a `task_id` (e.g., \"abc123-def456\") 3. **Tracking**: Call `/tasks/{task_id}/status` to check progress 4. **Result**: When `status = \"SUCCESS\"`, the `result` field contains the complete response **Credentials and signature**: Same modes as the synchronous version (JWT or payload).
492
+ # Asynchronous version of the `/invoices/submit-complete` endpoint using Celery for background processing. **Automated workflow (same as synchronous version):** 1. **Auto-enrichment** (optional): retrieves data via public APIs and Chorus Pro/AFNOR 2. **Factur-X PDF generation**: creates a PDF/A-3 with embedded XML 3. **Electronic signature** (optional): signs the PDF with a certificate 4. **Submission**: sends to the chosen destination (Chorus Pro or AFNOR PDP) **Supported destinations:** - **Chorus Pro**: French B2G platform (invoices to public sector) - **AFNOR PDP**: Partner Dematerialization Platforms **Differences with synchronous version:** - ✅ **Non-blocking**: Returns immediately with a `task_id` (HTTP 202 Accepted) - ✅ **Background processing**: Invoice is processed by a Celery worker - ✅ **Progress tracking**: Use `/tasks/{task_id}/status` to track status - ✅ **Ideal for high volumes**: Allows processing many invoices in parallel **How to use:** 1. **Submission**: Call this endpoint with your invoice data 2. **Immediate return**: You receive a `task_id` (e.g., \"abc123-def456\") 3. **Tracking**: Call `/tasks/{task_id}/status` to check progress 4. **Result**: When `status = \"SUCCESS\"`, the `result` field contains the complete response **Webhook notification (recommended):** Instead of polling, add `?callback_url=https://your-server.com/webhook` to receive automatic notification: - `event_type`: `submission.completed`, `submission.failed`, or `submission.partial` - `data.submission_result`: Complete submission result - `X-Webhook-Signature` header for HMAC verification **Credentials and signature**: Same modes as the synchronous version (JWT or payload).
478
493
  # @param submit_complete_invoice_request [SubmitCompleteInvoiceRequest]
479
494
  # @param [Hash] opts the optional parameters
495
+ # @option opts [String] :callback_url Webhook URL for async notification when submission completes.
496
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
480
497
  # @return [TaskResponse]
481
498
  def submit_complete_invoice_async_api_v1_processing_invoices_submit_complete_async_post(submit_complete_invoice_request, opts = {})
482
499
  data, _status_code, _headers = submit_complete_invoice_async_api_v1_processing_invoices_submit_complete_async_post_with_http_info(submit_complete_invoice_request, opts)
@@ -484,9 +501,11 @@ module FactPulse
484
501
  end
485
502
 
486
503
  # Submit a complete invoice (asynchronous with Celery)
487
- # Asynchronous version of the &#x60;/invoices/submit-complete&#x60; endpoint using Celery for background processing. **Automated workflow (same as synchronous version):** 1. **Auto-enrichment** (optional): retrieves data via public APIs and Chorus Pro/AFNOR 2. **Factur-X PDF generation**: creates a PDF/A-3 with embedded XML 3. **Electronic signature** (optional): signs the PDF with a certificate 4. **Submission**: sends to the chosen destination (Chorus Pro or AFNOR PDP) **Supported destinations:** - **Chorus Pro**: French B2G platform (invoices to public sector) - **AFNOR PDP**: Partner Dematerialization Platforms **Differences with synchronous version:** - ✅ **Non-blocking**: Returns immediately with a &#x60;task_id&#x60; (HTTP 202 Accepted) - ✅ **Background processing**: Invoice is processed by a Celery worker - ✅ **Progress tracking**: Use &#x60;/tasks/{task_id}/status&#x60; to track status - ✅ **Ideal for high volumes**: Allows processing many invoices in parallel **How to use:** 1. **Submission**: Call this endpoint with your invoice data 2. **Immediate return**: You receive a &#x60;task_id&#x60; (e.g., \&quot;abc123-def456\&quot;) 3. **Tracking**: Call &#x60;/tasks/{task_id}/status&#x60; to check progress 4. **Result**: When &#x60;status &#x3D; \&quot;SUCCESS\&quot;&#x60;, the &#x60;result&#x60; field contains the complete response **Credentials and signature**: Same modes as the synchronous version (JWT or payload).
504
+ # Asynchronous version of the &#x60;/invoices/submit-complete&#x60; endpoint using Celery for background processing. **Automated workflow (same as synchronous version):** 1. **Auto-enrichment** (optional): retrieves data via public APIs and Chorus Pro/AFNOR 2. **Factur-X PDF generation**: creates a PDF/A-3 with embedded XML 3. **Electronic signature** (optional): signs the PDF with a certificate 4. **Submission**: sends to the chosen destination (Chorus Pro or AFNOR PDP) **Supported destinations:** - **Chorus Pro**: French B2G platform (invoices to public sector) - **AFNOR PDP**: Partner Dematerialization Platforms **Differences with synchronous version:** - ✅ **Non-blocking**: Returns immediately with a &#x60;task_id&#x60; (HTTP 202 Accepted) - ✅ **Background processing**: Invoice is processed by a Celery worker - ✅ **Progress tracking**: Use &#x60;/tasks/{task_id}/status&#x60; to track status - ✅ **Ideal for high volumes**: Allows processing many invoices in parallel **How to use:** 1. **Submission**: Call this endpoint with your invoice data 2. **Immediate return**: You receive a &#x60;task_id&#x60; (e.g., \&quot;abc123-def456\&quot;) 3. **Tracking**: Call &#x60;/tasks/{task_id}/status&#x60; to check progress 4. **Result**: When &#x60;status &#x3D; \&quot;SUCCESS\&quot;&#x60;, the &#x60;result&#x60; field contains the complete response **Webhook notification (recommended):** Instead of polling, add &#x60;?callback_url&#x3D;https://your-server.com/webhook&#x60; to receive automatic notification: - &#x60;event_type&#x60;: &#x60;submission.completed&#x60;, &#x60;submission.failed&#x60;, or &#x60;submission.partial&#x60; - &#x60;data.submission_result&#x60;: Complete submission result - &#x60;X-Webhook-Signature&#x60; header for HMAC verification **Credentials and signature**: Same modes as the synchronous version (JWT or payload).
488
505
  # @param submit_complete_invoice_request [SubmitCompleteInvoiceRequest]
489
506
  # @param [Hash] opts the optional parameters
507
+ # @option opts [String] :callback_url Webhook URL for async notification when submission completes.
508
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
490
509
  # @return [Array<(TaskResponse, Integer, Hash)>] TaskResponse data, response status code and response headers
491
510
  def submit_complete_invoice_async_api_v1_processing_invoices_submit_complete_async_post_with_http_info(submit_complete_invoice_request, opts = {})
492
511
  if @api_client.config.debugging
@@ -501,6 +520,8 @@ module FactPulse
501
520
 
502
521
  # query parameters
503
522
  query_params = opts[:query_params] || {}
523
+ query_params[:'callback_url'] = opts[:'callback_url'] if !opts[:'callback_url'].nil?
524
+ query_params[:'webhook_mode'] = opts[:'webhook_mode'] if !opts[:'webhook_mode'].nil?
504
525
 
505
526
  # header parameters
506
527
  header_params = opts[:header_params] || {}
@@ -547,6 +568,7 @@ module FactPulse
547
568
  # @param [Hash] opts the optional parameters
548
569
  # @option opts [APIProfile] :profile
549
570
  # @option opts [Boolean] :use_verapdf Enable strict PDF/A validation with VeraPDF (recommended for production). If False, uses basic metadata validation. (default to false)
571
+ # @option opts [Boolean] :skip_br_fr
550
572
  # @return [PDFValidationResultAPI]
551
573
  def validate_facturx_pdf_api_v1_processing_validate_facturx_pdf_post(pdf_file, opts = {})
552
574
  data, _status_code, _headers = validate_facturx_pdf_api_v1_processing_validate_facturx_pdf_post_with_http_info(pdf_file, opts)
@@ -559,6 +581,7 @@ module FactPulse
559
581
  # @param [Hash] opts the optional parameters
560
582
  # @option opts [APIProfile] :profile
561
583
  # @option opts [Boolean] :use_verapdf Enable strict PDF/A validation with VeraPDF (recommended for production). If False, uses basic metadata validation. (default to false)
584
+ # @option opts [Boolean] :skip_br_fr
562
585
  # @return [Array<(PDFValidationResultAPI, Integer, Hash)>] PDFValidationResultAPI data, response status code and response headers
563
586
  def validate_facturx_pdf_api_v1_processing_validate_facturx_pdf_post_with_http_info(pdf_file, opts = {})
564
587
  if @api_client.config.debugging
@@ -589,6 +612,7 @@ module FactPulse
589
612
  form_params['pdf_file'] = pdf_file
590
613
  form_params['profile'] = opts[:'profile'] if !opts[:'profile'].nil?
591
614
  form_params['use_verapdf'] = opts[:'use_verapdf'] if !opts[:'use_verapdf'].nil?
615
+ form_params['skip_br_fr'] = opts[:'skip_br_fr'] if !opts[:'skip_br_fr'].nil?
592
616
 
593
617
  # http body (model)
594
618
  post_body = opts[:debug_body]
@@ -617,11 +641,13 @@ module FactPulse
617
641
  end
618
642
 
619
643
  # Validate a Factur-X PDF (asynchronous with polling)
620
- # Validates a Factur-X PDF asynchronously with polling system. ## How it works 1. **Submission**: PDF is queued for asynchronous validation 2. **Immediate return**: You receive a `task_id` (HTTP 202) 3. **Tracking**: Use the `/tasks/{task_id}/status` endpoint to track progress ## Advantages of asynchronous mode - **No timeout**: Ideal for large PDFs or VeraPDF validation (which can take several seconds) - **Scalability**: Validations are processed by dedicated Celery workers - **Status tracking**: Allows you to monitor validation progress - **Non-blocking**: Your client doesn't wait during validation ## When to use this mode? - **VeraPDF validation enabled** (`use_verapdf=True`): Strict validation can take 2-10 seconds - **Large PDF files**: PDFs > 1 MB - **Batch processing**: Validating multiple invoices in parallel - **Asynchronous integration**: Your system supports polling ## Checks performed ### 1. Factur-X XML extraction and validation - Verifies presence of Factur-X compliant embedded XML file - Automatically detects profile used (MINIMUM, BASIC, EN16931, EXTENDED) - Validates XML against detected profile's Schematron rules ### 2. PDF/A compliance - **Without VeraPDF**: Basic metadata validation (fast, ~100ms) - **With VeraPDF**: Strict ISO 19005 validation (146+ rules, 2-10s) - Detects PDF/A version (PDF/A-1, PDF/A-3, etc.) - Detailed non-compliance reports ### 3. XMP metadata - Verifies presence of XMP metadata in PDF - Validates Factur-X metadata compliance (profile, version) - Extracts all available XMP metadata ### 4. Electronic signatures - Detects presence of electronic signatures or seals - Extracts information about each signature (signer, date, reason) - Counts number of signatures present ## Parameters - **pdf_file**: The Factur-X PDF file to validate - **profile**: Expected Factur-X profile (optional). If not specified, profile will be auto-detected from embedded XML file. - **use_verapdf**: Enable strict PDF/A validation with VeraPDF. ⚠️ **Warning**: VeraPDF can take 2-10 seconds depending on PDF size. Recommended only in asynchronous mode to avoid timeouts. ## Retrieving results After submission, use `GET /tasks/{task_id}/status` endpoint to retrieve the result. **Polling example**: ```python import requests import time # 1. Submit task response = requests.post(\"/validate-facturx-async\", files={\"pdf_file\": pdf_file}) task_id = response.json()[\"taskId\"] # 2. Poll every 2 seconds while True: status_response = requests.get(f\"/tasks/{task_id}/status\") status = status_response.json() if status[\"status\"] == \"SUCCESS\": result = status[\"result\"][\"validation_result\"] print(f\"Compliant: {result['is_compliant']}\") break elif status[\"status\"] == \"FAILURE\": print(f\"Error: {status['result']['errorMessage']}\") break time.sleep(2) # Wait 2 seconds before next check ``` ## Use cases - Validate invoices before sending with VeraPDF (strict validation) - Process invoice batches in parallel - Integrate validation into an asynchronous pipeline - Validate large PDFs without timeout risk
644
+ # Validates a Factur-X PDF asynchronously with polling system. ## How it works 1. **Submission**: PDF is queued for asynchronous validation 2. **Immediate return**: You receive a `task_id` (HTTP 202) 3. **Tracking**: Use the `/tasks/{task_id}/status` endpoint to track progress ## Advantages of asynchronous mode - **No timeout**: Ideal for large PDFs or VeraPDF validation (which can take several seconds) - **Scalability**: Validations are processed by dedicated Celery workers - **Status tracking**: Allows you to monitor validation progress - **Non-blocking**: Your client doesn't wait during validation ## Webhook notification (recommended) Instead of polling, you can receive a webhook notification when validation completes: ``` callback_url=https://your-server.com/webhook webhook_mode=download_url # Optional: get download URL instead of base64 ``` The webhook will POST a JSON payload with: - `event_type`: `validation.completed` or `validation.failed` - `data.is_compliant`: Whether the PDF is Factur-X compliant - `data.detected_profile`: The detected Factur-X profile - `X-Webhook-Signature` header for HMAC verification ## When to use this mode? - **VeraPDF validation enabled** (`use_verapdf=True`): Strict validation can take 2-10 seconds - **Large PDF files**: PDFs > 1 MB - **Batch processing**: Validating multiple invoices in parallel - **Asynchronous integration**: Your system supports polling ## Checks performed ### 1. Factur-X XML extraction and validation - Verifies presence of Factur-X compliant embedded XML file - Automatically detects profile used (MINIMUM, BASIC, EN16931, EXTENDED) - Validates XML against detected profile's Schematron rules ### 2. PDF/A compliance - **Without VeraPDF**: Basic metadata validation (fast, ~100ms) - **With VeraPDF**: Strict ISO 19005 validation (146+ rules, 2-10s) - Detects PDF/A version (PDF/A-1, PDF/A-3, etc.) - Detailed non-compliance reports ### 3. XMP metadata - Verifies presence of XMP metadata in PDF - Validates Factur-X metadata compliance (profile, version) - Extracts all available XMP metadata ### 4. Electronic signatures - Detects presence of electronic signatures or seals - Extracts information about each signature (signer, date, reason) - Counts number of signatures present ## Parameters - **pdf_file**: The Factur-X PDF file to validate - **profile**: Expected Factur-X profile (optional). If not specified, profile will be auto-detected from embedded XML file. - **use_verapdf**: Enable strict PDF/A validation with VeraPDF. ⚠️ **Warning**: VeraPDF can take 2-10 seconds depending on PDF size. Recommended only in asynchronous mode to avoid timeouts. ## Retrieving results After submission, use `GET /tasks/{task_id}/status` endpoint to retrieve the result. **Polling example**: ```python import requests import time # 1. Submit task response = requests.post(\"/validate-facturx-async\", files={\"pdf_file\": pdf_file}) task_id = response.json()[\"taskId\"] # 2. Poll every 2 seconds while True: status_response = requests.get(f\"/tasks/{task_id}/status\") status = status_response.json() if status[\"status\"] == \"SUCCESS\": result = status[\"result\"][\"validation_result\"] print(f\"Compliant: {result['is_compliant']}\") break elif status[\"status\"] == \"FAILURE\": print(f\"Error: {status['result']['errorMessage']}\") break time.sleep(2) # Wait 2 seconds before next check ``` ## Use cases - Validate invoices before sending with VeraPDF (strict validation) - Process invoice batches in parallel - Integrate validation into an asynchronous pipeline - Validate large PDFs without timeout risk
621
645
  # @param pdf_file [File] Factur-X PDF file to validate (.pdf format).
622
646
  # @param [Hash] opts the optional parameters
623
647
  # @option opts [APIProfile] :profile
624
648
  # @option opts [Boolean] :use_verapdf Enable strict PDF/A validation with VeraPDF (recommended for production). May take several seconds. (default to false)
649
+ # @option opts [String] :callback_url
650
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
625
651
  # @return [TaskResponse]
626
652
  def validate_facturx_pdf_async_api_v1_processing_validate_facturx_async_post(pdf_file, opts = {})
627
653
  data, _status_code, _headers = validate_facturx_pdf_async_api_v1_processing_validate_facturx_async_post_with_http_info(pdf_file, opts)
@@ -629,11 +655,13 @@ module FactPulse
629
655
  end
630
656
 
631
657
  # Validate a Factur-X PDF (asynchronous with polling)
632
- # Validates a Factur-X PDF asynchronously with polling system. ## How it works 1. **Submission**: PDF is queued for asynchronous validation 2. **Immediate return**: You receive a &#x60;task_id&#x60; (HTTP 202) 3. **Tracking**: Use the &#x60;/tasks/{task_id}/status&#x60; endpoint to track progress ## Advantages of asynchronous mode - **No timeout**: Ideal for large PDFs or VeraPDF validation (which can take several seconds) - **Scalability**: Validations are processed by dedicated Celery workers - **Status tracking**: Allows you to monitor validation progress - **Non-blocking**: Your client doesn&#39;t wait during validation ## When to use this mode? - **VeraPDF validation enabled** (&#x60;use_verapdf&#x3D;True&#x60;): Strict validation can take 2-10 seconds - **Large PDF files**: PDFs &gt; 1 MB - **Batch processing**: Validating multiple invoices in parallel - **Asynchronous integration**: Your system supports polling ## Checks performed ### 1. Factur-X XML extraction and validation - Verifies presence of Factur-X compliant embedded XML file - Automatically detects profile used (MINIMUM, BASIC, EN16931, EXTENDED) - Validates XML against detected profile&#39;s Schematron rules ### 2. PDF/A compliance - **Without VeraPDF**: Basic metadata validation (fast, ~100ms) - **With VeraPDF**: Strict ISO 19005 validation (146+ rules, 2-10s) - Detects PDF/A version (PDF/A-1, PDF/A-3, etc.) - Detailed non-compliance reports ### 3. XMP metadata - Verifies presence of XMP metadata in PDF - Validates Factur-X metadata compliance (profile, version) - Extracts all available XMP metadata ### 4. Electronic signatures - Detects presence of electronic signatures or seals - Extracts information about each signature (signer, date, reason) - Counts number of signatures present ## Parameters - **pdf_file**: The Factur-X PDF file to validate - **profile**: Expected Factur-X profile (optional). If not specified, profile will be auto-detected from embedded XML file. - **use_verapdf**: Enable strict PDF/A validation with VeraPDF. ⚠️ **Warning**: VeraPDF can take 2-10 seconds depending on PDF size. Recommended only in asynchronous mode to avoid timeouts. ## Retrieving results After submission, use &#x60;GET /tasks/{task_id}/status&#x60; endpoint to retrieve the result. **Polling example**: &#x60;&#x60;&#x60;python import requests import time # 1. Submit task response &#x3D; requests.post(\&quot;/validate-facturx-async\&quot;, files&#x3D;{\&quot;pdf_file\&quot;: pdf_file}) task_id &#x3D; response.json()[\&quot;taskId\&quot;] # 2. Poll every 2 seconds while True: status_response &#x3D; requests.get(f\&quot;/tasks/{task_id}/status\&quot;) status &#x3D; status_response.json() if status[\&quot;status\&quot;] &#x3D;&#x3D; \&quot;SUCCESS\&quot;: result &#x3D; status[\&quot;result\&quot;][\&quot;validation_result\&quot;] print(f\&quot;Compliant: {result[&#39;is_compliant&#39;]}\&quot;) break elif status[\&quot;status\&quot;] &#x3D;&#x3D; \&quot;FAILURE\&quot;: print(f\&quot;Error: {status[&#39;result&#39;][&#39;errorMessage&#39;]}\&quot;) break time.sleep(2) # Wait 2 seconds before next check &#x60;&#x60;&#x60; ## Use cases - Validate invoices before sending with VeraPDF (strict validation) - Process invoice batches in parallel - Integrate validation into an asynchronous pipeline - Validate large PDFs without timeout risk
658
+ # Validates a Factur-X PDF asynchronously with polling system. ## How it works 1. **Submission**: PDF is queued for asynchronous validation 2. **Immediate return**: You receive a &#x60;task_id&#x60; (HTTP 202) 3. **Tracking**: Use the &#x60;/tasks/{task_id}/status&#x60; endpoint to track progress ## Advantages of asynchronous mode - **No timeout**: Ideal for large PDFs or VeraPDF validation (which can take several seconds) - **Scalability**: Validations are processed by dedicated Celery workers - **Status tracking**: Allows you to monitor validation progress - **Non-blocking**: Your client doesn&#39;t wait during validation ## Webhook notification (recommended) Instead of polling, you can receive a webhook notification when validation completes: &#x60;&#x60;&#x60; callback_url&#x3D;https://your-server.com/webhook webhook_mode&#x3D;download_url # Optional: get download URL instead of base64 &#x60;&#x60;&#x60; The webhook will POST a JSON payload with: - &#x60;event_type&#x60;: &#x60;validation.completed&#x60; or &#x60;validation.failed&#x60; - &#x60;data.is_compliant&#x60;: Whether the PDF is Factur-X compliant - &#x60;data.detected_profile&#x60;: The detected Factur-X profile - &#x60;X-Webhook-Signature&#x60; header for HMAC verification ## When to use this mode? - **VeraPDF validation enabled** (&#x60;use_verapdf&#x3D;True&#x60;): Strict validation can take 2-10 seconds - **Large PDF files**: PDFs &gt; 1 MB - **Batch processing**: Validating multiple invoices in parallel - **Asynchronous integration**: Your system supports polling ## Checks performed ### 1. Factur-X XML extraction and validation - Verifies presence of Factur-X compliant embedded XML file - Automatically detects profile used (MINIMUM, BASIC, EN16931, EXTENDED) - Validates XML against detected profile&#39;s Schematron rules ### 2. PDF/A compliance - **Without VeraPDF**: Basic metadata validation (fast, ~100ms) - **With VeraPDF**: Strict ISO 19005 validation (146+ rules, 2-10s) - Detects PDF/A version (PDF/A-1, PDF/A-3, etc.) - Detailed non-compliance reports ### 3. XMP metadata - Verifies presence of XMP metadata in PDF - Validates Factur-X metadata compliance (profile, version) - Extracts all available XMP metadata ### 4. Electronic signatures - Detects presence of electronic signatures or seals - Extracts information about each signature (signer, date, reason) - Counts number of signatures present ## Parameters - **pdf_file**: The Factur-X PDF file to validate - **profile**: Expected Factur-X profile (optional). If not specified, profile will be auto-detected from embedded XML file. - **use_verapdf**: Enable strict PDF/A validation with VeraPDF. ⚠️ **Warning**: VeraPDF can take 2-10 seconds depending on PDF size. Recommended only in asynchronous mode to avoid timeouts. ## Retrieving results After submission, use &#x60;GET /tasks/{task_id}/status&#x60; endpoint to retrieve the result. **Polling example**: &#x60;&#x60;&#x60;python import requests import time # 1. Submit task response &#x3D; requests.post(\&quot;/validate-facturx-async\&quot;, files&#x3D;{\&quot;pdf_file\&quot;: pdf_file}) task_id &#x3D; response.json()[\&quot;taskId\&quot;] # 2. Poll every 2 seconds while True: status_response &#x3D; requests.get(f\&quot;/tasks/{task_id}/status\&quot;) status &#x3D; status_response.json() if status[\&quot;status\&quot;] &#x3D;&#x3D; \&quot;SUCCESS\&quot;: result &#x3D; status[\&quot;result\&quot;][\&quot;validation_result\&quot;] print(f\&quot;Compliant: {result[&#39;is_compliant&#39;]}\&quot;) break elif status[\&quot;status\&quot;] &#x3D;&#x3D; \&quot;FAILURE\&quot;: print(f\&quot;Error: {status[&#39;result&#39;][&#39;errorMessage&#39;]}\&quot;) break time.sleep(2) # Wait 2 seconds before next check &#x60;&#x60;&#x60; ## Use cases - Validate invoices before sending with VeraPDF (strict validation) - Process invoice batches in parallel - Integrate validation into an asynchronous pipeline - Validate large PDFs without timeout risk
633
659
  # @param pdf_file [File] Factur-X PDF file to validate (.pdf format).
634
660
  # @param [Hash] opts the optional parameters
635
661
  # @option opts [APIProfile] :profile
636
662
  # @option opts [Boolean] :use_verapdf Enable strict PDF/A validation with VeraPDF (recommended for production). May take several seconds. (default to false)
663
+ # @option opts [String] :callback_url
664
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
637
665
  # @return [Array<(TaskResponse, Integer, Hash)>] TaskResponse data, response status code and response headers
638
666
  def validate_facturx_pdf_async_api_v1_processing_validate_facturx_async_post_with_http_info(pdf_file, opts = {})
639
667
  if @api_client.config.debugging
@@ -664,6 +692,8 @@ module FactPulse
664
692
  form_params['pdf_file'] = pdf_file
665
693
  form_params['profile'] = opts[:'profile'] if !opts[:'profile'].nil?
666
694
  form_params['use_verapdf'] = opts[:'use_verapdf'] if !opts[:'use_verapdf'].nil?
695
+ form_params['callback_url'] = opts[:'callback_url'] if !opts[:'callback_url'].nil?
696
+ form_params['webhook_mode'] = opts[:'webhook_mode'] if !opts[:'webhook_mode'].nil?
667
697
 
668
698
  # http body (model)
669
699
  post_body = opts[:debug_body]
@@ -765,6 +795,7 @@ module FactPulse
765
795
  # @param xml_file [File] Factur-X XML file to validate (.xml format).
766
796
  # @param [Hash] opts the optional parameters
767
797
  # @option opts [APIProfile] :profile Validation profile (MINIMUM, BASIC, EN16931, EXTENDED).
798
+ # @option opts [Boolean] :skip_br_fr
768
799
  # @return [ValidationSuccessResponse]
769
800
  def validate_xml_api_v1_processing_validate_xml_post(xml_file, opts = {})
770
801
  data, _status_code, _headers = validate_xml_api_v1_processing_validate_xml_post_with_http_info(xml_file, opts)
@@ -776,6 +807,7 @@ module FactPulse
776
807
  # @param xml_file [File] Factur-X XML file to validate (.xml format).
777
808
  # @param [Hash] opts the optional parameters
778
809
  # @option opts [APIProfile] :profile Validation profile (MINIMUM, BASIC, EN16931, EXTENDED).
810
+ # @option opts [Boolean] :skip_br_fr
779
811
  # @return [Array<(ValidationSuccessResponse, Integer, Hash)>] ValidationSuccessResponse data, response status code and response headers
780
812
  def validate_xml_api_v1_processing_validate_xml_post_with_http_info(xml_file, opts = {})
781
813
  if @api_client.config.debugging
@@ -805,6 +837,7 @@ module FactPulse
805
837
  form_params = opts[:form_params] || {}
806
838
  form_params['xml_file'] = xml_file
807
839
  form_params['profile'] = opts[:'profile'] if !opts[:'profile'].nil?
840
+ form_params['skip_br_fr'] = opts[:'skip_br_fr'] if !opts[:'skip_br_fr'].nil?
808
841
 
809
842
  # http body (model)
810
843
  post_body = opts[:debug_body]
@@ -1,10 +1,10 @@
1
1
  =begin
2
2
  #FactPulse REST API
3
3
 
4
- # REST API for electronic invoicing in France: Factur-X, AFNOR PDP/PA, electronic signatures. ## 🎯 Main Features ### 📄 Factur-X Invoice Generation - **Formats**: XML only or PDF/A-3 with embedded XML - **Profiles**: MINIMUM, BASIC, EN16931, EXTENDED - **Standards**: EN 16931 (EU directive 2014/55), ISO 19005-3 (PDF/A-3), CII (UN/CEFACT) - **🆕 Simplified Format**: Generation from SIRET + auto-enrichment (Chorus Pro API + Business Search) ### ✅ Validation and Compliance - **XML Validation**: Schematron (45 to 210+ rules depending on profile) - **PDF Validation**: PDF/A-3, Factur-X XMP metadata, electronic signatures - **VeraPDF**: Strict PDF/A validation (146+ ISO 19005-3 rules) - **Asynchronous Processing**: Celery support for heavy validations (VeraPDF) ### 📡 AFNOR PDP/PA Integration (XP Z12-013) - **Flow Submission**: Send invoices to Partner Dematerialization Platforms - **Flow Search**: View submitted invoices - **Download**: Retrieve PDF/A-3 with XML - **Directory Service**: Company search (SIREN/SIRET) - **Multi-client**: Support for multiple PDP configs per user (stored credentials or zero-storage) ### ✍️ PDF Electronic Signature - **Standards**: PAdES-B-B, PAdES-B-T (RFC 3161 timestamping), PAdES-B-LT (long-term archival) - **eIDAS Levels**: SES (self-signed), AdES (commercial CA), QES (QTSP) - **Validation**: Cryptographic integrity and certificate verification - **Certificate Generation**: Self-signed X.509 certificates for testing ### 🔄 Asynchronous Processing - **Celery**: Asynchronous generation, validation and signing - **Polling**: Status tracking via `/tasks/{task_id}/status` - **No timeout**: Ideal for large files or heavy validations ## 🔒 Authentication All requests require a **JWT token** in the Authorization header: ``` Authorization: Bearer YOUR_JWT_TOKEN ``` ### How to obtain a JWT token? #### 🔑 Method 1: `/api/token/` API (Recommended) **URL:** `https://www.factpulse.fr/api/token/` This method is **recommended** for integration in your applications and CI/CD workflows. **Prerequisites:** Having set a password on your account **For users registered via email/password:** - You already have a password, use it directly **For users registered via OAuth (Google/GitHub):** - You must first set a password at: https://www.factpulse.fr/accounts/password/set/ - Once the password is created, you can use the API **Request example:** ```bash curl -X POST https://www.factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\" }' ``` **Optional `client_uid` parameter:** To select credentials for a specific client (PA/PDP, Chorus Pro, signing certificates), add `client_uid`: ```bash curl -X POST https://www.factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\", \"client_uid\": \"550e8400-e29b-41d4-a716-446655440000\" }' ``` The `client_uid` will be included in the JWT and allow the API to automatically use: - AFNOR/PDP credentials configured for this client - Chorus Pro credentials configured for this client - Electronic signature certificates configured for this client **Response:** ```json { \"access\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\", // Access token (validity: 30 min) \"refresh\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\" // Refresh token (validity: 7 days) } ``` **Advantages:** - ✅ Full automation (CI/CD, scripts) - ✅ Programmatic token management - ✅ Refresh token support for automatic access renewal - ✅ Easy integration in any language/tool #### 🖥️ Method 2: Dashboard Generation (Alternative) **URL:** https://www.factpulse.fr/dashboard/ This method is suitable for quick tests or occasional use via the graphical interface. **How it works:** - Log in to the dashboard - Use the \"Generate Test Token\" or \"Generate Production Token\" buttons - Works for **all** users (OAuth and email/password), without requiring a password **Token types:** - **Test Token**: 24h validity, 1000 calls/day quota (free) - **Production Token**: 7 days validity, quota based on your plan **Advantages:** - ✅ Quick for API testing - ✅ No password required - ✅ Simple visual interface **Disadvantages:** - ❌ Requires manual action - ❌ No refresh token - ❌ Less suited for automation ### 📚 Full Documentation For more information on authentication and API usage: https://www.factpulse.fr/documentation-api/
4
+ # REST API for electronic invoicing in France: Factur-X, AFNOR PDP/PA, electronic signatures. ## 🎯 Main Features ### 📄 Factur-X Invoice Generation - **Formats**: XML only or PDF/A-3 with embedded XML - **Profiles**: MINIMUM, BASIC, EN16931, EXTENDED - **Standards**: EN 16931 (EU directive 2014/55), ISO 19005-3 (PDF/A-3), CII (UN/CEFACT) - **🆕 Simplified Format**: Generation from SIRET + auto-enrichment (Chorus Pro API + Business Search) ### ✅ Validation and Compliance - **XML Validation**: Schematron (45 to 210+ rules depending on profile) - **PDF Validation**: PDF/A-3, Factur-X XMP metadata, electronic signatures - **VeraPDF**: Strict PDF/A validation (146+ ISO 19005-3 rules) - **Asynchronous Processing**: Celery support for heavy validations (VeraPDF) ### 📡 AFNOR PDP/PA Integration (XP Z12-013) - **Flow Submission**: Send invoices to Partner Dematerialization Platforms - **Flow Search**: View submitted invoices - **Download**: Retrieve PDF/A-3 with XML - **Directory Service**: Company search (SIREN/SIRET) - **Multi-client**: Support for multiple PDP configs per user (stored credentials or zero-storage) ### ✍️ PDF Electronic Signature - **Standards**: PAdES-B-B, PAdES-B-T (RFC 3161 timestamping), PAdES-B-LT (long-term archival) - **eIDAS Levels**: SES (self-signed), AdES (commercial CA), QES (QTSP) - **Validation**: Cryptographic integrity and certificate verification - **Certificate Generation**: Self-signed X.509 certificates for testing ### 🔄 Asynchronous Processing - **Celery**: Asynchronous generation, validation and signing - **Polling**: Status tracking via `/tasks/{task_id}/status` - **No timeout**: Ideal for large files or heavy validations ## 🔒 Authentication All requests require a **JWT token** in the Authorization header: ``` Authorization: Bearer YOUR_JWT_TOKEN ``` ### How to obtain a JWT token? #### 🔑 Method 1: `/api/token/` API (Recommended) **URL:** `https://factpulse.fr/api/token/` This method is **recommended** for integration in your applications and CI/CD workflows. **Prerequisites:** Having set a password on your account **For users registered via email/password:** - You already have a password, use it directly **For users registered via OAuth (Google/GitHub):** - You must first set a password at: https://factpulse.fr/accounts/password/set/ - Once the password is created, you can use the API **Request example:** ```bash curl -X POST https://factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\" }' ``` **Optional `client_uid` parameter:** To select credentials for a specific client (PA/PDP, Chorus Pro, signing certificates), add `client_uid`: ```bash curl -X POST https://factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\", \"client_uid\": \"550e8400-e29b-41d4-a716-446655440000\" }' ``` The `client_uid` will be included in the JWT and allow the API to automatically use: - AFNOR/PDP credentials configured for this client - Chorus Pro credentials configured for this client - Electronic signature certificates configured for this client **Response:** ```json { \"access\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\", // Access token (validity: 30 min) \"refresh\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\" // Refresh token (validity: 7 days) } ``` **Advantages:** - ✅ Full automation (CI/CD, scripts) - ✅ Programmatic token management - ✅ Refresh token support for automatic access renewal - ✅ Easy integration in any language/tool #### 🖥️ Method 2: Dashboard Generation (Alternative) **URL:** https://factpulse.fr/api/dashboard/ This method is suitable for quick tests or occasional use via the graphical interface. **How it works:** - Log in to the dashboard - Use the \"Generate Test Token\" or \"Generate Production Token\" buttons - Works for **all** users (OAuth and email/password), without requiring a password **Token types:** - **Test Token**: 24h validity, 1000 calls/day quota (free) - **Production Token**: 7 days validity, quota based on your plan **Advantages:** - ✅ Quick for API testing - ✅ No password required - ✅ Simple visual interface **Disadvantages:** - ❌ Requires manual action - ❌ No refresh token - ❌ Less suited for automation ### 📚 Full Documentation For more information on authentication and API usage: https://factpulse.fr/documentation-api/
5
5
 
6
6
  The version of the OpenAPI document: 1.0.0
7
-
7
+ Contact: contact@factpulse.fr
8
8
  Generated by: https://openapi-generator.tech
9
9
  Generator version: 7.19.0-SNAPSHOT
10
10
 
@@ -21,7 +21,7 @@ module FactPulse
21
21
  end
22
22
  # Get status of an asynchronous verification
23
23
  # Retrieves the status and result of an asynchronous verification task. **Possible statuses:** - `PENDING`: Task waiting in queue - `STARTED`: Task currently running - `SUCCESS`: Task completed successfully (see `result`) - `FAILURE`: System error (unhandled exception) **Note:** The `result.status` field can be \"SUCCESS\" or \"ERROR\" independently of Celery status (which will always be SUCCESS if the task ran).
24
- # @param task_id [String]
24
+ # @param task_id [String] Celery task ID returned by /verify-async endpoint
25
25
  # @param [Hash] opts the optional parameters
26
26
  # @return [AsyncTaskStatus]
27
27
  def get_verification_status_api_v1_verification_verify_async_task_id_status_get(task_id, opts = {})
@@ -31,7 +31,7 @@ module FactPulse
31
31
 
32
32
  # Get status of an asynchronous verification
33
33
  # Retrieves the status and result of an asynchronous verification task. **Possible statuses:** - &#x60;PENDING&#x60;: Task waiting in queue - &#x60;STARTED&#x60;: Task currently running - &#x60;SUCCESS&#x60;: Task completed successfully (see &#x60;result&#x60;) - &#x60;FAILURE&#x60;: System error (unhandled exception) **Note:** The &#x60;result.status&#x60; field can be \&quot;SUCCESS\&quot; or \&quot;ERROR\&quot; independently of Celery status (which will always be SUCCESS if the task ran).
34
- # @param task_id [String]
34
+ # @param task_id [String] Celery task ID returned by /verify-async endpoint
35
35
  # @param [Hash] opts the optional parameters
36
36
  # @return [Array<(AsyncTaskStatus, Integer, Hash)>] AsyncTaskStatus data, response status code and response headers
37
37
  def get_verification_status_api_v1_verification_verify_async_task_id_status_get_with_http_info(task_id, opts = {})
@@ -84,7 +84,7 @@ module FactPulse
84
84
 
85
85
  # Get status of an asynchronous verification
86
86
  # Retrieves the status and result of an asynchronous verification task. **Possible statuses:** - `PENDING`: Task waiting in queue - `STARTED`: Task currently running - `SUCCESS`: Task completed successfully (see `result`) - `FAILURE`: System error (unhandled exception) **Note:** The `result.status` field can be \"SUCCESS\" or \"ERROR\" independently of Celery status (which will always be SUCCESS if the task ran).
87
- # @param task_id [String]
87
+ # @param task_id [String] Celery task ID returned by /verify-async endpoint
88
88
  # @param [Hash] opts the optional parameters
89
89
  # @return [AsyncTaskStatus]
90
90
  def get_verification_status_api_v1_verification_verify_async_task_id_status_get_0(task_id, opts = {})
@@ -94,7 +94,7 @@ module FactPulse
94
94
 
95
95
  # Get status of an asynchronous verification
96
96
  # Retrieves the status and result of an asynchronous verification task. **Possible statuses:** - &#x60;PENDING&#x60;: Task waiting in queue - &#x60;STARTED&#x60;: Task currently running - &#x60;SUCCESS&#x60;: Task completed successfully (see &#x60;result&#x60;) - &#x60;FAILURE&#x60;: System error (unhandled exception) **Note:** The &#x60;result.status&#x60; field can be \&quot;SUCCESS\&quot; or \&quot;ERROR\&quot; independently of Celery status (which will always be SUCCESS if the task ran).
97
- # @param task_id [String]
97
+ # @param task_id [String] Celery task ID returned by /verify-async endpoint
98
98
  # @param [Hash] opts the optional parameters
99
99
  # @return [Array<(AsyncTaskStatus, Integer, Hash)>] AsyncTaskStatus data, response status code and response headers
100
100
  def get_verification_status_api_v1_verification_verify_async_task_id_status_get_0_with_http_info(task_id, opts = {})
@@ -146,10 +146,12 @@ module FactPulse
146
146
  end
147
147
 
148
148
  # Verify PDF/XML Factur-X compliance (asynchronous)
149
- # Verifies PDF/XML Factur-X compliance asynchronously. **IMPORTANT**: Only Factur-X PDFs (with embedded XML) are accepted. PDFs without Factur-X XML will return a `NOT_FACTURX` error in the result. This version uses a Celery task and can call the OCR service if the PDF is an image or if `force_ocr=true`. **Returns immediately** a task ID. Use `/verify-async/{task_id}/status` to retrieve the result. **Verification principle (Factur-X 1.08):** - Principle #2: XML can only contain info present in the PDF - Principle #4: All XML info must be present and compliant in the PDF **Verified fields:** - Identification: BT-1 (invoice #), BT-2 (date), BT-3 (type), BT-5 (currency), BT-23 (framework) - Seller: BT-27 (name), BT-29 (SIRET), BT-30 (SIREN), BT-31 (VAT) - Buyer: BT-44 (name), BT-46 (SIRET), BT-47 (SIREN), BT-48 (VAT) - Amounts: BT-109 (excl. tax), BT-110 (VAT), BT-112 (incl. tax), BT-115 (amount due) - VAT breakdown: BT-116, BT-117, BT-118, BT-119 - Invoice lines: BT-153, BT-129, BT-146, BT-131 - Mandatory notes: PMT, PMD, AAB - Rule BR-FR-09: SIRET/SIREN consistency **Advantages over synchronous version:** - OCR support for image PDFs (via DocTR service) - Longer timeout for large documents - Doesn't block the server
149
+ # Verifies PDF/XML Factur-X compliance asynchronously. **IMPORTANT**: Only Factur-X PDFs (with embedded XML) are accepted. PDFs without Factur-X XML will return a `NOT_FACTURX` error in the result. This version uses a Celery task and can call the OCR service if the PDF is an image or if `force_ocr=true`. **Returns immediately** a task ID. Use `/verify-async/{task_id}/status` to retrieve the result. **Verification principle (Factur-X 1.08):** - Principle #2: XML can only contain info present in the PDF - Principle #4: All XML info must be present and compliant in the PDF **Verified fields:** - Identification: BT-1 (invoice #), BT-2 (date), BT-3 (type), BT-5 (currency), BT-23 (framework) - Seller: BT-27 (name), BT-29 (SIRET), BT-30 (SIREN), BT-31 (VAT) - Buyer: BT-44 (name), BT-46 (SIRET), BT-47 (SIREN), BT-48 (VAT) - Amounts: BT-109 (excl. tax), BT-110 (VAT), BT-112 (incl. tax), BT-115 (amount due) - VAT breakdown: BT-116, BT-117, BT-118, BT-119 - Invoice lines: BT-153, BT-129, BT-146, BT-131 - Mandatory notes: PMT, PMD, AAB - Rule BR-FR-09: SIRET/SIREN consistency **Advantages over synchronous version:** - OCR support for image PDFs (via DocTR service) - Longer timeout for large documents - Doesn't block the server ## Webhook notification (recommended) Instead of polling, you can receive a webhook notification when verification completes: ``` callback_url=https://your-server.com/webhook ``` The webhook will POST a JSON payload with: - `event_type`: `verification.completed` or `verification.failed` - `data.is_compliant`: Whether the PDF/XML are consistent - `data.compliance_score`: Compliance score (0-1) - `X-Webhook-Signature` header for HMAC verification
150
150
  # @param pdf_file [File] Factur-X PDF file to verify
151
151
  # @param [Hash] opts the optional parameters
152
152
  # @option opts [Boolean] :force_ocr Force OCR usage even if PDF contains native text (default to false)
153
+ # @option opts [String] :callback_url
154
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
153
155
  # @return [TaskResponse]
154
156
  def verify_pdf_async_api_v1_verification_verify_async_post(pdf_file, opts = {})
155
157
  data, _status_code, _headers = verify_pdf_async_api_v1_verification_verify_async_post_with_http_info(pdf_file, opts)
@@ -157,10 +159,12 @@ module FactPulse
157
159
  end
158
160
 
159
161
  # Verify PDF/XML Factur-X compliance (asynchronous)
160
- # Verifies PDF/XML Factur-X compliance asynchronously. **IMPORTANT**: Only Factur-X PDFs (with embedded XML) are accepted. PDFs without Factur-X XML will return a &#x60;NOT_FACTURX&#x60; error in the result. This version uses a Celery task and can call the OCR service if the PDF is an image or if &#x60;force_ocr&#x3D;true&#x60;. **Returns immediately** a task ID. Use &#x60;/verify-async/{task_id}/status&#x60; to retrieve the result. **Verification principle (Factur-X 1.08):** - Principle #2: XML can only contain info present in the PDF - Principle #4: All XML info must be present and compliant in the PDF **Verified fields:** - Identification: BT-1 (invoice #), BT-2 (date), BT-3 (type), BT-5 (currency), BT-23 (framework) - Seller: BT-27 (name), BT-29 (SIRET), BT-30 (SIREN), BT-31 (VAT) - Buyer: BT-44 (name), BT-46 (SIRET), BT-47 (SIREN), BT-48 (VAT) - Amounts: BT-109 (excl. tax), BT-110 (VAT), BT-112 (incl. tax), BT-115 (amount due) - VAT breakdown: BT-116, BT-117, BT-118, BT-119 - Invoice lines: BT-153, BT-129, BT-146, BT-131 - Mandatory notes: PMT, PMD, AAB - Rule BR-FR-09: SIRET/SIREN consistency **Advantages over synchronous version:** - OCR support for image PDFs (via DocTR service) - Longer timeout for large documents - Doesn&#39;t block the server
162
+ # Verifies PDF/XML Factur-X compliance asynchronously. **IMPORTANT**: Only Factur-X PDFs (with embedded XML) are accepted. PDFs without Factur-X XML will return a &#x60;NOT_FACTURX&#x60; error in the result. This version uses a Celery task and can call the OCR service if the PDF is an image or if &#x60;force_ocr&#x3D;true&#x60;. **Returns immediately** a task ID. Use &#x60;/verify-async/{task_id}/status&#x60; to retrieve the result. **Verification principle (Factur-X 1.08):** - Principle #2: XML can only contain info present in the PDF - Principle #4: All XML info must be present and compliant in the PDF **Verified fields:** - Identification: BT-1 (invoice #), BT-2 (date), BT-3 (type), BT-5 (currency), BT-23 (framework) - Seller: BT-27 (name), BT-29 (SIRET), BT-30 (SIREN), BT-31 (VAT) - Buyer: BT-44 (name), BT-46 (SIRET), BT-47 (SIREN), BT-48 (VAT) - Amounts: BT-109 (excl. tax), BT-110 (VAT), BT-112 (incl. tax), BT-115 (amount due) - VAT breakdown: BT-116, BT-117, BT-118, BT-119 - Invoice lines: BT-153, BT-129, BT-146, BT-131 - Mandatory notes: PMT, PMD, AAB - Rule BR-FR-09: SIRET/SIREN consistency **Advantages over synchronous version:** - OCR support for image PDFs (via DocTR service) - Longer timeout for large documents - Doesn&#39;t block the server ## Webhook notification (recommended) Instead of polling, you can receive a webhook notification when verification completes: &#x60;&#x60;&#x60; callback_url&#x3D;https://your-server.com/webhook &#x60;&#x60;&#x60; The webhook will POST a JSON payload with: - &#x60;event_type&#x60;: &#x60;verification.completed&#x60; or &#x60;verification.failed&#x60; - &#x60;data.is_compliant&#x60;: Whether the PDF/XML are consistent - &#x60;data.compliance_score&#x60;: Compliance score (0-1) - &#x60;X-Webhook-Signature&#x60; header for HMAC verification
161
163
  # @param pdf_file [File] Factur-X PDF file to verify
162
164
  # @param [Hash] opts the optional parameters
163
165
  # @option opts [Boolean] :force_ocr Force OCR usage even if PDF contains native text (default to false)
166
+ # @option opts [String] :callback_url
167
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
164
168
  # @return [Array<(TaskResponse, Integer, Hash)>] TaskResponse data, response status code and response headers
165
169
  def verify_pdf_async_api_v1_verification_verify_async_post_with_http_info(pdf_file, opts = {})
166
170
  if @api_client.config.debugging
@@ -190,6 +194,8 @@ module FactPulse
190
194
  form_params = opts[:form_params] || {}
191
195
  form_params['pdf_file'] = pdf_file
192
196
  form_params['force_ocr'] = opts[:'force_ocr'] if !opts[:'force_ocr'].nil?
197
+ form_params['callback_url'] = opts[:'callback_url'] if !opts[:'callback_url'].nil?
198
+ form_params['webhook_mode'] = opts[:'webhook_mode'] if !opts[:'webhook_mode'].nil?
193
199
 
194
200
  # http body (model)
195
201
  post_body = opts[:debug_body]
@@ -218,10 +224,12 @@ module FactPulse
218
224
  end
219
225
 
220
226
  # Verify PDF/XML Factur-X compliance (asynchronous)
221
- # Verifies PDF/XML Factur-X compliance asynchronously. **IMPORTANT**: Only Factur-X PDFs (with embedded XML) are accepted. PDFs without Factur-X XML will return a `NOT_FACTURX` error in the result. This version uses a Celery task and can call the OCR service if the PDF is an image or if `force_ocr=true`. **Returns immediately** a task ID. Use `/verify-async/{task_id}/status` to retrieve the result. **Verification principle (Factur-X 1.08):** - Principle #2: XML can only contain info present in the PDF - Principle #4: All XML info must be present and compliant in the PDF **Verified fields:** - Identification: BT-1 (invoice #), BT-2 (date), BT-3 (type), BT-5 (currency), BT-23 (framework) - Seller: BT-27 (name), BT-29 (SIRET), BT-30 (SIREN), BT-31 (VAT) - Buyer: BT-44 (name), BT-46 (SIRET), BT-47 (SIREN), BT-48 (VAT) - Amounts: BT-109 (excl. tax), BT-110 (VAT), BT-112 (incl. tax), BT-115 (amount due) - VAT breakdown: BT-116, BT-117, BT-118, BT-119 - Invoice lines: BT-153, BT-129, BT-146, BT-131 - Mandatory notes: PMT, PMD, AAB - Rule BR-FR-09: SIRET/SIREN consistency **Advantages over synchronous version:** - OCR support for image PDFs (via DocTR service) - Longer timeout for large documents - Doesn't block the server
227
+ # Verifies PDF/XML Factur-X compliance asynchronously. **IMPORTANT**: Only Factur-X PDFs (with embedded XML) are accepted. PDFs without Factur-X XML will return a `NOT_FACTURX` error in the result. This version uses a Celery task and can call the OCR service if the PDF is an image or if `force_ocr=true`. **Returns immediately** a task ID. Use `/verify-async/{task_id}/status` to retrieve the result. **Verification principle (Factur-X 1.08):** - Principle #2: XML can only contain info present in the PDF - Principle #4: All XML info must be present and compliant in the PDF **Verified fields:** - Identification: BT-1 (invoice #), BT-2 (date), BT-3 (type), BT-5 (currency), BT-23 (framework) - Seller: BT-27 (name), BT-29 (SIRET), BT-30 (SIREN), BT-31 (VAT) - Buyer: BT-44 (name), BT-46 (SIRET), BT-47 (SIREN), BT-48 (VAT) - Amounts: BT-109 (excl. tax), BT-110 (VAT), BT-112 (incl. tax), BT-115 (amount due) - VAT breakdown: BT-116, BT-117, BT-118, BT-119 - Invoice lines: BT-153, BT-129, BT-146, BT-131 - Mandatory notes: PMT, PMD, AAB - Rule BR-FR-09: SIRET/SIREN consistency **Advantages over synchronous version:** - OCR support for image PDFs (via DocTR service) - Longer timeout for large documents - Doesn't block the server ## Webhook notification (recommended) Instead of polling, you can receive a webhook notification when verification completes: ``` callback_url=https://your-server.com/webhook ``` The webhook will POST a JSON payload with: - `event_type`: `verification.completed` or `verification.failed` - `data.is_compliant`: Whether the PDF/XML are consistent - `data.compliance_score`: Compliance score (0-1) - `X-Webhook-Signature` header for HMAC verification
222
228
  # @param pdf_file [File] Factur-X PDF file to verify
223
229
  # @param [Hash] opts the optional parameters
224
230
  # @option opts [Boolean] :force_ocr Force OCR usage even if PDF contains native text (default to false)
231
+ # @option opts [String] :callback_url
232
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
225
233
  # @return [TaskResponse]
226
234
  def verify_pdf_async_api_v1_verification_verify_async_post_0(pdf_file, opts = {})
227
235
  data, _status_code, _headers = verify_pdf_async_api_v1_verification_verify_async_post_0_with_http_info(pdf_file, opts)
@@ -229,10 +237,12 @@ module FactPulse
229
237
  end
230
238
 
231
239
  # Verify PDF/XML Factur-X compliance (asynchronous)
232
- # Verifies PDF/XML Factur-X compliance asynchronously. **IMPORTANT**: Only Factur-X PDFs (with embedded XML) are accepted. PDFs without Factur-X XML will return a &#x60;NOT_FACTURX&#x60; error in the result. This version uses a Celery task and can call the OCR service if the PDF is an image or if &#x60;force_ocr&#x3D;true&#x60;. **Returns immediately** a task ID. Use &#x60;/verify-async/{task_id}/status&#x60; to retrieve the result. **Verification principle (Factur-X 1.08):** - Principle #2: XML can only contain info present in the PDF - Principle #4: All XML info must be present and compliant in the PDF **Verified fields:** - Identification: BT-1 (invoice #), BT-2 (date), BT-3 (type), BT-5 (currency), BT-23 (framework) - Seller: BT-27 (name), BT-29 (SIRET), BT-30 (SIREN), BT-31 (VAT) - Buyer: BT-44 (name), BT-46 (SIRET), BT-47 (SIREN), BT-48 (VAT) - Amounts: BT-109 (excl. tax), BT-110 (VAT), BT-112 (incl. tax), BT-115 (amount due) - VAT breakdown: BT-116, BT-117, BT-118, BT-119 - Invoice lines: BT-153, BT-129, BT-146, BT-131 - Mandatory notes: PMT, PMD, AAB - Rule BR-FR-09: SIRET/SIREN consistency **Advantages over synchronous version:** - OCR support for image PDFs (via DocTR service) - Longer timeout for large documents - Doesn&#39;t block the server
240
+ # Verifies PDF/XML Factur-X compliance asynchronously. **IMPORTANT**: Only Factur-X PDFs (with embedded XML) are accepted. PDFs without Factur-X XML will return a &#x60;NOT_FACTURX&#x60; error in the result. This version uses a Celery task and can call the OCR service if the PDF is an image or if &#x60;force_ocr&#x3D;true&#x60;. **Returns immediately** a task ID. Use &#x60;/verify-async/{task_id}/status&#x60; to retrieve the result. **Verification principle (Factur-X 1.08):** - Principle #2: XML can only contain info present in the PDF - Principle #4: All XML info must be present and compliant in the PDF **Verified fields:** - Identification: BT-1 (invoice #), BT-2 (date), BT-3 (type), BT-5 (currency), BT-23 (framework) - Seller: BT-27 (name), BT-29 (SIRET), BT-30 (SIREN), BT-31 (VAT) - Buyer: BT-44 (name), BT-46 (SIRET), BT-47 (SIREN), BT-48 (VAT) - Amounts: BT-109 (excl. tax), BT-110 (VAT), BT-112 (incl. tax), BT-115 (amount due) - VAT breakdown: BT-116, BT-117, BT-118, BT-119 - Invoice lines: BT-153, BT-129, BT-146, BT-131 - Mandatory notes: PMT, PMD, AAB - Rule BR-FR-09: SIRET/SIREN consistency **Advantages over synchronous version:** - OCR support for image PDFs (via DocTR service) - Longer timeout for large documents - Doesn&#39;t block the server ## Webhook notification (recommended) Instead of polling, you can receive a webhook notification when verification completes: &#x60;&#x60;&#x60; callback_url&#x3D;https://your-server.com/webhook &#x60;&#x60;&#x60; The webhook will POST a JSON payload with: - &#x60;event_type&#x60;: &#x60;verification.completed&#x60; or &#x60;verification.failed&#x60; - &#x60;data.is_compliant&#x60;: Whether the PDF/XML are consistent - &#x60;data.compliance_score&#x60;: Compliance score (0-1) - &#x60;X-Webhook-Signature&#x60; header for HMAC verification
233
241
  # @param pdf_file [File] Factur-X PDF file to verify
234
242
  # @param [Hash] opts the optional parameters
235
243
  # @option opts [Boolean] :force_ocr Force OCR usage even if PDF contains native text (default to false)
244
+ # @option opts [String] :callback_url
245
+ # @option opts [String] :webhook_mode Webhook content delivery: &#39;inline&#39; (base64 in payload) or &#39;download_url&#39; (temporary URL, 1h TTL) (default to 'inline')
236
246
  # @return [Array<(TaskResponse, Integer, Hash)>] TaskResponse data, response status code and response headers
237
247
  def verify_pdf_async_api_v1_verification_verify_async_post_0_with_http_info(pdf_file, opts = {})
238
248
  if @api_client.config.debugging
@@ -262,6 +272,8 @@ module FactPulse
262
272
  form_params = opts[:form_params] || {}
263
273
  form_params['pdf_file'] = pdf_file
264
274
  form_params['force_ocr'] = opts[:'force_ocr'] if !opts[:'force_ocr'].nil?
275
+ form_params['callback_url'] = opts[:'callback_url'] if !opts[:'callback_url'].nil?
276
+ form_params['webhook_mode'] = opts[:'webhook_mode'] if !opts[:'webhook_mode'].nil?
265
277
 
266
278
  # http body (model)
267
279
  post_body = opts[:debug_body]
@@ -1,10 +1,10 @@
1
1
  =begin
2
2
  #FactPulse REST API
3
3
 
4
- # REST API for electronic invoicing in France: Factur-X, AFNOR PDP/PA, electronic signatures. ## 🎯 Main Features ### 📄 Factur-X Invoice Generation - **Formats**: XML only or PDF/A-3 with embedded XML - **Profiles**: MINIMUM, BASIC, EN16931, EXTENDED - **Standards**: EN 16931 (EU directive 2014/55), ISO 19005-3 (PDF/A-3), CII (UN/CEFACT) - **🆕 Simplified Format**: Generation from SIRET + auto-enrichment (Chorus Pro API + Business Search) ### ✅ Validation and Compliance - **XML Validation**: Schematron (45 to 210+ rules depending on profile) - **PDF Validation**: PDF/A-3, Factur-X XMP metadata, electronic signatures - **VeraPDF**: Strict PDF/A validation (146+ ISO 19005-3 rules) - **Asynchronous Processing**: Celery support for heavy validations (VeraPDF) ### 📡 AFNOR PDP/PA Integration (XP Z12-013) - **Flow Submission**: Send invoices to Partner Dematerialization Platforms - **Flow Search**: View submitted invoices - **Download**: Retrieve PDF/A-3 with XML - **Directory Service**: Company search (SIREN/SIRET) - **Multi-client**: Support for multiple PDP configs per user (stored credentials or zero-storage) ### ✍️ PDF Electronic Signature - **Standards**: PAdES-B-B, PAdES-B-T (RFC 3161 timestamping), PAdES-B-LT (long-term archival) - **eIDAS Levels**: SES (self-signed), AdES (commercial CA), QES (QTSP) - **Validation**: Cryptographic integrity and certificate verification - **Certificate Generation**: Self-signed X.509 certificates for testing ### 🔄 Asynchronous Processing - **Celery**: Asynchronous generation, validation and signing - **Polling**: Status tracking via `/tasks/{task_id}/status` - **No timeout**: Ideal for large files or heavy validations ## 🔒 Authentication All requests require a **JWT token** in the Authorization header: ``` Authorization: Bearer YOUR_JWT_TOKEN ``` ### How to obtain a JWT token? #### 🔑 Method 1: `/api/token/` API (Recommended) **URL:** `https://www.factpulse.fr/api/token/` This method is **recommended** for integration in your applications and CI/CD workflows. **Prerequisites:** Having set a password on your account **For users registered via email/password:** - You already have a password, use it directly **For users registered via OAuth (Google/GitHub):** - You must first set a password at: https://www.factpulse.fr/accounts/password/set/ - Once the password is created, you can use the API **Request example:** ```bash curl -X POST https://www.factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\" }' ``` **Optional `client_uid` parameter:** To select credentials for a specific client (PA/PDP, Chorus Pro, signing certificates), add `client_uid`: ```bash curl -X POST https://www.factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\", \"client_uid\": \"550e8400-e29b-41d4-a716-446655440000\" }' ``` The `client_uid` will be included in the JWT and allow the API to automatically use: - AFNOR/PDP credentials configured for this client - Chorus Pro credentials configured for this client - Electronic signature certificates configured for this client **Response:** ```json { \"access\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\", // Access token (validity: 30 min) \"refresh\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\" // Refresh token (validity: 7 days) } ``` **Advantages:** - ✅ Full automation (CI/CD, scripts) - ✅ Programmatic token management - ✅ Refresh token support for automatic access renewal - ✅ Easy integration in any language/tool #### 🖥️ Method 2: Dashboard Generation (Alternative) **URL:** https://www.factpulse.fr/dashboard/ This method is suitable for quick tests or occasional use via the graphical interface. **How it works:** - Log in to the dashboard - Use the \"Generate Test Token\" or \"Generate Production Token\" buttons - Works for **all** users (OAuth and email/password), without requiring a password **Token types:** - **Test Token**: 24h validity, 1000 calls/day quota (free) - **Production Token**: 7 days validity, quota based on your plan **Advantages:** - ✅ Quick for API testing - ✅ No password required - ✅ Simple visual interface **Disadvantages:** - ❌ Requires manual action - ❌ No refresh token - ❌ Less suited for automation ### 📚 Full Documentation For more information on authentication and API usage: https://www.factpulse.fr/documentation-api/
4
+ # REST API for electronic invoicing in France: Factur-X, AFNOR PDP/PA, electronic signatures. ## 🎯 Main Features ### 📄 Factur-X Invoice Generation - **Formats**: XML only or PDF/A-3 with embedded XML - **Profiles**: MINIMUM, BASIC, EN16931, EXTENDED - **Standards**: EN 16931 (EU directive 2014/55), ISO 19005-3 (PDF/A-3), CII (UN/CEFACT) - **🆕 Simplified Format**: Generation from SIRET + auto-enrichment (Chorus Pro API + Business Search) ### ✅ Validation and Compliance - **XML Validation**: Schematron (45 to 210+ rules depending on profile) - **PDF Validation**: PDF/A-3, Factur-X XMP metadata, electronic signatures - **VeraPDF**: Strict PDF/A validation (146+ ISO 19005-3 rules) - **Asynchronous Processing**: Celery support for heavy validations (VeraPDF) ### 📡 AFNOR PDP/PA Integration (XP Z12-013) - **Flow Submission**: Send invoices to Partner Dematerialization Platforms - **Flow Search**: View submitted invoices - **Download**: Retrieve PDF/A-3 with XML - **Directory Service**: Company search (SIREN/SIRET) - **Multi-client**: Support for multiple PDP configs per user (stored credentials or zero-storage) ### ✍️ PDF Electronic Signature - **Standards**: PAdES-B-B, PAdES-B-T (RFC 3161 timestamping), PAdES-B-LT (long-term archival) - **eIDAS Levels**: SES (self-signed), AdES (commercial CA), QES (QTSP) - **Validation**: Cryptographic integrity and certificate verification - **Certificate Generation**: Self-signed X.509 certificates for testing ### 🔄 Asynchronous Processing - **Celery**: Asynchronous generation, validation and signing - **Polling**: Status tracking via `/tasks/{task_id}/status` - **No timeout**: Ideal for large files or heavy validations ## 🔒 Authentication All requests require a **JWT token** in the Authorization header: ``` Authorization: Bearer YOUR_JWT_TOKEN ``` ### How to obtain a JWT token? #### 🔑 Method 1: `/api/token/` API (Recommended) **URL:** `https://factpulse.fr/api/token/` This method is **recommended** for integration in your applications and CI/CD workflows. **Prerequisites:** Having set a password on your account **For users registered via email/password:** - You already have a password, use it directly **For users registered via OAuth (Google/GitHub):** - You must first set a password at: https://factpulse.fr/accounts/password/set/ - Once the password is created, you can use the API **Request example:** ```bash curl -X POST https://factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\" }' ``` **Optional `client_uid` parameter:** To select credentials for a specific client (PA/PDP, Chorus Pro, signing certificates), add `client_uid`: ```bash curl -X POST https://factpulse.fr/api/token/ \\ -H \"Content-Type: application/json\" \\ -d '{ \"username\": \"your_email@example.com\", \"password\": \"your_password\", \"client_uid\": \"550e8400-e29b-41d4-a716-446655440000\" }' ``` The `client_uid` will be included in the JWT and allow the API to automatically use: - AFNOR/PDP credentials configured for this client - Chorus Pro credentials configured for this client - Electronic signature certificates configured for this client **Response:** ```json { \"access\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\", // Access token (validity: 30 min) \"refresh\": \"eyJ0eXAiOiJKV1QiLCJhbGc...\" // Refresh token (validity: 7 days) } ``` **Advantages:** - ✅ Full automation (CI/CD, scripts) - ✅ Programmatic token management - ✅ Refresh token support for automatic access renewal - ✅ Easy integration in any language/tool #### 🖥️ Method 2: Dashboard Generation (Alternative) **URL:** https://factpulse.fr/api/dashboard/ This method is suitable for quick tests or occasional use via the graphical interface. **How it works:** - Log in to the dashboard - Use the \"Generate Test Token\" or \"Generate Production Token\" buttons - Works for **all** users (OAuth and email/password), without requiring a password **Token types:** - **Test Token**: 24h validity, 1000 calls/day quota (free) - **Production Token**: 7 days validity, quota based on your plan **Advantages:** - ✅ Quick for API testing - ✅ No password required - ✅ Simple visual interface **Disadvantages:** - ❌ Requires manual action - ❌ No refresh token - ❌ Less suited for automation ### 📚 Full Documentation For more information on authentication and API usage: https://factpulse.fr/documentation-api/
5
5
 
6
6
  The version of the OpenAPI document: 1.0.0
7
-
7
+ Contact: contact@factpulse.fr
8
8
  Generated by: https://openapi-generator.tech
9
9
  Generator version: 7.19.0-SNAPSHOT
10
10