-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathmodel_account_interface.go
263 lines (222 loc) · 18.9 KB
/
model_account_interface.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
/*
* finAPI Access (with deprecation)
*
* <strong>RESTful API for Account Information Services (AIS) and Payment Initiation Services (PIS)</strong> The following pages give you some general information on how to use our APIs.<br/> The actual API services documentation then follows further below. You can use the menu to jump between API sections. <br/> <br/> This page has a built-in HTTP(S) client, so you can test the services directly from within this page, by filling in the request parameters and/or body in the respective services, and then hitting the TRY button. Note that you need to be authorized to make a successful API call. To authorize, refer to the 'Authorization' section of the API, or just use the OAUTH button that can be found near the TRY button. <br/> <h2 id=\"general-information\">General information</h2> <h3 id=\"general-error-responses\"><strong>Error Responses</strong></h3> When an API call returns with an error, then in general it has the structure shown in the following example: <pre> { \"errors\": [ { \"message\": \"Interface 'FINTS_SERVER' is not supported for this operation.\", \"code\": \"BAD_REQUEST\", \"type\": \"TECHNICAL\" } ], \"date\": \"2020-11-19 16:54:06.854\", \"requestId\": \"selfgen-312042e7-df55-47e4-bffd-956a68ef37b5\", \"endpoint\": \"POST /api/v1/bankConnections/import\", \"authContext\": \"1/21\", \"bank\": \"DEMO0002 - finAPI Test Redirect Bank\" } </pre> If an API call requires an additional authentication by the user, HTTP code 510 is returned and the error response contains the additional \"multiStepAuthentication\" object, see the following example: <pre> { \"errors\": [ { \"message\": \"Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456\", \"code\": \"ADDITIONAL_AUTHENTICATION_REQUIRED\", \"type\": \"BUSINESS\", \"multiStepAuthentication\": { \"hash\": \"678b13f4be9ed7d981a840af8131223a\", \"status\": \"CHALLENGE_RESPONSE_REQUIRED\", \"challengeMessage\": \"Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456\", \"answerFieldLabel\": \"TAN\", \"redirectUrl\": null, \"redirectContext\": null, \"redirectContextField\": null, \"twoStepProcedures\": null, \"photoTanMimeType\": null, \"photoTanData\": null, \"opticalData\": null } } ], \"date\": \"2019-11-29 09:51:55.931\", \"requestId\": \"selfgen-45059c99-1b14-4df7-9bd3-9d5f126df294\", \"endpoint\": \"POST /api/v1/bankConnections/import\", \"authContext\": \"1/18\", \"bank\": \"DEMO0001 - finAPI Test Bank\" } </pre> An exception to this error format are API authentication errors, where the following structure is returned: <pre> { \"error\": \"invalid_token\", \"error_description\": \"Invalid access token: cccbce46-xxxx-xxxx-xxxx-xxxxxxxxxx\" } </pre> <h3 id=\"general-paging\"><strong>Paging</strong></h3> API services that may potentially return a lot of data implement paging. They return a limited number of entries within a \"page\". Further entries must be fetched with subsequent calls. <br/><br/> Any API service that implements paging provides the following input parameters:<br/> • \"page\": the number of the page to be retrieved (starting with 1).<br/> • \"perPage\": the number of entries within a page. The default and maximum value is stated in the documentation of the respective services. A paged response contains an additional \"paging\" object with the following structure: <pre> { ... , \"paging\": { \"page\": 1, \"perPage\": 20, \"pageCount\": 234, \"totalCount\": 4662 } } </pre> <h3 id=\"general-internationalization\"><strong>Internationalization</strong></h3> The finAPI services support internationalization which means you can define the language you prefer for API service responses. <br/><br/> The following languages are available: German, English, Czech, Slovak. <br/><br/> The preferred language can be defined by providing the official HTTP <strong>Accept-Language</strong> header. <br/><br/> finAPI reacts on the official iso language codes "de", "en", "cs" and "sk" for the named languages. Additional subtags supported by the Accept-Language header may be provided, e.g. "en-US", but are ignored. <br/> If no Accept-Language header is given, German is used as the default language. <br/><br/> Exceptions:<br/> • Bank login hints and login fields are only available in the language of the bank and not being translated.<br/> • Direct messages from the bank systems typically returned as BUSINESS errors will not be translated.<br/> • BUSINESS errors created by finAPI directly are available in German and English.<br/> • TECHNICAL errors messages meant for developers are mostly in English, but also may be translated. <h3 id=\"general-request-ids\"><strong>Request IDs</strong></h3> With any API call, you can pass a request ID via a header with name \"X-Request-Id\". The request ID can be an arbitrary string with up to 255 characters. Passing a longer string will result in an error. <br/><br/> If you don't pass a request ID for a call, finAPI will generate a random ID internally. <br/><br/> The request ID is always returned back in the response of a service, as a header with name \"X-Request-Id\". <br/><br/> We highly recommend to always pass a (preferably unique) request ID, and include it into your client application logs whenever you make a request or receive a response (especially in the case of an error response). finAPI is also logging request IDs on its end. Having a request ID can help the finAPI support team to work more efficiently and solve tickets faster. <h3 id=\"general-overriding-http-methods\"><strong>Overriding HTTP methods</strong></h3> Some HTTP clients do not support the HTTP methods PATCH or DELETE. If you are using such a client in your application, you can use a POST request instead with a special HTTP header indicating the originally intended HTTP method. <br/><br/> The header's name is <strong>X-HTTP-Method-Override</strong>. Set its value to either <strong>PATCH</strong> or <strong>DELETE</strong>. POST Requests having this header set will be treated either as PATCH or DELETE by the finAPI servers. <br/><br/> Example: <br/><br/> <strong>X-HTTP-Method-Override: PATCH</strong><br/> POST /api/v1/label/51<br/> {\"name\": \"changed label\"}<br/><br/> will be interpreted by finAPI as:<br/><br/> PATCH /api/v1/label/51<br/> {\"name\": \"changed label\"}<br/> <h3 id=\"general-user-metadata\"><strong>User metadata</strong></h3> With the migration to PSD2 APIs, a new term called \"User metadata\" (also known as \"PSU metadata\") has been introduced to the API. This user metadata aims to inform the banking API if there was a real end-user behind an HTTP request or if the request was triggered by a system (e.g. by an automatic batch update). In the latter case, the bank may apply some restrictions such as limiting the number of HTTP requests for a single consent. Also, some operations may be forbidden entirely by the banking API. For example, some banks do not allow issuing a new consent without the end-user being involved. Therefore, it is certainly necessary and obligatory for the customer to provide the PSU metadata for such operations. <br/><br/> As finAPI does not have direct interaction with the end-user, it is the client application's responsibility to provide all the necessary information about the end-user. This must be done by sending additional headers with every request triggered on behalf of the end-user. <br/><br/> At the moment, the following headers are supported by the API:<br/> • \"PSU-IP-Address\" - the IP address of the user's device.<br/> • \"PSU-Device-OS\" - the user's device and/or operating system identification.<br/> • \"PSU-User-Agent\" - the user's web browser or other client device identification. <h3 id=\"general-faq\"><strong>FAQ</strong></h3> <strong>Is there a finAPI SDK?</strong> <br/> Currently we do not offer a native SDK, but there is the option to generate an SDK for almost any target language via OpenAPI. Use the 'Download SDK' button on this page for SDK generation. <br/> <br/> <strong>How can I enable finAPI's automatic batch update?</strong> <br/> Currently there is no way to set up the batch update via the API. Please contact [email protected] for this. <br/> <br/> <strong>Why do I need to keep authorizing when calling services on this page?</strong> <br/> This page is a \"one-page-app\". Reloading the page resets the OAuth authorization context. There is generally no need to reload the page, so just don't do it and your authorization will persist.
*
* API version: 1.151.1
* Contact: [email protected]
*/
// Code generated by OpenAPI Generator (https://openapi-generator.tech); DO NOT EDIT.
package finapi
import (
"encoding/json"
)
// AccountInterface Account interface details
type AccountInterface struct {
// <strong>Type:</strong> BankingInterface<br/> Bank interface. Possible values:<br><br>• <code>WEB_SCRAPER</code> - finAPI will parse account data from the bank's online banking website.<br>• <code>FINTS_SERVER</code> - finAPI will download account data via the bank's FinTS interface.<br>• <code>XS2A</code> - finAPI will download account data via the bank's XS2A interface.<br>
Interface BankingInterface `json:"interface"`
// <strong>Type:</strong> AccountStatus<br/> The current status of the account from the perspective of this interface. Possible values are:<br/>• <code>UPDATED</code> means that the account is up to date from finAPI's point of view. This means that no current import/update is running, and the previous import/update had successfully updated the account's data (e.g. transactions and securities), and the bank given balance matched the transaction's calculated sum, meaning that no adjusting entry ('Zwischensaldo' transaction) was inserted.<br/>• <code>UPDATED_FIXED</code> means that the account is up to date from finAPI's point of view (no current import/update is running, and the previous import/update had successfully updated the account's data), BUT there was a deviation in the bank given balance which was fixed by adding an adjusting entry ('Zwischensaldo' transaction).<br/>• <code>DOWNLOAD_IN_PROGRESS</code> means that the account's data is currently being imported/updated.<br/>• <code>DOWNLOAD_FAILED</code> means that the account data was not successfully imported or updated. Possible reasons: finAPI could not get the account's balance, or it could not parse all transactions/securities, or some internal error has occurred. Also, it could mean that finAPI could not even get to the point of receiving the account data from the bank server, for example because of incorrect login credentials or a network problem. Note however that when we get a balance and just an empty list of transactions or securities, then this is regarded as valid and successful download. The reason for this is that for some accounts that have little activity, we may actually get no recent transactions but only a balance.<br/>• <code>DEPRECATED</code> means that the account could no longer be matched with any account from the bank server. This can mean either that the account was terminated by the user and is no longer sent by the bank server, or that finAPI could no longer match it because the account's data (name, type, iban, account number, etc.) has been changed by the bank.
Status AccountStatus `json:"status"`
Capabilities []AccountCapability `json:"capabilities"`
// <strong>Type:</strong> AccountInterfacePaymentCapabilities<br/> The payment capabilities of this account.
PaymentCapabilities AccountInterfacePaymentCapabilities `json:"paymentCapabilities"`
// Timestamp of when the account was last successfully updated using this interface (or initially imported); more precisely: time when the account data (balance and positions) has been stored into the finAPI databases. The value is returned in the format 'YYYY-MM-DD HH:MM:SS.SSS' (german time).
LastSuccessfulUpdate NullableString `json:"lastSuccessfulUpdate"`
// Timestamp of when the account was last tried to be updated using this interface (or initially imported); more precisely: time when the update (or initial import) was triggered. The value is returned in the format 'YYYY-MM-DD HH:MM:SS.SSS' (german time).
LastUpdateAttempt NullableString `json:"lastUpdateAttempt"`
}
// NewAccountInterface instantiates a new AccountInterface object
// This constructor will assign default values to properties that have it defined,
// and makes sure properties required by API are set, but the set of arguments
// will change when the set of required properties is changed
func NewAccountInterface(interface_ BankingInterface, status AccountStatus, capabilities []AccountCapability, paymentCapabilities AccountInterfacePaymentCapabilities, lastSuccessfulUpdate NullableString, lastUpdateAttempt NullableString, ) *AccountInterface {
this := AccountInterface{}
this.Interface = interface_
this.Status = status
this.Capabilities = capabilities
this.PaymentCapabilities = paymentCapabilities
this.LastSuccessfulUpdate = lastSuccessfulUpdate
this.LastUpdateAttempt = lastUpdateAttempt
return &this
}
// NewAccountInterfaceWithDefaults instantiates a new AccountInterface object
// This constructor will only assign default values to properties that have it defined,
// but it doesn't guarantee that properties required by API are set
func NewAccountInterfaceWithDefaults() *AccountInterface {
this := AccountInterface{}
return &this
}
// GetInterface returns the Interface field value
func (o *AccountInterface) GetInterface() BankingInterface {
if o == nil {
var ret BankingInterface
return ret
}
return o.Interface
}
// GetInterfaceOk returns a tuple with the Interface field value
// and a boolean to check if the value has been set.
func (o *AccountInterface) GetInterfaceOk() (*BankingInterface, bool) {
if o == nil {
return nil, false
}
return &o.Interface, true
}
// SetInterface sets field value
func (o *AccountInterface) SetInterface(v BankingInterface) {
o.Interface = v
}
// GetStatus returns the Status field value
func (o *AccountInterface) GetStatus() AccountStatus {
if o == nil {
var ret AccountStatus
return ret
}
return o.Status
}
// GetStatusOk returns a tuple with the Status field value
// and a boolean to check if the value has been set.
func (o *AccountInterface) GetStatusOk() (*AccountStatus, bool) {
if o == nil {
return nil, false
}
return &o.Status, true
}
// SetStatus sets field value
func (o *AccountInterface) SetStatus(v AccountStatus) {
o.Status = v
}
// GetCapabilities returns the Capabilities field value
func (o *AccountInterface) GetCapabilities() []AccountCapability {
if o == nil {
var ret []AccountCapability
return ret
}
return o.Capabilities
}
// GetCapabilitiesOk returns a tuple with the Capabilities field value
// and a boolean to check if the value has been set.
func (o *AccountInterface) GetCapabilitiesOk() (*[]AccountCapability, bool) {
if o == nil {
return nil, false
}
return &o.Capabilities, true
}
// SetCapabilities sets field value
func (o *AccountInterface) SetCapabilities(v []AccountCapability) {
o.Capabilities = v
}
// GetPaymentCapabilities returns the PaymentCapabilities field value
func (o *AccountInterface) GetPaymentCapabilities() AccountInterfacePaymentCapabilities {
if o == nil {
var ret AccountInterfacePaymentCapabilities
return ret
}
return o.PaymentCapabilities
}
// GetPaymentCapabilitiesOk returns a tuple with the PaymentCapabilities field value
// and a boolean to check if the value has been set.
func (o *AccountInterface) GetPaymentCapabilitiesOk() (*AccountInterfacePaymentCapabilities, bool) {
if o == nil {
return nil, false
}
return &o.PaymentCapabilities, true
}
// SetPaymentCapabilities sets field value
func (o *AccountInterface) SetPaymentCapabilities(v AccountInterfacePaymentCapabilities) {
o.PaymentCapabilities = v
}
// GetLastSuccessfulUpdate returns the LastSuccessfulUpdate field value
// If the value is explicit nil, the zero value for string will be returned
func (o *AccountInterface) GetLastSuccessfulUpdate() string {
if o == nil || o.LastSuccessfulUpdate.Get() == nil {
var ret string
return ret
}
return *o.LastSuccessfulUpdate.Get()
}
// GetLastSuccessfulUpdateOk returns a tuple with the LastSuccessfulUpdate field value
// and a boolean to check if the value has been set.
// NOTE: If the value is an explicit nil, `nil, true` will be returned
func (o *AccountInterface) GetLastSuccessfulUpdateOk() (*string, bool) {
if o == nil {
return nil, false
}
return o.LastSuccessfulUpdate.Get(), o.LastSuccessfulUpdate.IsSet()
}
// SetLastSuccessfulUpdate sets field value
func (o *AccountInterface) SetLastSuccessfulUpdate(v string) {
o.LastSuccessfulUpdate.Set(&v)
}
// GetLastUpdateAttempt returns the LastUpdateAttempt field value
// If the value is explicit nil, the zero value for string will be returned
func (o *AccountInterface) GetLastUpdateAttempt() string {
if o == nil || o.LastUpdateAttempt.Get() == nil {
var ret string
return ret
}
return *o.LastUpdateAttempt.Get()
}
// GetLastUpdateAttemptOk returns a tuple with the LastUpdateAttempt field value
// and a boolean to check if the value has been set.
// NOTE: If the value is an explicit nil, `nil, true` will be returned
func (o *AccountInterface) GetLastUpdateAttemptOk() (*string, bool) {
if o == nil {
return nil, false
}
return o.LastUpdateAttempt.Get(), o.LastUpdateAttempt.IsSet()
}
// SetLastUpdateAttempt sets field value
func (o *AccountInterface) SetLastUpdateAttempt(v string) {
o.LastUpdateAttempt.Set(&v)
}
func (o AccountInterface) MarshalJSON() ([]byte, error) {
toSerialize := map[string]interface{}{}
if true {
toSerialize["interface"] = o.Interface
}
if true {
toSerialize["status"] = o.Status
}
if true {
toSerialize["capabilities"] = o.Capabilities
}
if true {
toSerialize["paymentCapabilities"] = o.PaymentCapabilities
}
if true {
toSerialize["lastSuccessfulUpdate"] = o.LastSuccessfulUpdate.Get()
}
if true {
toSerialize["lastUpdateAttempt"] = o.LastUpdateAttempt.Get()
}
return json.Marshal(toSerialize)
}
type NullableAccountInterface struct {
value *AccountInterface
isSet bool
}
func (v NullableAccountInterface) Get() *AccountInterface {
return v.value
}
func (v *NullableAccountInterface) Set(val *AccountInterface) {
v.value = val
v.isSet = true
}
func (v NullableAccountInterface) IsSet() bool {
return v.isSet
}
func (v *NullableAccountInterface) Unset() {
v.value = nil
v.isSet = false
}
func NewNullableAccountInterface(val *AccountInterface) *NullableAccountInterface {
return &NullableAccountInterface{value: val, isSet: true}
}
func (v NullableAccountInterface) MarshalJSON() ([]byte, error) {
return json.Marshal(v.value)
}
func (v *NullableAccountInterface) UnmarshalJSON(src []byte) error {
v.isSet = true
return json.Unmarshal(src, &v.value)
}