Webhooks let your application receive service notifications without relying solely on periodic queries. In an API Verifactu, design them as part of operation tracking: receive an event, identify its document and decide which update is appropriate. The receiver also needs a plan for repeated or unexpected events.
Start with the available event types
Our API reference includes operations to query webhook types, configure a URL and inspect registered webhooks. Review these before designing your receiver. Confirm the precise notification format and authentication mechanism with the team; do not invent a signature, header or delivery guarantee that the contract does not specify.
Link each notification to an operation
Keep identifiers returned by submissions and use them to associate results with your local document. The documentation includes queries for submissions identified by queueId. Keep this technical reference separate from the commercial invoice number to avoid ambiguous relationships, particularly when managing multiple businesses.
Make repeated notifications safe
Design state updates so processing the same event twice does not duplicate actions. Check persisted status before triggering emails or follow-up tasks. Do not assume notifications arrive in the order your interface expects; when uncertain, compare the information with available queries and avoid overwriting a known result with an older one.
- Validate authentication and the incoming structure.
- Check which business and document the event belongs to.
- Record a useful reference for investigating incidents.
- Test duplicates, delays and temporary receiver errors.
Keep a reconciliation path
A webhook does not remove the need to review operations whose local status became outdated. Define reconciliation that respects service limits and an incident queue for the team. This allows tracking to recover after an interruption without repeated submissions or untraceable manual changes.