Once you've gone live is an unfortunate time to discover you've not properly written your code to handle every possible error type, including those that should "never" happen. Be certain your code is defensive, handling not just the common errors, but all possibilities.

Account for different error types that may be thrown by Fiskil APIs and ensure each edge case is handled.

Sometimes, Fiskil API calls may fail due to intermittent outages or connectivity errors at supported institutions. Implement retry logic or error handling as necessary for product API calls.

Storage and Logging

Log Fiskil identifiers and IDs properly to enhance security, when contacting Support about a specific request or webhook these will be required.

Ensure that the following identifiers are securely logged, as they will be needed when contacting Support about a specific request or webhook.

end_user_id included in most requests to identify the end users whose data is being accessed.

consent_id The consent identifier associated with each data sharing consent

session_id The session identifier associated with every consent created or attempted to be created.

error_id included in all errors returned to uniquely identify the error reported.

End User Management

Delete end users that are no longer using the product or recieving a service from your product.

Product-specific recommendation - Transaction API

If fetching historical Transactions data, make sure your app implements pagination logic.

The Transaction API natively supports the categorisation of transactions through the categories object. For a comprehensive understanding of the classification system, you can download our Categories Taxonomy CSV, which provides detailed information on all category types, subtypes, and their hierarchical relationships supported by Fiskil.

Was this page helpful?