A successful request is a good start, but an API Verifactu needs validation within your application's complete process. Your test plan should cover submitted data, responses and how the team will resolve an incident. Write down the expected outcome before running each case.
Separate the environment and credentials
Confirm the URL, credentials and scope of your test environment with the provider. AEAT has an external testing portal, but it should not be confused with an API provider's environment. At API VeriFactu you can request a test business and an API Key through the form; the team handles delivery of access.
Design cases that represent your business
Select the operations your software uses and prepare consistent fictitious data. For each case, record the request, expected response and final check in your application. Use the documentation and Postman collections as a starting point, adapting the data to your scenario. Avoid turning a technical test into a real issuance by using the wrong configuration.
- Valid authentication and incorrect credentials.
- A complete document and a rejected validation.
- A status query after submitting an operation.
- A network interruption with an initially unknown outcome.
- A repeated notification if you use webhooks.
Check recovery as well as submission
Simulate your application losing the response after a request. Before resubmitting, it should be able to find stored references and query whatever the API supports. Also check that an incident appears on the appropriate screen, rather than remaining hidden in a technical log that nobody reviews.
Prepare a controlled production launch
Define who approves the results, who changes configuration and how the first operations will be monitored. Keep the tests as regression coverage for future updates. Moving to production should include a review of permissions, credentials, backups and incident handling, as well as technical confirmation from the provider.