Submit Authorisation Codes V2

When using Bud as a TSP (Technical Service Provider) and doing full app-to-app authorisation, the customer is returned from the provider directly back to your app. Your app will then need to send all the query and hash fragment parameters to Bud so that we can complete the connection.

Query and fragment parameters should be merged with query taking precedence. If you receive a request /path?a=1#a=2&b=3 then you should perform this request with {"a":"1","b":"3"}. Given the nature of the fragment queries most server side languages will not process these so javascript may be required to correctly gather both parameters.

Regardless of what parameters are present, all of them should be sent to Bud so that we can choose to either continue the connection or to map and record the error.

Code and error are shown here only because they are the most common parameters you will see, but this object could contain any number of unspecified properties. Currently state is a common property among all authorisation flows and is the current task ID. The state property is not guaranteed for the future of this API contract and will not be treated as backwards incompatible if a new authentication flow does not use it.

This endpoint triggers an asynchronous collection of OpenBanking data within the Bud platform. Therefore after calling this endpoint the Retrieve Connection Status endpoint should be called to retrieve the status of the collection