From c51d2c9c469dbd6ca50c814c0ff98b93c57198e5 Mon Sep 17 00:00:00 2001 From: Phillip Baker Date: Fri, 26 Jan 2018 23:22:53 -0500 Subject: [PATCH] Initial client. --- .gitignore | 64 ++ README.md | 141 ++++ banking_client/__init__.py | 53 ++ banking_client/api/__init__.py | 11 + banking_client/api/account_api.py | 604 +++++++++++++++++ banking_client/api/general_api.py | 122 ++++ banking_client/api/subscription_api.py | 604 +++++++++++++++++ banking_client/api/transaction_api.py | 519 ++++++++++++++ banking_client/api/transfer_api.py | 144 ++++ banking_client/api/user_api.py | 259 +++++++ banking_client/api_client.py | 631 ++++++++++++++++++ banking_client/configuration.py | 251 +++++++ banking_client/models/__init__.py | 41 ++ banking_client/models/account.py | 298 +++++++++ banking_client/models/account_balances.py | 240 +++++++ banking_client/models/address.py | 214 ++++++ banking_client/models/check.py | 112 ++++ banking_client/models/document.py | 140 ++++ banking_client/models/error.py | 168 +++++ banking_client/models/inline_response_200.py | 166 +++++ .../models/inline_response_200_1.py | 112 ++++ .../models/inline_response_200_2.py | 166 +++++ .../models/inline_response_200_3.py | 112 ++++ .../models/inline_response_200_4.py | 166 +++++ .../models/inline_response_200_5.py | 166 +++++ .../models/inline_response_200_6.py | 112 ++++ .../models/inline_response_200_7.py | 112 ++++ .../models/inline_response_200_8.py | 166 +++++ banking_client/models/inline_response_201.py | 112 ++++ banking_client/models/links.py | 136 ++++ banking_client/models/location.py | 162 +++++ banking_client/models/membership.py | 164 +++++ banking_client/models/meta.py | 110 +++ banking_client/models/phone.py | 110 +++ banking_client/models/subscription.py | 326 +++++++++ banking_client/models/transaction.py | 453 +++++++++++++ banking_client/models/transfer.py | 162 +++++ banking_client/models/user.py | 245 +++++++ banking_client/rest.py | 322 +++++++++ requirements.txt | 5 + setup.py | 39 ++ test-requirements.txt | 5 + 42 files changed, 8245 insertions(+) create mode 100644 .gitignore create mode 100644 README.md create mode 100644 banking_client/__init__.py create mode 100644 banking_client/api/__init__.py create mode 100644 banking_client/api/account_api.py create mode 100644 banking_client/api/general_api.py create mode 100644 banking_client/api/subscription_api.py create mode 100644 banking_client/api/transaction_api.py create mode 100644 banking_client/api/transfer_api.py create mode 100644 banking_client/api/user_api.py create mode 100644 banking_client/api_client.py create mode 100644 banking_client/configuration.py create mode 100644 banking_client/models/__init__.py create mode 100644 banking_client/models/account.py create mode 100644 banking_client/models/account_balances.py create mode 100644 banking_client/models/address.py create mode 100644 banking_client/models/check.py create mode 100644 banking_client/models/document.py create mode 100644 banking_client/models/error.py create mode 100644 banking_client/models/inline_response_200.py create mode 100644 banking_client/models/inline_response_200_1.py create mode 100644 banking_client/models/inline_response_200_2.py create mode 100644 banking_client/models/inline_response_200_3.py create mode 100644 banking_client/models/inline_response_200_4.py create mode 100644 banking_client/models/inline_response_200_5.py create mode 100644 banking_client/models/inline_response_200_6.py create mode 100644 banking_client/models/inline_response_200_7.py create mode 100644 banking_client/models/inline_response_200_8.py create mode 100644 banking_client/models/inline_response_201.py create mode 100644 banking_client/models/links.py create mode 100644 banking_client/models/location.py create mode 100644 banking_client/models/membership.py create mode 100644 banking_client/models/meta.py create mode 100644 banking_client/models/phone.py create mode 100644 banking_client/models/subscription.py create mode 100644 banking_client/models/transaction.py create mode 100644 banking_client/models/transfer.py create mode 100644 banking_client/models/user.py create mode 100644 banking_client/rest.py create mode 100644 requirements.txt create mode 100644 setup.py create mode 100644 test-requirements.txt diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..a655050 --- /dev/null +++ b/.gitignore @@ -0,0 +1,64 @@ +# Byte-compiled / optimized / DLL files +__pycache__/ +*.py[cod] +*$py.class + +# C extensions +*.so + +# Distribution / packaging +.Python +env/ +build/ +develop-eggs/ +dist/ +downloads/ +eggs/ +.eggs/ +lib/ +lib64/ +parts/ +sdist/ +var/ +*.egg-info/ +.installed.cfg +*.egg + +# PyInstaller +# Usually these files are written by a python script from a template +# before PyInstaller builds the exe, so as to inject date/other infos into it. +*.manifest +*.spec + +# Installer logs +pip-log.txt +pip-delete-this-directory.txt + +# Unit test / coverage reports +htmlcov/ +.tox/ +.coverage +.coverage.* +.cache +nosetests.xml +coverage.xml +*,cover +.hypothesis/ +venv/ +.python-version + +# Translations +*.mo +*.pot + +# Django stuff: +*.log + +# Sphinx documentation +docs/_build/ + +# PyBuilder +target/ + +#Ipython Notebook +.ipynb_checkpoints diff --git a/README.md b/README.md new file mode 100644 index 0000000..6d2bc86 --- /dev/null +++ b/README.md @@ -0,0 +1,141 @@ +# banking-client + +- API version: 0.1.0 +- Package version: 1.0.0 +- Build package: io.swagger.codegen.languages.PythonClientCodegen + +## Requirements. + +Python 2.7 and 3.4+ + +## Installation & Usage +### pip install + +If the python package is hosted on Github, you can install directly from Github + +```sh +pip install git+https://github.com/narmitech/banking-client-python.git +``` +(you may need to run `pip` with root permission: `sudo pip install git+https://github.com/narmitech/banking-client-python.git`) + +Then import the package: +```python +import banking_client +``` + +### Setuptools + +Install via [Setuptools](http://pypi.python.org/pypi/setuptools). + +```sh +python setup.py install --user +``` +(or `sudo python setup.py install` to install the package for all users) + +Then import the package: +```python +import banking_client +``` + +## Getting Started + +Please follow the [installation procedure](#installation--usage) and then run the following: + +```python +from __future__ import print_function +import time +import banking_client +from banking_client.api_client import ApiClient +from banking_client.configuration import Configuration +from banking_client.rest import ApiException +from pprint import pprint + +config = Configuration() +config.host = 'https://api.demo.narmitech.com/v1' +config.access_token = 'YOUR_ACCESS_TOKEN' +config.secret = 'YOUR_SECRET' +api_instance = banking_client.AccountApi(api_client=ApiClient(configuration=config)) +api_instance.list() + +try: + # Get account + api_response = api_instance.list() + pprint(api_response) +except ApiException as e: + print("Exception when calling AccountApi->get: %s\n" % e) + +``` + +## Documentation for API Endpoints + +All URIs are relative to *https://api.example.com/v1* + +Class | Method | HTTP request | Description +------------ | ------------- | ------------- | ------------- +*AccountApi* | [**get**](docs/AccountApi.md#get) | **GET** /accounts/{accountId} | Get account +*AccountApi* | [**get_account_balances**](docs/AccountApi.md#get_account_balances) | **GET** /account_balances/{accountBalancesId} | Get account balances for an account +*AccountApi* | [**list**](docs/AccountApi.md#list) | **GET** /accounts | List accounts +*AccountApi* | [**list_account_balances**](docs/AccountApi.md#list_account_balances) | **GET** /account_balances | List account balances +*AccountApi* | [**update**](docs/AccountApi.md#update) | **PUT** /accounts/{accountId} | Update account +*GeneralApi* | [**list_ping**](docs/GeneralApi.md#list_ping) | **GET** /ping | Server heartbeat operation +*SubscriptionApi* | [**create**](docs/SubscriptionApi.md#create) | **POST** /subscriptions | Create subscription +*SubscriptionApi* | [**destroy**](docs/SubscriptionApi.md#destroy) | **DELETE** /subscriptions/{subscriptionId} | Delete subscription +*SubscriptionApi* | [**get**](docs/SubscriptionApi.md#get) | **GET** /subscriptions/{subscriptionId} | Get subscription +*SubscriptionApi* | [**list**](docs/SubscriptionApi.md#list) | **GET** /subscriptions | List subscriptions +*SubscriptionApi* | [**update**](docs/SubscriptionApi.md#update) | **PUT** /subscriptions/{subscriptionId} | Update subscription +*TransactionApi* | [**get**](docs/TransactionApi.md#get) | **GET** /transactions/{transactionId} | Get transaction +*TransactionApi* | [**list**](docs/TransactionApi.md#list) | **GET** /transactions | List transactions +*TransactionApi* | [**list_transactions**](docs/TransactionApi.md#list_transactions) | **GET** /accounts/{accountId}/transactions | List transactions for an account +*TransactionApi* | [**update**](docs/TransactionApi.md#update) | **PUT** /transactions/{transactionId} | Update transaction +*TransferApi* | [**create**](docs/TransferApi.md#create) | **POST** /transfers | Create a transfer +*UserApi* | [**get**](docs/UserApi.md#get) | **GET** /users/{userId} | Get user +*UserApi* | [**list**](docs/UserApi.md#list) | **GET** /users | List users + + +## Documentation For Models + + - [Account](docs/Account.md) + - [AccountBalances](docs/AccountBalances.md) + - [Address](docs/Address.md) + - [Check](docs/Check.md) + - [Document](docs/Document.md) + - [Error](docs/Error.md) + - [InlineResponse200](docs/InlineResponse200.md) + - [InlineResponse2001](docs/InlineResponse2001.md) + - [InlineResponse2002](docs/InlineResponse2002.md) + - [InlineResponse2003](docs/InlineResponse2003.md) + - [InlineResponse2004](docs/InlineResponse2004.md) + - [InlineResponse2005](docs/InlineResponse2005.md) + - [InlineResponse2006](docs/InlineResponse2006.md) + - [InlineResponse2007](docs/InlineResponse2007.md) + - [InlineResponse2008](docs/InlineResponse2008.md) + - [InlineResponse201](docs/InlineResponse201.md) + - [Links](docs/Links.md) + - [Location](docs/Location.md) + - [Membership](docs/Membership.md) + - [Meta](docs/Meta.md) + - [Phone](docs/Phone.md) + - [Subscription](docs/Subscription.md) + - [Transaction](docs/Transaction.md) + - [Transfer](docs/Transfer.md) + - [User](docs/User.md) + + +## Documentation For Authorization + + +## Application + +- **Type**: OAuth +- **Flow**: application +- **Authorization URL**: +- **Scopes**: + - **write**: allows reading and modifying resources + - **read**: allows reading resources + - **read:profile**: allows reading extended information about the user including address + + +## Author + +contact@narmitech.com + diff --git a/banking_client/__init__.py b/banking_client/__init__.py new file mode 100644 index 0000000..0f2314d --- /dev/null +++ b/banking_client/__init__.py @@ -0,0 +1,53 @@ +# coding: utf-8 + +# flake8: noqa + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +# import apis into sdk package +from banking_client.api.account_api import AccountApi +from banking_client.api.general_api import GeneralApi +from banking_client.api.subscription_api import SubscriptionApi +from banking_client.api.transaction_api import TransactionApi +from banking_client.api.transfer_api import TransferApi +from banking_client.api.user_api import UserApi + +# import ApiClient +from banking_client.api_client import ApiClient +from banking_client.configuration import Configuration +# import models into sdk package +from banking_client.models.account import Account +from banking_client.models.account_balances import AccountBalances +from banking_client.models.address import Address +from banking_client.models.check import Check +from banking_client.models.document import Document +from banking_client.models.error import Error +from banking_client.models.inline_response_200 import InlineResponse200 +from banking_client.models.inline_response_200_1 import InlineResponse2001 +from banking_client.models.inline_response_200_2 import InlineResponse2002 +from banking_client.models.inline_response_200_3 import InlineResponse2003 +from banking_client.models.inline_response_200_4 import InlineResponse2004 +from banking_client.models.inline_response_200_5 import InlineResponse2005 +from banking_client.models.inline_response_200_6 import InlineResponse2006 +from banking_client.models.inline_response_200_7 import InlineResponse2007 +from banking_client.models.inline_response_200_8 import InlineResponse2008 +from banking_client.models.inline_response_201 import InlineResponse201 +from banking_client.models.links import Links +from banking_client.models.location import Location +from banking_client.models.membership import Membership +from banking_client.models.meta import Meta +from banking_client.models.phone import Phone +from banking_client.models.subscription import Subscription +from banking_client.models.transaction import Transaction +from banking_client.models.transfer import Transfer +from banking_client.models.user import User diff --git a/banking_client/api/__init__.py b/banking_client/api/__init__.py new file mode 100644 index 0000000..b4186d6 --- /dev/null +++ b/banking_client/api/__init__.py @@ -0,0 +1,11 @@ +from __future__ import absolute_import + +# flake8: noqa + +# import apis into api package +from banking_client.api.account_api import AccountApi +from banking_client.api.general_api import GeneralApi +from banking_client.api.subscription_api import SubscriptionApi +from banking_client.api.transaction_api import TransactionApi +from banking_client.api.transfer_api import TransferApi +from banking_client.api.user_api import UserApi diff --git a/banking_client/api/account_api.py b/banking_client/api/account_api.py new file mode 100644 index 0000000..c01c569 --- /dev/null +++ b/banking_client/api/account_api.py @@ -0,0 +1,604 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +import re # noqa: F401 + +# python 2 and python 3 compatibility library +import six + +from banking_client.api_client import ApiClient + + +class AccountApi(object): + """ + This class is auto generated, do not edit the class manually. + """ + + def __init__(self, api_client=None): + if api_client is None: + api_client = ApiClient() + self.api_client = api_client + + def get(self, account_id, **kwargs): # noqa: E501 + """Get account # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get(account_id, async=True) + >>> result = thread.get() + + :param async bool + :param str account_id: The id of the account to be operated on (note that this identifies an account at the suffix level) (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2003 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.get_with_http_info(account_id, **kwargs) # noqa: E501 + else: + (data) = self.get_with_http_info(account_id, **kwargs) # noqa: E501 + return data + + def get_with_http_info(self, account_id, **kwargs): # noqa: E501 + """Get account # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get_with_http_info(account_id, async=True) + >>> result = thread.get() + + :param async bool + :param str account_id: The id of the account to be operated on (note that this identifies an account at the suffix level) (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2003 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['account_id', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method get" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'account_id' is set + if ('account_id' not in params or + params['account_id'] is None): + raise ValueError("Missing the required parameter `account_id` when calling `get`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'account_id' in params: + path_params['accountId'] = params['account_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/accounts/{accountId}', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2003', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def get_account_balances(self, account_balances_id, **kwargs): # noqa: E501 + """Get account balances for an account # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get_account_balances(account_balances_id, async=True) + >>> result = thread.get() + + :param async bool + :param str account_balances_id: The id of the account balances object to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2006 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.get_account_balances_with_http_info(account_balances_id, **kwargs) # noqa: E501 + else: + (data) = self.get_account_balances_with_http_info(account_balances_id, **kwargs) # noqa: E501 + return data + + def get_account_balances_with_http_info(self, account_balances_id, **kwargs): # noqa: E501 + """Get account balances for an account # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get_account_balances_with_http_info(account_balances_id, async=True) + >>> result = thread.get() + + :param async bool + :param str account_balances_id: The id of the account balances object to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2006 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['account_balances_id', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method get_account_balances" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'account_balances_id' is set + if ('account_balances_id' not in params or + params['account_balances_id'] is None): + raise ValueError("Missing the required parameter `account_balances_id` when calling `get_account_balances`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'account_balances_id' in params: + path_params['accountBalancesId'] = params['account_balances_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/account_balances/{accountBalancesId}', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2006', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def list(self, **kwargs): # noqa: E501 + """List accounts # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2002 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.list_with_http_info(**kwargs) # noqa: E501 + else: + (data) = self.list_with_http_info(**kwargs) # noqa: E501 + return data + + def list_with_http_info(self, **kwargs): # noqa: E501 + """List accounts # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_with_http_info(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2002 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['page', 'per_page', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method list" % key + ) + params[key] = val + del params['kwargs'] + + collection_formats = {} + + path_params = {} + + query_params = [] + if 'page' in params: + query_params.append(('page', params['page'])) # noqa: E501 + if 'per_page' in params: + query_params.append(('per_page', params['per_page'])) # noqa: E501 + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/accounts', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2002', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def list_account_balances(self, **kwargs): # noqa: E501 + """List account balances # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_account_balances(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2005 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.list_account_balances_with_http_info(**kwargs) # noqa: E501 + else: + (data) = self.list_account_balances_with_http_info(**kwargs) # noqa: E501 + return data + + def list_account_balances_with_http_info(self, **kwargs): # noqa: E501 + """List account balances # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_account_balances_with_http_info(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2005 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['page', 'per_page', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method list_account_balances" % key + ) + params[key] = val + del params['kwargs'] + + collection_formats = {} + + path_params = {} + + query_params = [] + if 'page' in params: + query_params.append(('page', params['page'])) # noqa: E501 + if 'per_page' in params: + query_params.append(('per_page', params['per_page'])) # noqa: E501 + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/account_balances', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2005', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def update(self, account_id, body, **kwargs): # noqa: E501 + """Update account # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.update(account_id, body, async=True) + >>> result = thread.get() + + :param async bool + :param str account_id: The id of the account to be operated on (note that this identifies an account at the suffix level) (required) + :param Account body: Account attributes to update object (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2003 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.update_with_http_info(account_id, body, **kwargs) # noqa: E501 + else: + (data) = self.update_with_http_info(account_id, body, **kwargs) # noqa: E501 + return data + + def update_with_http_info(self, account_id, body, **kwargs): # noqa: E501 + """Update account # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.update_with_http_info(account_id, body, async=True) + >>> result = thread.get() + + :param async bool + :param str account_id: The id of the account to be operated on (note that this identifies an account at the suffix level) (required) + :param Account body: Account attributes to update object (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2003 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['account_id', 'body', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method update" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'account_id' is set + if ('account_id' not in params or + params['account_id'] is None): + raise ValueError("Missing the required parameter `account_id` when calling `update`") # noqa: E501 + # verify the required parameter 'body' is set + if ('body' not in params or + params['body'] is None): + raise ValueError("Missing the required parameter `body` when calling `update`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'account_id' in params: + path_params['accountId'] = params['account_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + if 'body' in params: + body_params = params['body'] + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/accounts/{accountId}', 'PUT', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2003', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) diff --git a/banking_client/api/general_api.py b/banking_client/api/general_api.py new file mode 100644 index 0000000..46739d2 --- /dev/null +++ b/banking_client/api/general_api.py @@ -0,0 +1,122 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +import re # noqa: F401 + +# python 2 and python 3 compatibility library +import six + +from banking_client.api_client import ApiClient + + +class GeneralApi(object): + """ + This class is auto generated, do not edit the class manually. + """ + + def __init__(self, api_client=None): + if api_client is None: + api_client = ApiClient() + self.api_client = api_client + + def list_ping(self, **kwargs): # noqa: E501 + """Server heartbeat operation # noqa: E501 + + Publicly available endpoint to answer the question, \"are you there?\" # noqa: E501 + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_ping(async=True) + >>> result = thread.get() + + :param async bool + :return: None + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.list_ping_with_http_info(**kwargs) # noqa: E501 + else: + (data) = self.list_ping_with_http_info(**kwargs) # noqa: E501 + return data + + def list_ping_with_http_info(self, **kwargs): # noqa: E501 + """Server heartbeat operation # noqa: E501 + + Publicly available endpoint to answer the question, \"are you there?\" # noqa: E501 + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_ping_with_http_info(async=True) + >>> result = thread.get() + + :param async bool + :return: None + If the method is called asynchronously, + returns the request thread. + """ + + all_params = [] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method list_ping" % key + ) + params[key] = val + del params['kwargs'] + + collection_formats = {} + + path_params = {} + + query_params = [] + + header_params = {} + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = [] # noqa: E501 + + return self.api_client.call_api( + '/ping', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type=None, # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) diff --git a/banking_client/api/subscription_api.py b/banking_client/api/subscription_api.py new file mode 100644 index 0000000..949b791 --- /dev/null +++ b/banking_client/api/subscription_api.py @@ -0,0 +1,604 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +import re # noqa: F401 + +# python 2 and python 3 compatibility library +import six + +from banking_client.api_client import ApiClient + + +class SubscriptionApi(object): + """ + This class is auto generated, do not edit the class manually. + """ + + def __init__(self, api_client=None): + if api_client is None: + api_client = ApiClient() + self.api_client = api_client + + def create(self, body, **kwargs): # noqa: E501 + """Create subscription # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.create(body, async=True) + >>> result = thread.get() + + :param async bool + :param Subscription body: Subscription attributes to create object (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse201 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.create_with_http_info(body, **kwargs) # noqa: E501 + else: + (data) = self.create_with_http_info(body, **kwargs) # noqa: E501 + return data + + def create_with_http_info(self, body, **kwargs): # noqa: E501 + """Create subscription # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.create_with_http_info(body, async=True) + >>> result = thread.get() + + :param async bool + :param Subscription body: Subscription attributes to create object (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse201 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['body', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method create" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'body' is set + if ('body' not in params or + params['body'] is None): + raise ValueError("Missing the required parameter `body` when calling `create`") # noqa: E501 + + collection_formats = {} + + path_params = {} + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + if 'body' in params: + body_params = params['body'] + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/subscriptions', 'POST', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse201', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def destroy(self, subscription_id, **kwargs): # noqa: E501 + """Delete subscription # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.destroy(subscription_id, async=True) + >>> result = thread.get() + + :param async bool + :param str subscription_id: The id of the subscription to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: str + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.destroy_with_http_info(subscription_id, **kwargs) # noqa: E501 + else: + (data) = self.destroy_with_http_info(subscription_id, **kwargs) # noqa: E501 + return data + + def destroy_with_http_info(self, subscription_id, **kwargs): # noqa: E501 + """Delete subscription # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.destroy_with_http_info(subscription_id, async=True) + >>> result = thread.get() + + :param async bool + :param str subscription_id: The id of the subscription to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: str + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['subscription_id', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method destroy" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'subscription_id' is set + if ('subscription_id' not in params or + params['subscription_id'] is None): + raise ValueError("Missing the required parameter `subscription_id` when calling `destroy`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'subscription_id' in params: + path_params['subscriptionId'] = params['subscription_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/subscriptions/{subscriptionId}', 'DELETE', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='str', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def get(self, subscription_id, **kwargs): # noqa: E501 + """Get subscription # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get(subscription_id, async=True) + >>> result = thread.get() + + :param async bool + :param str subscription_id: The id of the subscription to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse201 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.get_with_http_info(subscription_id, **kwargs) # noqa: E501 + else: + (data) = self.get_with_http_info(subscription_id, **kwargs) # noqa: E501 + return data + + def get_with_http_info(self, subscription_id, **kwargs): # noqa: E501 + """Get subscription # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get_with_http_info(subscription_id, async=True) + >>> result = thread.get() + + :param async bool + :param str subscription_id: The id of the subscription to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse201 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['subscription_id', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method get" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'subscription_id' is set + if ('subscription_id' not in params or + params['subscription_id'] is None): + raise ValueError("Missing the required parameter `subscription_id` when calling `get`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'subscription_id' in params: + path_params['subscriptionId'] = params['subscription_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/subscriptions/{subscriptionId}', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse201', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def list(self, **kwargs): # noqa: E501 + """List subscriptions # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2008 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.list_with_http_info(**kwargs) # noqa: E501 + else: + (data) = self.list_with_http_info(**kwargs) # noqa: E501 + return data + + def list_with_http_info(self, **kwargs): # noqa: E501 + """List subscriptions # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_with_http_info(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2008 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['page', 'per_page', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method list" % key + ) + params[key] = val + del params['kwargs'] + + collection_formats = {} + + path_params = {} + + query_params = [] + if 'page' in params: + query_params.append(('page', params['page'])) # noqa: E501 + if 'per_page' in params: + query_params.append(('per_page', params['per_page'])) # noqa: E501 + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/subscriptions', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2008', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def update(self, subscription_id, body, **kwargs): # noqa: E501 + """Update subscription # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.update(subscription_id, body, async=True) + >>> result = thread.get() + + :param async bool + :param str subscription_id: The id of the subscription to be operated on (required) + :param Subscription body: Subscription attributes to update object (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse201 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.update_with_http_info(subscription_id, body, **kwargs) # noqa: E501 + else: + (data) = self.update_with_http_info(subscription_id, body, **kwargs) # noqa: E501 + return data + + def update_with_http_info(self, subscription_id, body, **kwargs): # noqa: E501 + """Update subscription # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.update_with_http_info(subscription_id, body, async=True) + >>> result = thread.get() + + :param async bool + :param str subscription_id: The id of the subscription to be operated on (required) + :param Subscription body: Subscription attributes to update object (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse201 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['subscription_id', 'body', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method update" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'subscription_id' is set + if ('subscription_id' not in params or + params['subscription_id'] is None): + raise ValueError("Missing the required parameter `subscription_id` when calling `update`") # noqa: E501 + # verify the required parameter 'body' is set + if ('body' not in params or + params['body'] is None): + raise ValueError("Missing the required parameter `body` when calling `update`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'subscription_id' in params: + path_params['subscriptionId'] = params['subscription_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + if 'body' in params: + body_params = params['body'] + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/subscriptions/{subscriptionId}', 'PUT', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse201', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) diff --git a/banking_client/api/transaction_api.py b/banking_client/api/transaction_api.py new file mode 100644 index 0000000..8663aa2 --- /dev/null +++ b/banking_client/api/transaction_api.py @@ -0,0 +1,519 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +import re # noqa: F401 + +# python 2 and python 3 compatibility library +import six + +from banking_client.api_client import ApiClient + + +class TransactionApi(object): + """ + This class is auto generated, do not edit the class manually. + """ + + def __init__(self, api_client=None): + if api_client is None: + api_client = ApiClient() + self.api_client = api_client + + def get(self, transaction_id, **kwargs): # noqa: E501 + """Get transaction # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get(transaction_id, async=True) + >>> result = thread.get() + + :param async bool + :param str transaction_id: The id of the transaction to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2007 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.get_with_http_info(transaction_id, **kwargs) # noqa: E501 + else: + (data) = self.get_with_http_info(transaction_id, **kwargs) # noqa: E501 + return data + + def get_with_http_info(self, transaction_id, **kwargs): # noqa: E501 + """Get transaction # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get_with_http_info(transaction_id, async=True) + >>> result = thread.get() + + :param async bool + :param str transaction_id: The id of the transaction to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2007 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['transaction_id', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method get" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'transaction_id' is set + if ('transaction_id' not in params or + params['transaction_id'] is None): + raise ValueError("Missing the required parameter `transaction_id` when calling `get`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'transaction_id' in params: + path_params['transactionId'] = params['transaction_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/transactions/{transactionId}', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2007', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def list(self, **kwargs): # noqa: E501 + """List transactions # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :param str before: A cursor to paginate large (time sorted) collections. Use to return results sorted before (greater than) the given ID. + :param str after: A cursor to paginate large (time sorted) collections. Use to return results sorted after (less than) the given ID. + :param str filter: Indicate which type of transactions to return. Can be one of: * `unsettled`: transactions without a `settled_at` time + :return: InlineResponse2004 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.list_with_http_info(**kwargs) # noqa: E501 + else: + (data) = self.list_with_http_info(**kwargs) # noqa: E501 + return data + + def list_with_http_info(self, **kwargs): # noqa: E501 + """List transactions # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_with_http_info(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :param str before: A cursor to paginate large (time sorted) collections. Use to return results sorted before (greater than) the given ID. + :param str after: A cursor to paginate large (time sorted) collections. Use to return results sorted after (less than) the given ID. + :param str filter: Indicate which type of transactions to return. Can be one of: * `unsettled`: transactions without a `settled_at` time + :return: InlineResponse2004 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['page', 'per_page', 'authorization', 'date', 'signature', 'x_request_id', 'before', 'after', 'filter'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method list" % key + ) + params[key] = val + del params['kwargs'] + + collection_formats = {} + + path_params = {} + + query_params = [] + if 'page' in params: + query_params.append(('page', params['page'])) # noqa: E501 + if 'per_page' in params: + query_params.append(('per_page', params['per_page'])) # noqa: E501 + if 'before' in params: + query_params.append(('before', params['before'])) # noqa: E501 + if 'after' in params: + query_params.append(('after', params['after'])) # noqa: E501 + if 'filter' in params: + query_params.append(('filter', params['filter'])) # noqa: E501 + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/transactions', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2004', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def list_transactions(self, account_id, **kwargs): # noqa: E501 + """List transactions for an account # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_transactions(account_id, async=True) + >>> result = thread.get() + + :param async bool + :param str account_id: The id of the account for which to retrieve transactions (note that this identifies an account at the suffix level) (required) + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :param str before: A cursor to paginate large (time sorted) collections. Use to return results sorted before (greater than) the given ID. + :param str after: A cursor to paginate large (time sorted) collections. Use to return results sorted after (less than) the given ID. + :return: InlineResponse2004 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.list_transactions_with_http_info(account_id, **kwargs) # noqa: E501 + else: + (data) = self.list_transactions_with_http_info(account_id, **kwargs) # noqa: E501 + return data + + def list_transactions_with_http_info(self, account_id, **kwargs): # noqa: E501 + """List transactions for an account # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_transactions_with_http_info(account_id, async=True) + >>> result = thread.get() + + :param async bool + :param str account_id: The id of the account for which to retrieve transactions (note that this identifies an account at the suffix level) (required) + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :param str before: A cursor to paginate large (time sorted) collections. Use to return results sorted before (greater than) the given ID. + :param str after: A cursor to paginate large (time sorted) collections. Use to return results sorted after (less than) the given ID. + :return: InlineResponse2004 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['account_id', 'page', 'per_page', 'authorization', 'date', 'signature', 'x_request_id', 'before', 'after'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method list_transactions" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'account_id' is set + if ('account_id' not in params or + params['account_id'] is None): + raise ValueError("Missing the required parameter `account_id` when calling `list_transactions`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'account_id' in params: + path_params['accountId'] = params['account_id'] # noqa: E501 + + query_params = [] + if 'page' in params: + query_params.append(('page', params['page'])) # noqa: E501 + if 'per_page' in params: + query_params.append(('per_page', params['per_page'])) # noqa: E501 + if 'before' in params: + query_params.append(('before', params['before'])) # noqa: E501 + if 'after' in params: + query_params.append(('after', params['after'])) # noqa: E501 + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/accounts/{accountId}/transactions', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2004', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def update(self, transaction_id, body, **kwargs): # noqa: E501 + """Update transaction # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.update(transaction_id, body, async=True) + >>> result = thread.get() + + :param async bool + :param str transaction_id: The id of the transaction to be operated on (required) + :param Transaction body: Transaction attributes to be updated (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2007 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.update_with_http_info(transaction_id, body, **kwargs) # noqa: E501 + else: + (data) = self.update_with_http_info(transaction_id, body, **kwargs) # noqa: E501 + return data + + def update_with_http_info(self, transaction_id, body, **kwargs): # noqa: E501 + """Update transaction # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.update_with_http_info(transaction_id, body, async=True) + >>> result = thread.get() + + :param async bool + :param str transaction_id: The id of the transaction to be operated on (required) + :param Transaction body: Transaction attributes to be updated (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2007 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['transaction_id', 'body', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method update" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'transaction_id' is set + if ('transaction_id' not in params or + params['transaction_id'] is None): + raise ValueError("Missing the required parameter `transaction_id` when calling `update`") # noqa: E501 + # verify the required parameter 'body' is set + if ('body' not in params or + params['body'] is None): + raise ValueError("Missing the required parameter `body` when calling `update`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'transaction_id' in params: + path_params['transactionId'] = params['transaction_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + if 'body' in params: + body_params = params['body'] + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/transactions/{transactionId}', 'PUT', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2007', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) diff --git a/banking_client/api/transfer_api.py b/banking_client/api/transfer_api.py new file mode 100644 index 0000000..9b4a787 --- /dev/null +++ b/banking_client/api/transfer_api.py @@ -0,0 +1,144 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +import re # noqa: F401 + +# python 2 and python 3 compatibility library +import six + +from banking_client.api_client import ApiClient + + +class TransferApi(object): + """ + This class is auto generated, do not edit the class manually. + """ + + def __init__(self, api_client=None): + if api_client is None: + api_client = ApiClient() + self.api_client = api_client + + def create(self, body, **kwargs): # noqa: E501 + """Create a transfer # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.create(body, async=True) + >>> result = thread.get() + + :param async bool + :param Transfer body: Transfer object representing money to be moved between accounts (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: object + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.create_with_http_info(body, **kwargs) # noqa: E501 + else: + (data) = self.create_with_http_info(body, **kwargs) # noqa: E501 + return data + + def create_with_http_info(self, body, **kwargs): # noqa: E501 + """Create a transfer # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.create_with_http_info(body, async=True) + >>> result = thread.get() + + :param async bool + :param Transfer body: Transfer object representing money to be moved between accounts (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: object + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['body', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method create" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'body' is set + if ('body' not in params or + params['body'] is None): + raise ValueError("Missing the required parameter `body` when calling `create`") # noqa: E501 + + collection_formats = {} + + path_params = {} + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + if 'body' in params: + body_params = params['body'] + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/transfers', 'POST', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='object', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) diff --git a/banking_client/api/user_api.py b/banking_client/api/user_api.py new file mode 100644 index 0000000..0f75895 --- /dev/null +++ b/banking_client/api/user_api.py @@ -0,0 +1,259 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +import re # noqa: F401 + +# python 2 and python 3 compatibility library +import six + +from banking_client.api_client import ApiClient + + +class UserApi(object): + """ + This class is auto generated, do not edit the class manually. + """ + + def __init__(self, api_client=None): + if api_client is None: + api_client = ApiClient() + self.api_client = api_client + + def get(self, user_id, **kwargs): # noqa: E501 + """Get user # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get(user_id, async=True) + >>> result = thread.get() + + :param async bool + :param str user_id: The id of the user to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2001 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.get_with_http_info(user_id, **kwargs) # noqa: E501 + else: + (data) = self.get_with_http_info(user_id, **kwargs) # noqa: E501 + return data + + def get_with_http_info(self, user_id, **kwargs): # noqa: E501 + """Get user # noqa: E501 + + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.get_with_http_info(user_id, async=True) + >>> result = thread.get() + + :param async bool + :param str user_id: The id of the user to be operated on (required) + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse2001 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['user_id', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method get" % key + ) + params[key] = val + del params['kwargs'] + # verify the required parameter 'user_id' is set + if ('user_id' not in params or + params['user_id'] is None): + raise ValueError("Missing the required parameter `user_id` when calling `get`") # noqa: E501 + + collection_formats = {} + + path_params = {} + if 'user_id' in params: + path_params['userId'] = params['user_id'] # noqa: E501 + + query_params = [] + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/users/{userId}', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse2001', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) + + def list(self, **kwargs): # noqa: E501 + """List users # noqa: E501 + + # noqa: E501 + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse200 + If the method is called asynchronously, + returns the request thread. + """ + kwargs['_return_http_data_only'] = True + if kwargs.get('async'): + return self.list_with_http_info(**kwargs) # noqa: E501 + else: + (data) = self.list_with_http_info(**kwargs) # noqa: E501 + return data + + def list_with_http_info(self, **kwargs): # noqa: E501 + """List users # noqa: E501 + + # noqa: E501 + This method makes a synchronous HTTP request by default. To make an + asynchronous HTTP request, please pass async=True + >>> thread = api.list_with_http_info(async=True) + >>> result = thread.get() + + :param async bool + :param int page: + :param int per_page: + :param str authorization: + :param str date: + :param str signature: + :param str x_request_id: + :return: InlineResponse200 + If the method is called asynchronously, + returns the request thread. + """ + + all_params = ['page', 'per_page', 'authorization', 'date', 'signature', 'x_request_id'] # noqa: E501 + all_params.append('async') + all_params.append('_return_http_data_only') + all_params.append('_preload_content') + all_params.append('_request_timeout') + + params = locals() + for key, val in six.iteritems(params['kwargs']): + if key not in all_params: + raise TypeError( + "Got an unexpected keyword argument '%s'" + " to method list" % key + ) + params[key] = val + del params['kwargs'] + + collection_formats = {} + + path_params = {} + + query_params = [] + if 'page' in params: + query_params.append(('page', params['page'])) # noqa: E501 + if 'per_page' in params: + query_params.append(('per_page', params['per_page'])) # noqa: E501 + + header_params = {} + if 'authorization' in params: + header_params['Authorization'] = params['authorization'] # noqa: E501 + if 'date' in params: + header_params['Date'] = params['date'] # noqa: E501 + if 'signature' in params: + header_params['Signature'] = params['signature'] # noqa: E501 + if 'x_request_id' in params: + header_params['X-Request-Id'] = params['x_request_id'] # noqa: E501 + + form_params = [] + local_var_files = {} + + body_params = None + # HTTP header `Accept` + header_params['Accept'] = self.api_client.select_header_accept( + ['application/json']) # noqa: E501 + + # HTTP header `Content-Type` + header_params['Content-Type'] = self.api_client.select_header_content_type( # noqa: E501 + ['application/json']) # noqa: E501 + + # Authentication setting + auth_settings = ['Application'] # noqa: E501 + + return self.api_client.call_api( + '/users', 'GET', + path_params, + query_params, + header_params, + body=body_params, + post_params=form_params, + files=local_var_files, + response_type='InlineResponse200', # noqa: E501 + auth_settings=auth_settings, + async=params.get('async'), + _return_http_data_only=params.get('_return_http_data_only'), + _preload_content=params.get('_preload_content', True), + _request_timeout=params.get('_request_timeout'), + collection_formats=collection_formats) diff --git a/banking_client/api_client.py b/banking_client/api_client.py new file mode 100644 index 0000000..cf2a646 --- /dev/null +++ b/banking_client/api_client.py @@ -0,0 +1,631 @@ +# coding: utf-8 +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + +from __future__ import absolute_import + +import datetime +import json +import mimetypes +from multiprocessing.pool import ThreadPool +import os +import re +import tempfile + +# python 2 and python 3 compatibility library +import six +import httpsig +from six.moves.urllib.parse import quote + +from banking_client.configuration import Configuration +import banking_client.models +from banking_client import rest + + +class ApiClient(object): + """Generic API client. + + This client handles the client-server communication, and is invariant + across implementations. Specifics of the methods and models for each + application are generated from the templates. + + This class is auto generated, do not edit the class manually. + + :param configuration: .Configuration object for this client + :param header_name: a header to pass when making calls to the API. + :param header_value: a header value to pass when making calls to + the API. + :param cookie: a cookie to include in the header when making calls + to the API + """ + + PRIMITIVE_TYPES = (float, bool, bytes, six.text_type) + six.integer_types + NATIVE_TYPES_MAPPING = { + 'int': int, + 'long': int if six.PY3 else long, # noqa: F821 + 'float': float, + 'str': str, + 'bool': bool, + 'date': datetime.date, + 'datetime': datetime.datetime, + 'object': object, + } + + def __init__(self, configuration=None, header_name=None, header_value=None, + cookie=None): + if configuration is None: + configuration = Configuration() + self.configuration = configuration + + self.pool = ThreadPool() + self.rest_client = rest.RESTClientObject(configuration) + self.default_headers = {} + if header_name is not None: + self.default_headers[header_name] = header_value + self.cookie = cookie + # Set default User-Agent. + self.user_agent = 'banking-client/1.0.0/python' + + def __del__(self): + self.pool.close() + self.pool.join() + + @property + def user_agent(self): + """User agent for this API client""" + return self.default_headers['User-Agent'] + + @user_agent.setter + def user_agent(self, value): + self.default_headers['User-Agent'] = value + + def set_default_header(self, header_name, header_value): + self.default_headers[header_name] = header_value + + def __call_api( + self, resource_path, method, path_params=None, + query_params=None, header_params=None, body=None, post_params=None, + files=None, response_type=None, auth_settings=None, + _return_http_data_only=None, collection_formats=None, + _preload_content=True, _request_timeout=None): + + config = self.configuration + + # header parameters + header_params = header_params or {} + header_params.update(self.default_headers) + if self.cookie: + header_params['Cookie'] = self.cookie + if header_params: + header_params = self.sanitize_for_serialization(header_params) + header_params = dict(self.parameters_to_tuples(header_params, + collection_formats)) + + # path parameters + if path_params: + path_params = self.sanitize_for_serialization(path_params) + path_params = self.parameters_to_tuples(path_params, + collection_formats) + for k, v in path_params: + # specified safe chars, encode everything + resource_path = resource_path.replace( + '{%s}' % k, + quote(str(v), safe=config.safe_chars_for_path_param) + ) + + # query parameters + if query_params: + query_params = self.sanitize_for_serialization(query_params) + query_params = self.parameters_to_tuples(query_params, + collection_formats) + + # post parameters + if post_params or files: + post_params = self.prepare_post_parameters(post_params, files) + post_params = self.sanitize_for_serialization(post_params) + post_params = self.parameters_to_tuples(post_params, + collection_formats) + + auth = self.configuration.auth_settings()['Application'] + key_id = auth['token'] + secret = auth['secret'] + algorithm = 'hmac-sha256' + date = datetime.datetime.utcnow().isoformat() + 'Z' + signed_headers = ['date'] + hs = httpsig.HeaderSigner(key_id, secret, algorithm=algorithm, headers=signed_headers) + hs.signature_template = 'keyId="{}",algorithm="{}",signature="%s",headers="{}"'.format( + key_id, algorithm, ' '.join(signed_headers)) + signature = hs.sign({'Date': date,}) + header_params['Signature'] = signature['authorization'] + header_params['Date'] = date + + # auth setting + self.update_params_for_auth(header_params, query_params, auth_settings) + + # body + if body: + body = self.sanitize_for_serialization(body) + + # request url + url = self.configuration.host + resource_path + + # perform request and return response + response_data = self.request( + method, url, query_params=query_params, headers=header_params, + post_params=post_params, body=body, + _preload_content=_preload_content, + _request_timeout=_request_timeout) + + self.last_response = response_data + + return_data = response_data + if _preload_content: + # deserialize response data + if response_type: + return_data = self.deserialize(response_data, response_type) + else: + return_data = None + + if _return_http_data_only: + return (return_data) + else: + return (return_data, response_data.status, + response_data.getheaders()) + + def sanitize_for_serialization(self, obj): + """Builds a JSON POST object. + + If obj is None, return None. + If obj is str, int, long, float, bool, return directly. + If obj is datetime.datetime, datetime.date + convert to string in iso8601 format. + If obj is list, sanitize each element in the list. + If obj is dict, return the dict. + If obj is model, return the properties dict. + + :param obj: The data to serialize. + :return: The serialized form of data. + """ + if obj is None: + return None + elif isinstance(obj, self.PRIMITIVE_TYPES): + return obj + elif isinstance(obj, list): + return [self.sanitize_for_serialization(sub_obj) + for sub_obj in obj] + elif isinstance(obj, tuple): + return tuple(self.sanitize_for_serialization(sub_obj) + for sub_obj in obj) + elif isinstance(obj, (datetime.datetime, datetime.date)): + return obj.isoformat() + + if isinstance(obj, dict): + obj_dict = obj + else: + # Convert model obj to dict except + # attributes `swagger_types`, `attribute_map` + # and attributes which value is not None. + # Convert attribute name to json key in + # model definition for request. + obj_dict = {obj.attribute_map[attr]: getattr(obj, attr) + for attr, _ in six.iteritems(obj.swagger_types) + if getattr(obj, attr) is not None} + + return {key: self.sanitize_for_serialization(val) + for key, val in six.iteritems(obj_dict)} + + def deserialize(self, response, response_type): + """Deserializes response into an object. + + :param response: RESTResponse object to be deserialized. + :param response_type: class literal for + deserialized object, or string of class name. + + :return: deserialized object. + """ + # handle file downloading + # save response body into a tmp file and return the instance + if response_type == "file": + return self.__deserialize_file(response) + + # fetch data from response object + try: + data = json.loads(response.data) + except ValueError: + data = response.data + + return self.__deserialize(data, response_type) + + def __deserialize(self, data, klass): + """Deserializes dict, list, str into an object. + + :param data: dict, list or str. + :param klass: class literal, or string of class name. + + :return: object. + """ + if data is None: + return None + + if type(klass) == str: + if klass.startswith('list['): + sub_kls = re.match('list\[(.*)\]', klass).group(1) + return [self.__deserialize(sub_data, sub_kls) + for sub_data in data] + + if klass.startswith('dict('): + sub_kls = re.match('dict\(([^,]*), (.*)\)', klass).group(2) + return {k: self.__deserialize(v, sub_kls) + for k, v in six.iteritems(data)} + + # convert str to class + if klass in self.NATIVE_TYPES_MAPPING: + klass = self.NATIVE_TYPES_MAPPING[klass] + else: + klass = getattr(banking_client.models, klass) + + if klass in self.PRIMITIVE_TYPES: + return self.__deserialize_primitive(data, klass) + elif klass == object: + return self.__deserialize_object(data) + elif klass == datetime.date: + return self.__deserialize_date(data) + elif klass == datetime.datetime: + return self.__deserialize_datatime(data) + else: + return self.__deserialize_model(data, klass) + + def call_api(self, resource_path, method, + path_params=None, query_params=None, header_params=None, + body=None, post_params=None, files=None, + response_type=None, auth_settings=None, async=None, + _return_http_data_only=None, collection_formats=None, + _preload_content=True, _request_timeout=None): + """Makes the HTTP request (synchronous) and returns deserialized data. + + To make an async request, set the async parameter. + + :param resource_path: Path to method endpoint. + :param method: Method to call. + :param path_params: Path parameters in the url. + :param query_params: Query parameters in the url. + :param header_params: Header parameters to be + placed in the request header. + :param body: Request body. + :param post_params dict: Request post form parameters, + for `application/x-www-form-urlencoded`, `multipart/form-data`. + :param auth_settings list: Auth Settings names for the request. + :param response: Response data type. + :param files dict: key -> filename, value -> filepath, + for `multipart/form-data`. + :param async bool: execute request asynchronously + :param _return_http_data_only: response data without head status code + and headers + :param collection_formats: dict of collection formats for path, query, + header, and post parameters. + :param _preload_content: if False, the urllib3.HTTPResponse object will + be returned without reading/decoding response + data. Default is True. + :param _request_timeout: timeout setting for this request. If one + number provided, it will be total request + timeout. It can also be a pair (tuple) of + (connection, read) timeouts. + :return: + If async parameter is True, + the request will be called asynchronously. + The method will return the request thread. + If parameter async is False or missing, + then the method will return the response directly. + """ + if not async: + return self.__call_api(resource_path, method, + path_params, query_params, header_params, + body, post_params, files, + response_type, auth_settings, + _return_http_data_only, collection_formats, + _preload_content, _request_timeout) + else: + thread = self.pool.apply_async(self.__call_api, (resource_path, + method, path_params, query_params, + header_params, body, + post_params, files, + response_type, auth_settings, + _return_http_data_only, + collection_formats, + _preload_content, _request_timeout)) + return thread + + def request(self, method, url, query_params=None, headers=None, + post_params=None, body=None, _preload_content=True, + _request_timeout=None): + """Makes the HTTP request using RESTClient.""" + if method == "GET": + return self.rest_client.GET(url, + query_params=query_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + headers=headers) + elif method == "HEAD": + return self.rest_client.HEAD(url, + query_params=query_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + headers=headers) + elif method == "OPTIONS": + return self.rest_client.OPTIONS(url, + query_params=query_params, + headers=headers, + post_params=post_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + elif method == "POST": + return self.rest_client.POST(url, + query_params=query_params, + headers=headers, + post_params=post_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + elif method == "PUT": + return self.rest_client.PUT(url, + query_params=query_params, + headers=headers, + post_params=post_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + elif method == "PATCH": + return self.rest_client.PATCH(url, + query_params=query_params, + headers=headers, + post_params=post_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + elif method == "DELETE": + return self.rest_client.DELETE(url, + query_params=query_params, + headers=headers, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + else: + raise ValueError( + "http method must be `GET`, `HEAD`, `OPTIONS`," + " `POST`, `PATCH`, `PUT` or `DELETE`." + ) + + def parameters_to_tuples(self, params, collection_formats): + """Get parameters as list of tuples, formatting collections. + + :param params: Parameters as dict or list of two-tuples + :param dict collection_formats: Parameter collection formats + :return: Parameters as list of tuples, collections formatted + """ + new_params = [] + if collection_formats is None: + collection_formats = {} + for k, v in six.iteritems(params) if isinstance(params, dict) else params: # noqa: E501 + if k in collection_formats: + collection_format = collection_formats[k] + if collection_format == 'multi': + new_params.extend((k, value) for value in v) + else: + if collection_format == 'ssv': + delimiter = ' ' + elif collection_format == 'tsv': + delimiter = '\t' + elif collection_format == 'pipes': + delimiter = '|' + else: # csv is the default + delimiter = ',' + new_params.append( + (k, delimiter.join(str(value) for value in v))) + else: + new_params.append((k, v)) + return new_params + + def prepare_post_parameters(self, post_params=None, files=None): + """Builds form parameters. + + :param post_params: Normal form parameters. + :param files: File parameters. + :return: Form parameters with files. + """ + params = [] + + if post_params: + params = post_params + + if files: + for k, v in six.iteritems(files): + if not v: + continue + file_names = v if type(v) is list else [v] + for n in file_names: + with open(n, 'rb') as f: + filename = os.path.basename(f.name) + filedata = f.read() + mimetype = (mimetypes.guess_type(filename)[0] or + 'application/octet-stream') + params.append( + tuple([k, tuple([filename, filedata, mimetype])])) + + return params + + def select_header_accept(self, accepts): + """Returns `Accept` based on an array of accepts provided. + + :param accepts: List of headers. + :return: Accept (e.g. application/json). + """ + if not accepts: + return + + accepts = [x.lower() for x in accepts] + + if 'application/json' in accepts: + return 'application/json' + else: + return ', '.join(accepts) + + def select_header_content_type(self, content_types): + """Returns `Content-Type` based on an array of content_types provided. + + :param content_types: List of content-types. + :return: Content-Type (e.g. application/json). + """ + if not content_types: + return 'application/json' + + content_types = [x.lower() for x in content_types] + + if 'application/json' in content_types or '*/*' in content_types: + return 'application/json' + else: + return content_types[0] + + def update_params_for_auth(self, headers, querys, auth_settings): + """Updates header and query params based on authentication setting. + + :param headers: Header parameters dict to be updated. + :param querys: Query parameters tuple list to be updated. + :param auth_settings: Authentication setting identifiers list. + """ + if not auth_settings: + return + + for auth in auth_settings: + auth_setting = self.configuration.auth_settings().get(auth) + if auth_setting: + if not auth_setting['value']: + continue + elif auth_setting['in'] == 'header': + headers[auth_setting['key']] = auth_setting['value'] + elif auth_setting['in'] == 'query': + querys.append((auth_setting['key'], auth_setting['value'])) + else: + raise ValueError( + 'Authentication token must be in `query` or `header`' + ) + + def __deserialize_file(self, response): + """Deserializes body to file + + Saves response body into a file in a temporary folder, + using the filename from the `Content-Disposition` header if provided. + + :param response: RESTResponse. + :return: file path. + """ + fd, path = tempfile.mkstemp(dir=self.configuration.temp_folder_path) + os.close(fd) + os.remove(path) + + content_disposition = response.getheader("Content-Disposition") + if content_disposition: + filename = re.search(r'filename=[\'"]?([^\'"\s]+)[\'"]?', + content_disposition).group(1) + path = os.path.join(os.path.dirname(path), filename) + + with open(path, "w") as f: + f.write(response.data) + + return path + + def __deserialize_primitive(self, data, klass): + """Deserializes string to primitive type. + + :param data: str. + :param klass: class literal. + + :return: int, long, float, str, bool. + """ + try: + return klass(data) + except UnicodeEncodeError: + return six.u(data) + except TypeError: + return data + + def __deserialize_object(self, value): + """Return a original value. + + :return: object. + """ + return value + + def __deserialize_date(self, string): + """Deserializes string to date. + + :param string: str. + :return: date. + """ + try: + from dateutil.parser import parse + return parse(string).date() + except ImportError: + return string + except ValueError: + raise rest.ApiException( + status=0, + reason="Failed to parse `{0}` as date object".format(string) + ) + + def __deserialize_datatime(self, string): + """Deserializes string to datetime. + + The string should be in iso8601 datetime format. + + :param string: str. + :return: datetime. + """ + try: + from dateutil.parser import parse + return parse(string) + except ImportError: + return string + except ValueError: + raise rest.ApiException( + status=0, + reason=( + "Failed to parse `{0}` as datetime object" + .format(string) + ) + ) + + def __deserialize_model(self, data, klass): + """Deserializes list or dict to model. + + :param data: dict, list. + :param klass: class literal. + :return: model object. + """ + + if not klass.swagger_types and not hasattr(klass, + 'get_real_child_model'): + return data + + kwargs = {} + if klass.swagger_types is not None: + for attr, attr_type in six.iteritems(klass.swagger_types): + if (data is not None and + klass.attribute_map[attr] in data and + isinstance(data, (list, dict))): + value = data[klass.attribute_map[attr]] + kwargs[attr] = self.__deserialize(value, attr_type) + + instance = klass(**kwargs) + + if hasattr(instance, 'get_real_child_model'): + klass_name = instance.get_real_child_model(data) + if klass_name: + instance = self.__deserialize(data, klass_name) + return instance diff --git a/banking_client/configuration.py b/banking_client/configuration.py new file mode 100644 index 0000000..096028a --- /dev/null +++ b/banking_client/configuration.py @@ -0,0 +1,251 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +import copy +import logging +import multiprocessing +import sys +import urllib3 + +import six +from six.moves import http_client as httplib + + +class TypeWithDefault(type): + def __init__(cls, name, bases, dct): + super(TypeWithDefault, cls).__init__(name, bases, dct) + cls._default = None + + def __call__(cls): + if cls._default is None: + cls._default = type.__call__(cls) + return copy.copy(cls._default) + + def set_default(cls, default): + cls._default = copy.copy(default) + + +class Configuration(six.with_metaclass(TypeWithDefault, object)): + """ + This class is auto generated, do not edit the class manually. + """ + + def __init__(self): + """Constructor""" + # Default Base url + self.host = "https://api.example.com/v1" + # Temp file folder for downloading files + self.temp_folder_path = None + + # Authentication Settings + # dict to store API key(s) + self.api_key = {} + # dict to store API prefix (e.g. Bearer) + self.api_key_prefix = {} + # Username for HTTP basic authentication + self.username = "" + # Password for HTTP basic authentication + self.password = "" + + # access token for OAuth + self.access_token = "" + self.secret = "" + + # Logging Settings + self.logger = {} + self.logger["package_logger"] = logging.getLogger("banking_client") + self.logger["urllib3_logger"] = logging.getLogger("urllib3") + # Log format + self.logger_format = '%(asctime)s %(levelname)s %(message)s' + # Log stream handler + self.logger_stream_handler = None + # Log file handler + self.logger_file_handler = None + # Debug file location + self.logger_file = None + # Debug switch + self.debug = False + + # SSL/TLS verification + # Set this to false to skip verifying SSL certificate when calling API + # from https server. + self.verify_ssl = True + # Set this to customize the certificate file to verify the peer. + self.ssl_ca_cert = None + # client certificate file + self.cert_file = None + # client key file + self.key_file = None + # Set this to True/False to enable/disable SSL hostname verification. + self.assert_hostname = None + + # urllib3 connection pool's maximum number of connections saved + # per pool. urllib3 uses 1 connection as default value, but this is + # not the best value when you are making a lot of possibly parallel + # requests to the same host, which is often the case here. + # cpu_count * 5 is used as default value to increase performance. + self.connection_pool_maxsize = multiprocessing.cpu_count() * 5 + + # Proxy URL + self.proxy = None + # Safe chars for path_param + self.safe_chars_for_path_param = '' + + @property + def logger_file(self): + """The logger file. + + If the logger_file is None, then add stream handler and remove file + handler. Otherwise, add file handler and remove stream handler. + + :param value: The logger_file path. + :type: str + """ + return self.__logger_file + + @logger_file.setter + def logger_file(self, value): + """The logger file. + + If the logger_file is None, then add stream handler and remove file + handler. Otherwise, add file handler and remove stream handler. + + :param value: The logger_file path. + :type: str + """ + self.__logger_file = value + if self.__logger_file: + # If set logging file, + # then add file handler and remove stream handler. + self.logger_file_handler = logging.FileHandler(self.__logger_file) + self.logger_file_handler.setFormatter(self.logger_formatter) + for _, logger in six.iteritems(self.logger): + logger.addHandler(self.logger_file_handler) + if self.logger_stream_handler: + logger.removeHandler(self.logger_stream_handler) + else: + # If not set logging file, + # then add stream handler and remove file handler. + self.logger_stream_handler = logging.StreamHandler() + self.logger_stream_handler.setFormatter(self.logger_formatter) + for _, logger in six.iteritems(self.logger): + logger.addHandler(self.logger_stream_handler) + if self.logger_file_handler: + logger.removeHandler(self.logger_file_handler) + + @property + def debug(self): + """Debug status + + :param value: The debug status, True or False. + :type: bool + """ + return self.__debug + + @debug.setter + def debug(self, value): + """Debug status + + :param value: The debug status, True or False. + :type: bool + """ + self.__debug = value + if self.__debug: + # if debug status is True, turn on debug logging + for _, logger in six.iteritems(self.logger): + logger.setLevel(logging.DEBUG) + # turn on httplib debug + httplib.HTTPConnection.debuglevel = 1 + else: + # if debug status is False, turn off debug logging, + # setting log level to default `logging.WARNING` + for _, logger in six.iteritems(self.logger): + logger.setLevel(logging.WARNING) + # turn off httplib debug + httplib.HTTPConnection.debuglevel = 0 + + @property + def logger_format(self): + """The logger format. + + The logger_formatter will be updated when sets logger_format. + + :param value: The format string. + :type: str + """ + return self.__logger_format + + @logger_format.setter + def logger_format(self, value): + """The logger format. + + The logger_formatter will be updated when sets logger_format. + + :param value: The format string. + :type: str + """ + self.__logger_format = value + self.logger_formatter = logging.Formatter(self.__logger_format) + + def get_api_key_with_prefix(self, identifier): + """Gets API key (with prefix if set). + + :param identifier: The identifier of apiKey. + :return: The token for api key authentication. + """ + if (self.api_key.get(identifier) and + self.api_key_prefix.get(identifier)): + return self.api_key_prefix[identifier] + ' ' + self.api_key[identifier] # noqa: E501 + elif self.api_key.get(identifier): + return self.api_key[identifier] + + def get_basic_auth_token(self): + """Gets HTTP basic authentication header (string). + + :return: The token for basic HTTP authentication. + """ + return urllib3.util.make_headers( + basic_auth=self.username + ':' + self.password + ).get('authorization') + + def auth_settings(self): + """Gets Auth Settings dict for api client. + + :return: The Auth Settings information dict. + """ + return { + + 'Application': + { + 'type': 'oauth2', + 'in': 'header', + 'key': 'Authorization', + 'value': 'Bearer ' + self.access_token, + 'token': self.access_token, + 'secret': self.secret + }, + + } + + def to_debug_report(self): + """Gets the essential information for debugging. + + :return: The report for debugging. + """ + return "Python SDK Debug Report:\n"\ + "OS: {env}\n"\ + "Python Version: {pyversion}\n"\ + "Version of the API: 0.1.0\n"\ + "SDK Package Version: 1.0.0".\ + format(env=sys.platform, pyversion=sys.version) diff --git a/banking_client/models/__init__.py b/banking_client/models/__init__.py new file mode 100644 index 0000000..eb39789 --- /dev/null +++ b/banking_client/models/__init__.py @@ -0,0 +1,41 @@ +# coding: utf-8 + +# flake8: noqa +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +# import models into model package +from banking_client.models.account import Account +from banking_client.models.account_balances import AccountBalances +from banking_client.models.address import Address +from banking_client.models.check import Check +from banking_client.models.document import Document +from banking_client.models.error import Error +from banking_client.models.inline_response_200 import InlineResponse200 +from banking_client.models.inline_response_200_1 import InlineResponse2001 +from banking_client.models.inline_response_200_2 import InlineResponse2002 +from banking_client.models.inline_response_200_3 import InlineResponse2003 +from banking_client.models.inline_response_200_4 import InlineResponse2004 +from banking_client.models.inline_response_200_5 import InlineResponse2005 +from banking_client.models.inline_response_200_6 import InlineResponse2006 +from banking_client.models.inline_response_200_7 import InlineResponse2007 +from banking_client.models.inline_response_200_8 import InlineResponse2008 +from banking_client.models.inline_response_201 import InlineResponse201 +from banking_client.models.links import Links +from banking_client.models.location import Location +from banking_client.models.membership import Membership +from banking_client.models.meta import Meta +from banking_client.models.phone import Phone +from banking_client.models.subscription import Subscription +from banking_client.models.transaction import Transaction +from banking_client.models.transfer import Transfer +from banking_client.models.user import User diff --git a/banking_client/models/account.py b/banking_client/models/account.py new file mode 100644 index 0000000..992174c --- /dev/null +++ b/banking_client/models/account.py @@ -0,0 +1,298 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.user import User # noqa: F401,E501 + + +class Account(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'id': 'str', + 'name': 'str', + 'number': 'str', + 'type': 'str', + 'updated_at': 'datetime', + 'users': 'list[User]', + 'features': 'list[str]', + 'routing': 'str' + } + + attribute_map = { + 'id': 'id', + 'name': 'name', + 'number': 'number', + 'type': 'type', + 'updated_at': 'updated_at', + 'users': 'users', + 'features': 'features', + 'routing': 'routing' + } + + def __init__(self, id=None, name=None, number=None, type=None, updated_at=None, users=None, features=None, routing=None): # noqa: E501 + """Account - a model defined in Swagger""" # noqa: E501 + + self._id = None + self._name = None + self._number = None + self._type = None + self._updated_at = None + self._users = None + self._features = None + self._routing = None + self.discriminator = None + + if id is not None: + self.id = id + if name is not None: + self.name = name + if number is not None: + self.number = number + if type is not None: + self.type = type + if updated_at is not None: + self.updated_at = updated_at + if users is not None: + self.users = users + if features is not None: + self.features = features + if routing is not None: + self.routing = routing + + @property + def id(self): + """Gets the id of this Account. # noqa: E501 + + Unique account identifier # noqa: E501 + + :return: The id of this Account. # noqa: E501 + :rtype: str + """ + return self._id + + @id.setter + def id(self, id): + """Sets the id of this Account. + + Unique account identifier # noqa: E501 + + :param id: The id of this Account. # noqa: E501 + :type: str + """ + + self._id = id + + @property + def name(self): + """Gets the name of this Account. # noqa: E501 + + + :return: The name of this Account. # noqa: E501 + :rtype: str + """ + return self._name + + @name.setter + def name(self, name): + """Sets the name of this Account. + + + :param name: The name of this Account. # noqa: E501 + :type: str + """ + + self._name = name + + @property + def number(self): + """Gets the number of this Account. # noqa: E501 + + + :return: The number of this Account. # noqa: E501 + :rtype: str + """ + return self._number + + @number.setter + def number(self, number): + """Sets the number of this Account. + + + :param number: The number of this Account. # noqa: E501 + :type: str + """ + + self._number = number + + @property + def type(self): + """Gets the type of this Account. # noqa: E501 + + + :return: The type of this Account. # noqa: E501 + :rtype: str + """ + return self._type + + @type.setter + def type(self, type): + """Sets the type of this Account. + + + :param type: The type of this Account. # noqa: E501 + :type: str + """ + + self._type = type + + @property + def updated_at(self): + """Gets the updated_at of this Account. # noqa: E501 + + + :return: The updated_at of this Account. # noqa: E501 + :rtype: datetime + """ + return self._updated_at + + @updated_at.setter + def updated_at(self, updated_at): + """Sets the updated_at of this Account. + + + :param updated_at: The updated_at of this Account. # noqa: E501 + :type: datetime + """ + + self._updated_at = updated_at + + @property + def users(self): + """Gets the users of this Account. # noqa: E501 + + + :return: The users of this Account. # noqa: E501 + :rtype: list[User] + """ + return self._users + + @users.setter + def users(self, users): + """Sets the users of this Account. + + + :param users: The users of this Account. # noqa: E501 + :type: list[User] + """ + + self._users = users + + @property + def features(self): + """Gets the features of this Account. # noqa: E501 + + + :return: The features of this Account. # noqa: E501 + :rtype: list[str] + """ + return self._features + + @features.setter + def features(self, features): + """Sets the features of this Account. + + + :param features: The features of this Account. # noqa: E501 + :type: list[str] + """ + + self._features = features + + @property + def routing(self): + """Gets the routing of this Account. # noqa: E501 + + The ABA number associated with the account. # noqa: E501 + + :return: The routing of this Account. # noqa: E501 + :rtype: str + """ + return self._routing + + @routing.setter + def routing(self, routing): + """Sets the routing of this Account. + + The ABA number associated with the account. # noqa: E501 + + :param routing: The routing of this Account. # noqa: E501 + :type: str + """ + + self._routing = routing + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Account): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/account_balances.py b/banking_client/models/account_balances.py new file mode 100644 index 0000000..ec6b2c3 --- /dev/null +++ b/banking_client/models/account_balances.py @@ -0,0 +1,240 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class AccountBalances(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'id': 'str', + 'account_id': 'str', + 'primary': 'int', + 'available': 'int', + 'ledger': 'int', + 'updated_at': 'datetime' + } + + attribute_map = { + 'id': 'id', + 'account_id': 'account_id', + 'primary': 'primary', + 'available': 'available', + 'ledger': 'ledger', + 'updated_at': 'updated_at' + } + + def __init__(self, id=None, account_id=None, primary=None, available=None, ledger=None, updated_at=None): # noqa: E501 + """AccountBalances - a model defined in Swagger""" # noqa: E501 + + self._id = None + self._account_id = None + self._primary = None + self._available = None + self._ledger = None + self._updated_at = None + self.discriminator = None + + if id is not None: + self.id = id + if account_id is not None: + self.account_id = account_id + if primary is not None: + self.primary = primary + if available is not None: + self.available = available + if ledger is not None: + self.ledger = ledger + if updated_at is not None: + self.updated_at = updated_at + + @property + def id(self): + """Gets the id of this AccountBalances. # noqa: E501 + + + :return: The id of this AccountBalances. # noqa: E501 + :rtype: str + """ + return self._id + + @id.setter + def id(self, id): + """Sets the id of this AccountBalances. + + + :param id: The id of this AccountBalances. # noqa: E501 + :type: str + """ + + self._id = id + + @property + def account_id(self): + """Gets the account_id of this AccountBalances. # noqa: E501 + + + :return: The account_id of this AccountBalances. # noqa: E501 + :rtype: str + """ + return self._account_id + + @account_id.setter + def account_id(self, account_id): + """Sets the account_id of this AccountBalances. + + + :param account_id: The account_id of this AccountBalances. # noqa: E501 + :type: str + """ + + self._account_id = account_id + + @property + def primary(self): + """Gets the primary of this AccountBalances. # noqa: E501 + + + :return: The primary of this AccountBalances. # noqa: E501 + :rtype: int + """ + return self._primary + + @primary.setter + def primary(self, primary): + """Sets the primary of this AccountBalances. + + + :param primary: The primary of this AccountBalances. # noqa: E501 + :type: int + """ + + self._primary = primary + + @property + def available(self): + """Gets the available of this AccountBalances. # noqa: E501 + + + :return: The available of this AccountBalances. # noqa: E501 + :rtype: int + """ + return self._available + + @available.setter + def available(self, available): + """Sets the available of this AccountBalances. + + + :param available: The available of this AccountBalances. # noqa: E501 + :type: int + """ + + self._available = available + + @property + def ledger(self): + """Gets the ledger of this AccountBalances. # noqa: E501 + + + :return: The ledger of this AccountBalances. # noqa: E501 + :rtype: int + """ + return self._ledger + + @ledger.setter + def ledger(self, ledger): + """Sets the ledger of this AccountBalances. + + + :param ledger: The ledger of this AccountBalances. # noqa: E501 + :type: int + """ + + self._ledger = ledger + + @property + def updated_at(self): + """Gets the updated_at of this AccountBalances. # noqa: E501 + + + :return: The updated_at of this AccountBalances. # noqa: E501 + :rtype: datetime + """ + return self._updated_at + + @updated_at.setter + def updated_at(self, updated_at): + """Sets the updated_at of this AccountBalances. + + + :param updated_at: The updated_at of this AccountBalances. # noqa: E501 + :type: datetime + """ + + self._updated_at = updated_at + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, AccountBalances): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/address.py b/banking_client/models/address.py new file mode 100644 index 0000000..a8ea9bf --- /dev/null +++ b/banking_client/models/address.py @@ -0,0 +1,214 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Address(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'street_address': 'str', + 'street_address_2': 'str', + 'city': 'str', + 'region_code': 'str', + 'postal_code': 'str' + } + + attribute_map = { + 'street_address': 'street_address', + 'street_address_2': 'street_address_2', + 'city': 'city', + 'region_code': 'region_code', + 'postal_code': 'postal_code' + } + + def __init__(self, street_address=None, street_address_2=None, city=None, region_code=None, postal_code=None): # noqa: E501 + """Address - a model defined in Swagger""" # noqa: E501 + + self._street_address = None + self._street_address_2 = None + self._city = None + self._region_code = None + self._postal_code = None + self.discriminator = None + + if street_address is not None: + self.street_address = street_address + if street_address_2 is not None: + self.street_address_2 = street_address_2 + if city is not None: + self.city = city + if region_code is not None: + self.region_code = region_code + if postal_code is not None: + self.postal_code = postal_code + + @property + def street_address(self): + """Gets the street_address of this Address. # noqa: E501 + + + :return: The street_address of this Address. # noqa: E501 + :rtype: str + """ + return self._street_address + + @street_address.setter + def street_address(self, street_address): + """Sets the street_address of this Address. + + + :param street_address: The street_address of this Address. # noqa: E501 + :type: str + """ + + self._street_address = street_address + + @property + def street_address_2(self): + """Gets the street_address_2 of this Address. # noqa: E501 + + + :return: The street_address_2 of this Address. # noqa: E501 + :rtype: str + """ + return self._street_address_2 + + @street_address_2.setter + def street_address_2(self, street_address_2): + """Sets the street_address_2 of this Address. + + + :param street_address_2: The street_address_2 of this Address. # noqa: E501 + :type: str + """ + + self._street_address_2 = street_address_2 + + @property + def city(self): + """Gets the city of this Address. # noqa: E501 + + + :return: The city of this Address. # noqa: E501 + :rtype: str + """ + return self._city + + @city.setter + def city(self, city): + """Sets the city of this Address. + + + :param city: The city of this Address. # noqa: E501 + :type: str + """ + + self._city = city + + @property + def region_code(self): + """Gets the region_code of this Address. # noqa: E501 + + + :return: The region_code of this Address. # noqa: E501 + :rtype: str + """ + return self._region_code + + @region_code.setter + def region_code(self, region_code): + """Sets the region_code of this Address. + + + :param region_code: The region_code of this Address. # noqa: E501 + :type: str + """ + + self._region_code = region_code + + @property + def postal_code(self): + """Gets the postal_code of this Address. # noqa: E501 + + + :return: The postal_code of this Address. # noqa: E501 + :rtype: str + """ + return self._postal_code + + @postal_code.setter + def postal_code(self, postal_code): + """Sets the postal_code of this Address. + + + :param postal_code: The postal_code of this Address. # noqa: E501 + :type: str + """ + + self._postal_code = postal_code + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Address): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/check.py b/banking_client/models/check.py new file mode 100644 index 0000000..9a8dac7 --- /dev/null +++ b/banking_client/models/check.py @@ -0,0 +1,112 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Check(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'number': 'str' + } + + attribute_map = { + 'number': 'number' + } + + def __init__(self, number=None): # noqa: E501 + """Check - a model defined in Swagger""" # noqa: E501 + + self._number = None + self.discriminator = None + + if number is not None: + self.number = number + + @property + def number(self): + """Gets the number of this Check. # noqa: E501 + + The identifier of the paper check. # noqa: E501 + + :return: The number of this Check. # noqa: E501 + :rtype: str + """ + return self._number + + @number.setter + def number(self, number): + """Sets the number of this Check. + + The identifier of the paper check. # noqa: E501 + + :param number: The number of this Check. # noqa: E501 + :type: str + """ + + self._number = number + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Check): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/document.py b/banking_client/models/document.py new file mode 100644 index 0000000..80adcf6 --- /dev/null +++ b/banking_client/models/document.py @@ -0,0 +1,140 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Document(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'id': 'str', + 'url': 'str' + } + + attribute_map = { + 'id': 'id', + 'url': 'url' + } + + def __init__(self, id=None, url=None): # noqa: E501 + """Document - a model defined in Swagger""" # noqa: E501 + + self._id = None + self._url = None + self.discriminator = None + + if id is not None: + self.id = id + if url is not None: + self.url = url + + @property + def id(self): + """Gets the id of this Document. # noqa: E501 + + Document ID # noqa: E501 + + :return: The id of this Document. # noqa: E501 + :rtype: str + """ + return self._id + + @id.setter + def id(self, id): + """Sets the id of this Document. + + Document ID # noqa: E501 + + :param id: The id of this Document. # noqa: E501 + :type: str + """ + + self._id = id + + @property + def url(self): + """Gets the url of this Document. # noqa: E501 + + An opaque URI identifying where the document is located # noqa: E501 + + :return: The url of this Document. # noqa: E501 + :rtype: str + """ + return self._url + + @url.setter + def url(self, url): + """Sets the url of this Document. + + An opaque URI identifying where the document is located # noqa: E501 + + :param url: The url of this Document. # noqa: E501 + :type: str + """ + + self._url = url + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Document): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/error.py b/banking_client/models/error.py new file mode 100644 index 0000000..28aebb3 --- /dev/null +++ b/banking_client/models/error.py @@ -0,0 +1,168 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Error(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'id': 'str', + 'message': 'str', + 'url': 'str' + } + + attribute_map = { + 'id': 'id', + 'message': 'message', + 'url': 'url' + } + + def __init__(self, id=None, message=None, url=None): # noqa: E501 + """Error - a model defined in Swagger""" # noqa: E501 + + self._id = None + self._message = None + self._url = None + self.discriminator = None + + if id is not None: + self.id = id + if message is not None: + self.message = message + if url is not None: + self.url = url + + @property + def id(self): + """Gets the id of this Error. # noqa: E501 + + id of error raised # noqa: E501 + + :return: The id of this Error. # noqa: E501 + :rtype: str + """ + return self._id + + @id.setter + def id(self, id): + """Sets the id of this Error. + + id of error raised # noqa: E501 + + :param id: The id of this Error. # noqa: E501 + :type: str + """ + + self._id = id + + @property + def message(self): + """Gets the message of this Error. # noqa: E501 + + description of error raised, formatted to be presentable to the end user # noqa: E501 + + :return: The message of this Error. # noqa: E501 + :rtype: str + """ + return self._message + + @message.setter + def message(self, message): + """Sets the message of this Error. + + description of error raised, formatted to be presentable to the end user # noqa: E501 + + :param message: The message of this Error. # noqa: E501 + :type: str + """ + + self._message = message + + @property + def url(self): + """Gets the url of this Error. # noqa: E501 + + reference url with more information about the error # noqa: E501 + + :return: The url of this Error. # noqa: E501 + :rtype: str + """ + return self._url + + @url.setter + def url(self, url): + """Sets the url of this Error. + + reference url with more information about the error # noqa: E501 + + :param url: The url of this Error. # noqa: E501 + :type: str + """ + + self._url = url + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Error): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200.py b/banking_client/models/inline_response_200.py new file mode 100644 index 0000000..a67a00c --- /dev/null +++ b/banking_client/models/inline_response_200.py @@ -0,0 +1,166 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.links import Links # noqa: F401,E501 +from banking_client.models.meta import Meta # noqa: F401,E501 +from banking_client.models.user import User # noqa: F401,E501 + + +class InlineResponse200(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'users': 'list[User]', + 'meta': 'Meta', + 'links': 'Links' + } + + attribute_map = { + 'users': 'users', + 'meta': 'meta', + 'links': 'links' + } + + def __init__(self, users=None, meta=None, links=None): # noqa: E501 + """InlineResponse200 - a model defined in Swagger""" # noqa: E501 + + self._users = None + self._meta = None + self._links = None + self.discriminator = None + + if users is not None: + self.users = users + if meta is not None: + self.meta = meta + if links is not None: + self.links = links + + @property + def users(self): + """Gets the users of this InlineResponse200. # noqa: E501 + + + :return: The users of this InlineResponse200. # noqa: E501 + :rtype: list[User] + """ + return self._users + + @users.setter + def users(self, users): + """Sets the users of this InlineResponse200. + + + :param users: The users of this InlineResponse200. # noqa: E501 + :type: list[User] + """ + + self._users = users + + @property + def meta(self): + """Gets the meta of this InlineResponse200. # noqa: E501 + + + :return: The meta of this InlineResponse200. # noqa: E501 + :rtype: Meta + """ + return self._meta + + @meta.setter + def meta(self, meta): + """Sets the meta of this InlineResponse200. + + + :param meta: The meta of this InlineResponse200. # noqa: E501 + :type: Meta + """ + + self._meta = meta + + @property + def links(self): + """Gets the links of this InlineResponse200. # noqa: E501 + + + :return: The links of this InlineResponse200. # noqa: E501 + :rtype: Links + """ + return self._links + + @links.setter + def links(self, links): + """Sets the links of this InlineResponse200. + + + :param links: The links of this InlineResponse200. # noqa: E501 + :type: Links + """ + + self._links = links + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse200): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200_1.py b/banking_client/models/inline_response_200_1.py new file mode 100644 index 0000000..54476f6 --- /dev/null +++ b/banking_client/models/inline_response_200_1.py @@ -0,0 +1,112 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.user import User # noqa: F401,E501 + + +class InlineResponse2001(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'user': 'User' + } + + attribute_map = { + 'user': 'user' + } + + def __init__(self, user=None): # noqa: E501 + """InlineResponse2001 - a model defined in Swagger""" # noqa: E501 + + self._user = None + self.discriminator = None + + if user is not None: + self.user = user + + @property + def user(self): + """Gets the user of this InlineResponse2001. # noqa: E501 + + + :return: The user of this InlineResponse2001. # noqa: E501 + :rtype: User + """ + return self._user + + @user.setter + def user(self, user): + """Sets the user of this InlineResponse2001. + + + :param user: The user of this InlineResponse2001. # noqa: E501 + :type: User + """ + + self._user = user + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse2001): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200_2.py b/banking_client/models/inline_response_200_2.py new file mode 100644 index 0000000..ea80b29 --- /dev/null +++ b/banking_client/models/inline_response_200_2.py @@ -0,0 +1,166 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.account import Account # noqa: F401,E501 +from banking_client.models.links import Links # noqa: F401,E501 +from banking_client.models.meta import Meta # noqa: F401,E501 + + +class InlineResponse2002(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'accounts': 'list[Account]', + 'meta': 'Meta', + 'links': 'Links' + } + + attribute_map = { + 'accounts': 'accounts', + 'meta': 'meta', + 'links': 'links' + } + + def __init__(self, accounts=None, meta=None, links=None): # noqa: E501 + """InlineResponse2002 - a model defined in Swagger""" # noqa: E501 + + self._accounts = None + self._meta = None + self._links = None + self.discriminator = None + + if accounts is not None: + self.accounts = accounts + if meta is not None: + self.meta = meta + if links is not None: + self.links = links + + @property + def accounts(self): + """Gets the accounts of this InlineResponse2002. # noqa: E501 + + + :return: The accounts of this InlineResponse2002. # noqa: E501 + :rtype: list[Account] + """ + return self._accounts + + @accounts.setter + def accounts(self, accounts): + """Sets the accounts of this InlineResponse2002. + + + :param accounts: The accounts of this InlineResponse2002. # noqa: E501 + :type: list[Account] + """ + + self._accounts = accounts + + @property + def meta(self): + """Gets the meta of this InlineResponse2002. # noqa: E501 + + + :return: The meta of this InlineResponse2002. # noqa: E501 + :rtype: Meta + """ + return self._meta + + @meta.setter + def meta(self, meta): + """Sets the meta of this InlineResponse2002. + + + :param meta: The meta of this InlineResponse2002. # noqa: E501 + :type: Meta + """ + + self._meta = meta + + @property + def links(self): + """Gets the links of this InlineResponse2002. # noqa: E501 + + + :return: The links of this InlineResponse2002. # noqa: E501 + :rtype: Links + """ + return self._links + + @links.setter + def links(self, links): + """Sets the links of this InlineResponse2002. + + + :param links: The links of this InlineResponse2002. # noqa: E501 + :type: Links + """ + + self._links = links + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse2002): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200_3.py b/banking_client/models/inline_response_200_3.py new file mode 100644 index 0000000..3b9e2c7 --- /dev/null +++ b/banking_client/models/inline_response_200_3.py @@ -0,0 +1,112 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.account import Account # noqa: F401,E501 + + +class InlineResponse2003(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'account': 'Account' + } + + attribute_map = { + 'account': 'account' + } + + def __init__(self, account=None): # noqa: E501 + """InlineResponse2003 - a model defined in Swagger""" # noqa: E501 + + self._account = None + self.discriminator = None + + if account is not None: + self.account = account + + @property + def account(self): + """Gets the account of this InlineResponse2003. # noqa: E501 + + + :return: The account of this InlineResponse2003. # noqa: E501 + :rtype: Account + """ + return self._account + + @account.setter + def account(self, account): + """Sets the account of this InlineResponse2003. + + + :param account: The account of this InlineResponse2003. # noqa: E501 + :type: Account + """ + + self._account = account + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse2003): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200_4.py b/banking_client/models/inline_response_200_4.py new file mode 100644 index 0000000..6daa11c --- /dev/null +++ b/banking_client/models/inline_response_200_4.py @@ -0,0 +1,166 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.links import Links # noqa: F401,E501 +from banking_client.models.meta import Meta # noqa: F401,E501 +from banking_client.models.transaction import Transaction # noqa: F401,E501 + + +class InlineResponse2004(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'transactions': 'list[Transaction]', + 'meta': 'Meta', + 'links': 'Links' + } + + attribute_map = { + 'transactions': 'transactions', + 'meta': 'meta', + 'links': 'links' + } + + def __init__(self, transactions=None, meta=None, links=None): # noqa: E501 + """InlineResponse2004 - a model defined in Swagger""" # noqa: E501 + + self._transactions = None + self._meta = None + self._links = None + self.discriminator = None + + if transactions is not None: + self.transactions = transactions + if meta is not None: + self.meta = meta + if links is not None: + self.links = links + + @property + def transactions(self): + """Gets the transactions of this InlineResponse2004. # noqa: E501 + + + :return: The transactions of this InlineResponse2004. # noqa: E501 + :rtype: list[Transaction] + """ + return self._transactions + + @transactions.setter + def transactions(self, transactions): + """Sets the transactions of this InlineResponse2004. + + + :param transactions: The transactions of this InlineResponse2004. # noqa: E501 + :type: list[Transaction] + """ + + self._transactions = transactions + + @property + def meta(self): + """Gets the meta of this InlineResponse2004. # noqa: E501 + + + :return: The meta of this InlineResponse2004. # noqa: E501 + :rtype: Meta + """ + return self._meta + + @meta.setter + def meta(self, meta): + """Sets the meta of this InlineResponse2004. + + + :param meta: The meta of this InlineResponse2004. # noqa: E501 + :type: Meta + """ + + self._meta = meta + + @property + def links(self): + """Gets the links of this InlineResponse2004. # noqa: E501 + + + :return: The links of this InlineResponse2004. # noqa: E501 + :rtype: Links + """ + return self._links + + @links.setter + def links(self, links): + """Sets the links of this InlineResponse2004. + + + :param links: The links of this InlineResponse2004. # noqa: E501 + :type: Links + """ + + self._links = links + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse2004): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200_5.py b/banking_client/models/inline_response_200_5.py new file mode 100644 index 0000000..f1cacb1 --- /dev/null +++ b/banking_client/models/inline_response_200_5.py @@ -0,0 +1,166 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.account_balances import AccountBalances # noqa: F401,E501 +from banking_client.models.links import Links # noqa: F401,E501 +from banking_client.models.meta import Meta # noqa: F401,E501 + + +class InlineResponse2005(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'account_balances': 'list[AccountBalances]', + 'meta': 'Meta', + 'links': 'Links' + } + + attribute_map = { + 'account_balances': 'account_balances', + 'meta': 'meta', + 'links': 'links' + } + + def __init__(self, account_balances=None, meta=None, links=None): # noqa: E501 + """InlineResponse2005 - a model defined in Swagger""" # noqa: E501 + + self._account_balances = None + self._meta = None + self._links = None + self.discriminator = None + + if account_balances is not None: + self.account_balances = account_balances + if meta is not None: + self.meta = meta + if links is not None: + self.links = links + + @property + def account_balances(self): + """Gets the account_balances of this InlineResponse2005. # noqa: E501 + + + :return: The account_balances of this InlineResponse2005. # noqa: E501 + :rtype: list[AccountBalances] + """ + return self._account_balances + + @account_balances.setter + def account_balances(self, account_balances): + """Sets the account_balances of this InlineResponse2005. + + + :param account_balances: The account_balances of this InlineResponse2005. # noqa: E501 + :type: list[AccountBalances] + """ + + self._account_balances = account_balances + + @property + def meta(self): + """Gets the meta of this InlineResponse2005. # noqa: E501 + + + :return: The meta of this InlineResponse2005. # noqa: E501 + :rtype: Meta + """ + return self._meta + + @meta.setter + def meta(self, meta): + """Sets the meta of this InlineResponse2005. + + + :param meta: The meta of this InlineResponse2005. # noqa: E501 + :type: Meta + """ + + self._meta = meta + + @property + def links(self): + """Gets the links of this InlineResponse2005. # noqa: E501 + + + :return: The links of this InlineResponse2005. # noqa: E501 + :rtype: Links + """ + return self._links + + @links.setter + def links(self, links): + """Sets the links of this InlineResponse2005. + + + :param links: The links of this InlineResponse2005. # noqa: E501 + :type: Links + """ + + self._links = links + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse2005): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200_6.py b/banking_client/models/inline_response_200_6.py new file mode 100644 index 0000000..7616d59 --- /dev/null +++ b/banking_client/models/inline_response_200_6.py @@ -0,0 +1,112 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.account_balances import AccountBalances # noqa: F401,E501 + + +class InlineResponse2006(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'transaction': 'AccountBalances' + } + + attribute_map = { + 'transaction': 'transaction' + } + + def __init__(self, transaction=None): # noqa: E501 + """InlineResponse2006 - a model defined in Swagger""" # noqa: E501 + + self._transaction = None + self.discriminator = None + + if transaction is not None: + self.transaction = transaction + + @property + def transaction(self): + """Gets the transaction of this InlineResponse2006. # noqa: E501 + + + :return: The transaction of this InlineResponse2006. # noqa: E501 + :rtype: AccountBalances + """ + return self._transaction + + @transaction.setter + def transaction(self, transaction): + """Sets the transaction of this InlineResponse2006. + + + :param transaction: The transaction of this InlineResponse2006. # noqa: E501 + :type: AccountBalances + """ + + self._transaction = transaction + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse2006): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200_7.py b/banking_client/models/inline_response_200_7.py new file mode 100644 index 0000000..b25e2e9 --- /dev/null +++ b/banking_client/models/inline_response_200_7.py @@ -0,0 +1,112 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.transaction import Transaction # noqa: F401,E501 + + +class InlineResponse2007(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'transaction': 'Transaction' + } + + attribute_map = { + 'transaction': 'transaction' + } + + def __init__(self, transaction=None): # noqa: E501 + """InlineResponse2007 - a model defined in Swagger""" # noqa: E501 + + self._transaction = None + self.discriminator = None + + if transaction is not None: + self.transaction = transaction + + @property + def transaction(self): + """Gets the transaction of this InlineResponse2007. # noqa: E501 + + + :return: The transaction of this InlineResponse2007. # noqa: E501 + :rtype: Transaction + """ + return self._transaction + + @transaction.setter + def transaction(self, transaction): + """Sets the transaction of this InlineResponse2007. + + + :param transaction: The transaction of this InlineResponse2007. # noqa: E501 + :type: Transaction + """ + + self._transaction = transaction + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse2007): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_200_8.py b/banking_client/models/inline_response_200_8.py new file mode 100644 index 0000000..34be420 --- /dev/null +++ b/banking_client/models/inline_response_200_8.py @@ -0,0 +1,166 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.links import Links # noqa: F401,E501 +from banking_client.models.meta import Meta # noqa: F401,E501 +from banking_client.models.subscription import Subscription # noqa: F401,E501 + + +class InlineResponse2008(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'subscriptions': 'list[Subscription]', + 'meta': 'Meta', + 'links': 'Links' + } + + attribute_map = { + 'subscriptions': 'subscriptions', + 'meta': 'meta', + 'links': 'links' + } + + def __init__(self, subscriptions=None, meta=None, links=None): # noqa: E501 + """InlineResponse2008 - a model defined in Swagger""" # noqa: E501 + + self._subscriptions = None + self._meta = None + self._links = None + self.discriminator = None + + if subscriptions is not None: + self.subscriptions = subscriptions + if meta is not None: + self.meta = meta + if links is not None: + self.links = links + + @property + def subscriptions(self): + """Gets the subscriptions of this InlineResponse2008. # noqa: E501 + + + :return: The subscriptions of this InlineResponse2008. # noqa: E501 + :rtype: list[Subscription] + """ + return self._subscriptions + + @subscriptions.setter + def subscriptions(self, subscriptions): + """Sets the subscriptions of this InlineResponse2008. + + + :param subscriptions: The subscriptions of this InlineResponse2008. # noqa: E501 + :type: list[Subscription] + """ + + self._subscriptions = subscriptions + + @property + def meta(self): + """Gets the meta of this InlineResponse2008. # noqa: E501 + + + :return: The meta of this InlineResponse2008. # noqa: E501 + :rtype: Meta + """ + return self._meta + + @meta.setter + def meta(self, meta): + """Sets the meta of this InlineResponse2008. + + + :param meta: The meta of this InlineResponse2008. # noqa: E501 + :type: Meta + """ + + self._meta = meta + + @property + def links(self): + """Gets the links of this InlineResponse2008. # noqa: E501 + + + :return: The links of this InlineResponse2008. # noqa: E501 + :rtype: Links + """ + return self._links + + @links.setter + def links(self, links): + """Sets the links of this InlineResponse2008. + + + :param links: The links of this InlineResponse2008. # noqa: E501 + :type: Links + """ + + self._links = links + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse2008): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/inline_response_201.py b/banking_client/models/inline_response_201.py new file mode 100644 index 0000000..83b415b --- /dev/null +++ b/banking_client/models/inline_response_201.py @@ -0,0 +1,112 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.subscription import Subscription # noqa: F401,E501 + + +class InlineResponse201(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'subscription': 'Subscription' + } + + attribute_map = { + 'subscription': 'subscription' + } + + def __init__(self, subscription=None): # noqa: E501 + """InlineResponse201 - a model defined in Swagger""" # noqa: E501 + + self._subscription = None + self.discriminator = None + + if subscription is not None: + self.subscription = subscription + + @property + def subscription(self): + """Gets the subscription of this InlineResponse201. # noqa: E501 + + + :return: The subscription of this InlineResponse201. # noqa: E501 + :rtype: Subscription + """ + return self._subscription + + @subscription.setter + def subscription(self, subscription): + """Sets the subscription of this InlineResponse201. + + + :param subscription: The subscription of this InlineResponse201. # noqa: E501 + :type: Subscription + """ + + self._subscription = subscription + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, InlineResponse201): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/links.py b/banking_client/models/links.py new file mode 100644 index 0000000..96c6678 --- /dev/null +++ b/banking_client/models/links.py @@ -0,0 +1,136 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Links(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'next': 'str', + 'previous': 'str' + } + + attribute_map = { + 'next': 'next', + 'previous': 'previous' + } + + def __init__(self, next=None, previous=None): # noqa: E501 + """Links - a model defined in Swagger""" # noqa: E501 + + self._next = None + self._previous = None + self.discriminator = None + + if next is not None: + self.next = next + if previous is not None: + self.previous = previous + + @property + def next(self): + """Gets the next of this Links. # noqa: E501 + + + :return: The next of this Links. # noqa: E501 + :rtype: str + """ + return self._next + + @next.setter + def next(self, next): + """Sets the next of this Links. + + + :param next: The next of this Links. # noqa: E501 + :type: str + """ + + self._next = next + + @property + def previous(self): + """Gets the previous of this Links. # noqa: E501 + + + :return: The previous of this Links. # noqa: E501 + :rtype: str + """ + return self._previous + + @previous.setter + def previous(self, previous): + """Sets the previous of this Links. + + + :param previous: The previous of this Links. # noqa: E501 + :type: str + """ + + self._previous = previous + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Links): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/location.py b/banking_client/models/location.py new file mode 100644 index 0000000..6247108 --- /dev/null +++ b/banking_client/models/location.py @@ -0,0 +1,162 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Location(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'city': 'str', + 'region_code': 'str', + 'country_code': 'str' + } + + attribute_map = { + 'city': 'city', + 'region_code': 'region_code', + 'country_code': 'country_code' + } + + def __init__(self, city=None, region_code=None, country_code=None): # noqa: E501 + """Location - a model defined in Swagger""" # noqa: E501 + + self._city = None + self._region_code = None + self._country_code = None + self.discriminator = None + + if city is not None: + self.city = city + if region_code is not None: + self.region_code = region_code + if country_code is not None: + self.country_code = country_code + + @property + def city(self): + """Gets the city of this Location. # noqa: E501 + + + :return: The city of this Location. # noqa: E501 + :rtype: str + """ + return self._city + + @city.setter + def city(self, city): + """Sets the city of this Location. + + + :param city: The city of this Location. # noqa: E501 + :type: str + """ + + self._city = city + + @property + def region_code(self): + """Gets the region_code of this Location. # noqa: E501 + + + :return: The region_code of this Location. # noqa: E501 + :rtype: str + """ + return self._region_code + + @region_code.setter + def region_code(self, region_code): + """Sets the region_code of this Location. + + + :param region_code: The region_code of this Location. # noqa: E501 + :type: str + """ + + self._region_code = region_code + + @property + def country_code(self): + """Gets the country_code of this Location. # noqa: E501 + + + :return: The country_code of this Location. # noqa: E501 + :rtype: str + """ + return self._country_code + + @country_code.setter + def country_code(self, country_code): + """Sets the country_code of this Location. + + + :param country_code: The country_code of this Location. # noqa: E501 + :type: str + """ + + self._country_code = country_code + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Location): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/membership.py b/banking_client/models/membership.py new file mode 100644 index 0000000..52316ad --- /dev/null +++ b/banking_client/models/membership.py @@ -0,0 +1,164 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Membership(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'id': 'str', + 'account_id': 'str', + 'user_id': 'str' + } + + attribute_map = { + 'id': 'id', + 'account_id': 'account_id', + 'user_id': 'user_id' + } + + def __init__(self, id=None, account_id=None, user_id=None): # noqa: E501 + """Membership - a model defined in Swagger""" # noqa: E501 + + self._id = None + self._account_id = None + self._user_id = None + self.discriminator = None + + if id is not None: + self.id = id + if account_id is not None: + self.account_id = account_id + if user_id is not None: + self.user_id = user_id + + @property + def id(self): + """Gets the id of this Membership. # noqa: E501 + + Membership ID, opaque unique identifier # noqa: E501 + + :return: The id of this Membership. # noqa: E501 + :rtype: str + """ + return self._id + + @id.setter + def id(self, id): + """Sets the id of this Membership. + + Membership ID, opaque unique identifier # noqa: E501 + + :param id: The id of this Membership. # noqa: E501 + :type: str + """ + + self._id = id + + @property + def account_id(self): + """Gets the account_id of this Membership. # noqa: E501 + + + :return: The account_id of this Membership. # noqa: E501 + :rtype: str + """ + return self._account_id + + @account_id.setter + def account_id(self, account_id): + """Sets the account_id of this Membership. + + + :param account_id: The account_id of this Membership. # noqa: E501 + :type: str + """ + + self._account_id = account_id + + @property + def user_id(self): + """Gets the user_id of this Membership. # noqa: E501 + + + :return: The user_id of this Membership. # noqa: E501 + :rtype: str + """ + return self._user_id + + @user_id.setter + def user_id(self, user_id): + """Sets the user_id of this Membership. + + + :param user_id: The user_id of this Membership. # noqa: E501 + :type: str + """ + + self._user_id = user_id + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Membership): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/meta.py b/banking_client/models/meta.py new file mode 100644 index 0000000..89b477c --- /dev/null +++ b/banking_client/models/meta.py @@ -0,0 +1,110 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Meta(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'total': 'int' + } + + attribute_map = { + 'total': 'total' + } + + def __init__(self, total=None): # noqa: E501 + """Meta - a model defined in Swagger""" # noqa: E501 + + self._total = None + self.discriminator = None + + if total is not None: + self.total = total + + @property + def total(self): + """Gets the total of this Meta. # noqa: E501 + + + :return: The total of this Meta. # noqa: E501 + :rtype: int + """ + return self._total + + @total.setter + def total(self, total): + """Sets the total of this Meta. + + + :param total: The total of this Meta. # noqa: E501 + :type: int + """ + + self._total = total + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Meta): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/phone.py b/banking_client/models/phone.py new file mode 100644 index 0000000..2c748af --- /dev/null +++ b/banking_client/models/phone.py @@ -0,0 +1,110 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Phone(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'number': 'str' + } + + attribute_map = { + 'number': 'number' + } + + def __init__(self, number=None): # noqa: E501 + """Phone - a model defined in Swagger""" # noqa: E501 + + self._number = None + self.discriminator = None + + if number is not None: + self.number = number + + @property + def number(self): + """Gets the number of this Phone. # noqa: E501 + + + :return: The number of this Phone. # noqa: E501 + :rtype: str + """ + return self._number + + @number.setter + def number(self, number): + """Sets the number of this Phone. + + + :param number: The number of this Phone. # noqa: E501 + :type: str + """ + + self._number = number + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Phone): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/subscription.py b/banking_client/models/subscription.py new file mode 100644 index 0000000..e938997 --- /dev/null +++ b/banking_client/models/subscription.py @@ -0,0 +1,326 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Subscription(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'id': 'str', + 'subscription': 'str', + 'description': 'str', + 'url': 'str', + 'secret': 'str', + 'version': 'str', + 'is_active': 'bool', + 'created_at': 'datetime', + 'updated_at': 'datetime' + } + + attribute_map = { + 'id': 'id', + 'subscription': 'subscription', + 'description': 'description', + 'url': 'url', + 'secret': 'secret', + 'version': 'version', + 'is_active': 'is_active', + 'created_at': 'created_at', + 'updated_at': 'updated_at' + } + + def __init__(self, id=None, subscription=None, description=None, url=None, secret=None, version=None, is_active=None, created_at=None, updated_at=None): # noqa: E501 + """Subscription - a model defined in Swagger""" # noqa: E501 + + self._id = None + self._subscription = None + self._description = None + self._url = None + self._secret = None + self._version = None + self._is_active = None + self._created_at = None + self._updated_at = None + self.discriminator = None + + if id is not None: + self.id = id + if subscription is not None: + self.subscription = subscription + if description is not None: + self.description = description + if url is not None: + self.url = url + if secret is not None: + self.secret = secret + if version is not None: + self.version = version + if is_active is not None: + self.is_active = is_active + if created_at is not None: + self.created_at = created_at + if updated_at is not None: + self.updated_at = updated_at + + @property + def id(self): + """Gets the id of this Subscription. # noqa: E501 + + Subscription ID, opaque unique identifier # noqa: E501 + + :return: The id of this Subscription. # noqa: E501 + :rtype: str + """ + return self._id + + @id.setter + def id(self, id): + """Sets the id of this Subscription. + + Subscription ID, opaque unique identifier # noqa: E501 + + :param id: The id of this Subscription. # noqa: E501 + :type: str + """ + + self._id = id + + @property + def subscription(self): + """Gets the subscription of this Subscription. # noqa: E501 + + name of event to respond to, ie resource.create, resource.* # noqa: E501 + + :return: The subscription of this Subscription. # noqa: E501 + :rtype: str + """ + return self._subscription + + @subscription.setter + def subscription(self, subscription): + """Sets the subscription of this Subscription. + + name of event to respond to, ie resource.create, resource.* # noqa: E501 + + :param subscription: The subscription of this Subscription. # noqa: E501 + :type: str + """ + + self._subscription = subscription + + @property + def description(self): + """Gets the description of this Subscription. # noqa: E501 + + human readable description of hook (e.g. my special foo) # noqa: E501 + + :return: The description of this Subscription. # noqa: E501 + :rtype: str + """ + return self._description + + @description.setter + def description(self, description): + """Sets the description of this Subscription. + + human readable description of hook (e.g. my special foo) # noqa: E501 + + :param description: The description of this Subscription. # noqa: E501 + :type: str + """ + + self._description = description + + @property + def url(self): + """Gets the url of this Subscription. # noqa: E501 + + URL to which events will POST # noqa: E501 + + :return: The url of this Subscription. # noqa: E501 + :rtype: str + """ + return self._url + + @url.setter + def url(self, url): + """Sets the url of this Subscription. + + URL to which events will POST # noqa: E501 + + :param url: The url of this Subscription. # noqa: E501 + :type: str + """ + + self._url = url + + @property + def secret(self): + """Gets the secret of this Subscription. # noqa: E501 + + + :return: The secret of this Subscription. # noqa: E501 + :rtype: str + """ + return self._secret + + @secret.setter + def secret(self, secret): + """Sets the secret of this Subscription. + + + :param secret: The secret of this Subscription. # noqa: E501 + :type: str + """ + + self._secret = secret + + @property + def version(self): + """Gets the version of this Subscription. # noqa: E501 + + + :return: The version of this Subscription. # noqa: E501 + :rtype: str + """ + return self._version + + @version.setter + def version(self, version): + """Sets the version of this Subscription. + + + :param version: The version of this Subscription. # noqa: E501 + :type: str + """ + + self._version = version + + @property + def is_active(self): + """Gets the is_active of this Subscription. # noqa: E501 + + + :return: The is_active of this Subscription. # noqa: E501 + :rtype: bool + """ + return self._is_active + + @is_active.setter + def is_active(self, is_active): + """Sets the is_active of this Subscription. + + + :param is_active: The is_active of this Subscription. # noqa: E501 + :type: bool + """ + + self._is_active = is_active + + @property + def created_at(self): + """Gets the created_at of this Subscription. # noqa: E501 + + + :return: The created_at of this Subscription. # noqa: E501 + :rtype: datetime + """ + return self._created_at + + @created_at.setter + def created_at(self, created_at): + """Sets the created_at of this Subscription. + + + :param created_at: The created_at of this Subscription. # noqa: E501 + :type: datetime + """ + + self._created_at = created_at + + @property + def updated_at(self): + """Gets the updated_at of this Subscription. # noqa: E501 + + + :return: The updated_at of this Subscription. # noqa: E501 + :rtype: datetime + """ + return self._updated_at + + @updated_at.setter + def updated_at(self, updated_at): + """Sets the updated_at of this Subscription. + + + :param updated_at: The updated_at of this Subscription. # noqa: E501 + :type: datetime + """ + + self._updated_at = updated_at + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Subscription): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/transaction.py b/banking_client/models/transaction.py new file mode 100644 index 0000000..78be2ef --- /dev/null +++ b/banking_client/models/transaction.py @@ -0,0 +1,453 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.check import Check # noqa: F401,E501 +from banking_client.models.location import Location # noqa: F401,E501 + + +class Transaction(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'id': 'str', + 'description': 'str', + 'type': 'str', + 'source': 'str', + 'settled_at': 'datetime', + 'created_at': 'datetime', + 'account_id': 'str', + 'category': 'str', + 'sub_category': 'str', + 'amount': 'int', + 'location': 'Location', + 'check': 'Check', + 'tags': 'list[str]', + 'note': 'str' + } + + attribute_map = { + 'id': 'id', + 'description': 'description', + 'type': 'type', + 'source': 'source', + 'settled_at': 'settled_at', + 'created_at': 'created_at', + 'account_id': 'account_id', + 'category': 'category', + 'sub_category': 'sub_category', + 'amount': 'amount', + 'location': 'location', + 'check': 'check', + 'tags': 'tags', + 'note': 'note' + } + + def __init__(self, id=None, description=None, type=None, source=None, settled_at=None, created_at=None, account_id=None, category=None, sub_category=None, amount=None, location=None, check=None, tags=None, note=None): # noqa: E501 + """Transaction - a model defined in Swagger""" # noqa: E501 + + self._id = None + self._description = None + self._type = None + self._source = None + self._settled_at = None + self._created_at = None + self._account_id = None + self._category = None + self._sub_category = None + self._amount = None + self._location = None + self._check = None + self._tags = None + self._note = None + self.discriminator = None + + if id is not None: + self.id = id + if description is not None: + self.description = description + if type is not None: + self.type = type + if source is not None: + self.source = source + if settled_at is not None: + self.settled_at = settled_at + if created_at is not None: + self.created_at = created_at + if account_id is not None: + self.account_id = account_id + if category is not None: + self.category = category + if sub_category is not None: + self.sub_category = sub_category + if amount is not None: + self.amount = amount + if location is not None: + self.location = location + if check is not None: + self.check = check + if tags is not None: + self.tags = tags + if note is not None: + self.note = note + + @property + def id(self): + """Gets the id of this Transaction. # noqa: E501 + + Unique transaction identifier # noqa: E501 + + :return: The id of this Transaction. # noqa: E501 + :rtype: str + """ + return self._id + + @id.setter + def id(self, id): + """Sets the id of this Transaction. + + Unique transaction identifier # noqa: E501 + + :param id: The id of this Transaction. # noqa: E501 + :type: str + """ + + self._id = id + + @property + def description(self): + """Gets the description of this Transaction. # noqa: E501 + + + :return: The description of this Transaction. # noqa: E501 + :rtype: str + """ + return self._description + + @description.setter + def description(self, description): + """Sets the description of this Transaction. + + + :param description: The description of this Transaction. # noqa: E501 + :type: str + """ + + self._description = description + + @property + def type(self): + """Gets the type of this Transaction. # noqa: E501 + + + :return: The type of this Transaction. # noqa: E501 + :rtype: str + """ + return self._type + + @type.setter + def type(self, type): + """Sets the type of this Transaction. + + + :param type: The type of this Transaction. # noqa: E501 + :type: str + """ + + self._type = type + + @property + def source(self): + """Gets the source of this Transaction. # noqa: E501 + + + :return: The source of this Transaction. # noqa: E501 + :rtype: str + """ + return self._source + + @source.setter + def source(self, source): + """Sets the source of this Transaction. + + + :param source: The source of this Transaction. # noqa: E501 + :type: str + """ + + self._source = source + + @property + def settled_at(self): + """Gets the settled_at of this Transaction. # noqa: E501 + + + :return: The settled_at of this Transaction. # noqa: E501 + :rtype: datetime + """ + return self._settled_at + + @settled_at.setter + def settled_at(self, settled_at): + """Sets the settled_at of this Transaction. + + + :param settled_at: The settled_at of this Transaction. # noqa: E501 + :type: datetime + """ + + self._settled_at = settled_at + + @property + def created_at(self): + """Gets the created_at of this Transaction. # noqa: E501 + + + :return: The created_at of this Transaction. # noqa: E501 + :rtype: datetime + """ + return self._created_at + + @created_at.setter + def created_at(self, created_at): + """Sets the created_at of this Transaction. + + + :param created_at: The created_at of this Transaction. # noqa: E501 + :type: datetime + """ + + self._created_at = created_at + + @property + def account_id(self): + """Gets the account_id of this Transaction. # noqa: E501 + + + :return: The account_id of this Transaction. # noqa: E501 + :rtype: str + """ + return self._account_id + + @account_id.setter + def account_id(self, account_id): + """Sets the account_id of this Transaction. + + + :param account_id: The account_id of this Transaction. # noqa: E501 + :type: str + """ + + self._account_id = account_id + + @property + def category(self): + """Gets the category of this Transaction. # noqa: E501 + + + :return: The category of this Transaction. # noqa: E501 + :rtype: str + """ + return self._category + + @category.setter + def category(self, category): + """Sets the category of this Transaction. + + + :param category: The category of this Transaction. # noqa: E501 + :type: str + """ + + self._category = category + + @property + def sub_category(self): + """Gets the sub_category of this Transaction. # noqa: E501 + + + :return: The sub_category of this Transaction. # noqa: E501 + :rtype: str + """ + return self._sub_category + + @sub_category.setter + def sub_category(self, sub_category): + """Sets the sub_category of this Transaction. + + + :param sub_category: The sub_category of this Transaction. # noqa: E501 + :type: str + """ + + self._sub_category = sub_category + + @property + def amount(self): + """Gets the amount of this Transaction. # noqa: E501 + + + :return: The amount of this Transaction. # noqa: E501 + :rtype: int + """ + return self._amount + + @amount.setter + def amount(self, amount): + """Sets the amount of this Transaction. + + + :param amount: The amount of this Transaction. # noqa: E501 + :type: int + """ + + self._amount = amount + + @property + def location(self): + """Gets the location of this Transaction. # noqa: E501 + + + :return: The location of this Transaction. # noqa: E501 + :rtype: Location + """ + return self._location + + @location.setter + def location(self, location): + """Sets the location of this Transaction. + + + :param location: The location of this Transaction. # noqa: E501 + :type: Location + """ + + self._location = location + + @property + def check(self): + """Gets the check of this Transaction. # noqa: E501 + + + :return: The check of this Transaction. # noqa: E501 + :rtype: Check + """ + return self._check + + @check.setter + def check(self, check): + """Sets the check of this Transaction. + + + :param check: The check of this Transaction. # noqa: E501 + :type: Check + """ + + self._check = check + + @property + def tags(self): + """Gets the tags of this Transaction. # noqa: E501 + + + :return: The tags of this Transaction. # noqa: E501 + :rtype: list[str] + """ + return self._tags + + @tags.setter + def tags(self, tags): + """Sets the tags of this Transaction. + + + :param tags: The tags of this Transaction. # noqa: E501 + :type: list[str] + """ + + self._tags = tags + + @property + def note(self): + """Gets the note of this Transaction. # noqa: E501 + + + :return: The note of this Transaction. # noqa: E501 + :rtype: str + """ + return self._note + + @note.setter + def note(self, note): + """Sets the note of this Transaction. + + + :param note: The note of this Transaction. # noqa: E501 + :type: str + """ + + self._note = note + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Transaction): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/transfer.py b/banking_client/models/transfer.py new file mode 100644 index 0000000..5116a05 --- /dev/null +++ b/banking_client/models/transfer.py @@ -0,0 +1,162 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + + +class Transfer(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'from_account_id': 'str', + 'to_account_id': 'str', + 'amount': 'int' + } + + attribute_map = { + 'from_account_id': 'from_account_id', + 'to_account_id': 'to_account_id', + 'amount': 'amount' + } + + def __init__(self, from_account_id=None, to_account_id=None, amount=None): # noqa: E501 + """Transfer - a model defined in Swagger""" # noqa: E501 + + self._from_account_id = None + self._to_account_id = None + self._amount = None + self.discriminator = None + + if from_account_id is not None: + self.from_account_id = from_account_id + if to_account_id is not None: + self.to_account_id = to_account_id + if amount is not None: + self.amount = amount + + @property + def from_account_id(self): + """Gets the from_account_id of this Transfer. # noqa: E501 + + + :return: The from_account_id of this Transfer. # noqa: E501 + :rtype: str + """ + return self._from_account_id + + @from_account_id.setter + def from_account_id(self, from_account_id): + """Sets the from_account_id of this Transfer. + + + :param from_account_id: The from_account_id of this Transfer. # noqa: E501 + :type: str + """ + + self._from_account_id = from_account_id + + @property + def to_account_id(self): + """Gets the to_account_id of this Transfer. # noqa: E501 + + + :return: The to_account_id of this Transfer. # noqa: E501 + :rtype: str + """ + return self._to_account_id + + @to_account_id.setter + def to_account_id(self, to_account_id): + """Sets the to_account_id of this Transfer. + + + :param to_account_id: The to_account_id of this Transfer. # noqa: E501 + :type: str + """ + + self._to_account_id = to_account_id + + @property + def amount(self): + """Gets the amount of this Transfer. # noqa: E501 + + + :return: The amount of this Transfer. # noqa: E501 + :rtype: int + """ + return self._amount + + @amount.setter + def amount(self, amount): + """Sets the amount of this Transfer. + + + :param amount: The amount of this Transfer. # noqa: E501 + :type: int + """ + + self._amount = amount + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, Transfer): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/models/user.py b/banking_client/models/user.py new file mode 100644 index 0000000..840fe4b --- /dev/null +++ b/banking_client/models/user.py @@ -0,0 +1,245 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +import pprint +import re # noqa: F401 + +import six + +from banking_client.models.address import Address # noqa: F401,E501 +from banking_client.models.phone import Phone # noqa: F401,E501 + + +class User(object): + """ + This class is auto generated, do not edit the class manually. + """ + + """ + Attributes: + swagger_types (dict): The key is attribute name + and the value is attribute type. + attribute_map (dict): The key is attribute name + and the value is json key in definition. + """ + swagger_types = { + 'id': 'str', + 'email': 'str', + 'first_name': 'str', + 'last_name': 'str', + 'addresses': 'list[Address]', + 'phone_numbers': 'list[Phone]' + } + + attribute_map = { + 'id': 'id', + 'email': 'email', + 'first_name': 'first_name', + 'last_name': 'last_name', + 'addresses': 'addresses', + 'phone_numbers': 'phone_numbers' + } + + def __init__(self, id=None, email=None, first_name=None, last_name=None, addresses=None, phone_numbers=None): # noqa: E501 + """User - a model defined in Swagger""" # noqa: E501 + + self._id = None + self._email = None + self._first_name = None + self._last_name = None + self._addresses = None + self._phone_numbers = None + self.discriminator = None + + if id is not None: + self.id = id + if email is not None: + self.email = email + if first_name is not None: + self.first_name = first_name + if last_name is not None: + self.last_name = last_name + if addresses is not None: + self.addresses = addresses + if phone_numbers is not None: + self.phone_numbers = phone_numbers + + @property + def id(self): + """Gets the id of this User. # noqa: E501 + + User ID # noqa: E501 + + :return: The id of this User. # noqa: E501 + :rtype: str + """ + return self._id + + @id.setter + def id(self, id): + """Sets the id of this User. + + User ID # noqa: E501 + + :param id: The id of this User. # noqa: E501 + :type: str + """ + + self._id = id + + @property + def email(self): + """Gets the email of this User. # noqa: E501 + + + :return: The email of this User. # noqa: E501 + :rtype: str + """ + return self._email + + @email.setter + def email(self, email): + """Sets the email of this User. + + + :param email: The email of this User. # noqa: E501 + :type: str + """ + + self._email = email + + @property + def first_name(self): + """Gets the first_name of this User. # noqa: E501 + + + :return: The first_name of this User. # noqa: E501 + :rtype: str + """ + return self._first_name + + @first_name.setter + def first_name(self, first_name): + """Sets the first_name of this User. + + + :param first_name: The first_name of this User. # noqa: E501 + :type: str + """ + + self._first_name = first_name + + @property + def last_name(self): + """Gets the last_name of this User. # noqa: E501 + + + :return: The last_name of this User. # noqa: E501 + :rtype: str + """ + return self._last_name + + @last_name.setter + def last_name(self, last_name): + """Sets the last_name of this User. + + + :param last_name: The last_name of this User. # noqa: E501 + :type: str + """ + + self._last_name = last_name + + @property + def addresses(self): + """Gets the addresses of this User. # noqa: E501 + + + :return: The addresses of this User. # noqa: E501 + :rtype: list[Address] + """ + return self._addresses + + @addresses.setter + def addresses(self, addresses): + """Sets the addresses of this User. + + + :param addresses: The addresses of this User. # noqa: E501 + :type: list[Address] + """ + + self._addresses = addresses + + @property + def phone_numbers(self): + """Gets the phone_numbers of this User. # noqa: E501 + + + :return: The phone_numbers of this User. # noqa: E501 + :rtype: list[Phone] + """ + return self._phone_numbers + + @phone_numbers.setter + def phone_numbers(self, phone_numbers): + """Sets the phone_numbers of this User. + + + :param phone_numbers: The phone_numbers of this User. # noqa: E501 + :type: list[Phone] + """ + + self._phone_numbers = phone_numbers + + def to_dict(self): + """Returns the model properties as a dict""" + result = {} + + for attr, _ in six.iteritems(self.swagger_types): + value = getattr(self, attr) + if isinstance(value, list): + result[attr] = list(map( + lambda x: x.to_dict() if hasattr(x, "to_dict") else x, + value + )) + elif hasattr(value, "to_dict"): + result[attr] = value.to_dict() + elif isinstance(value, dict): + result[attr] = dict(map( + lambda item: (item[0], item[1].to_dict()) + if hasattr(item[1], "to_dict") else item, + value.items() + )) + else: + result[attr] = value + + return result + + def to_str(self): + """Returns the string representation of the model""" + return pprint.pformat(self.to_dict()) + + def __repr__(self): + """For `print` and `pprint`""" + return self.to_str() + + def __eq__(self, other): + """Returns true if both objects are equal""" + if not isinstance(other, User): + return False + + return self.__dict__ == other.__dict__ + + def __ne__(self, other): + """Returns true if both objects are not equal""" + return not self == other diff --git a/banking_client/rest.py b/banking_client/rest.py new file mode 100644 index 0000000..d1fe69c --- /dev/null +++ b/banking_client/rest.py @@ -0,0 +1,322 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from __future__ import absolute_import + +import io +import json +import logging +import re +import ssl + +import certifi +# python 2 and python 3 compatibility library +import six +from six.moves.urllib.parse import urlencode + +try: + import urllib3 +except ImportError: + raise ImportError('python client requires urllib3.') + + +logger = logging.getLogger(__name__) + + +class RESTResponse(io.IOBase): + + def __init__(self, resp): + self.urllib3_response = resp + self.status = resp.status + self.reason = resp.reason + self.data = resp.data + + def getheaders(self): + """Returns a dictionary of the response headers.""" + return self.urllib3_response.getheaders() + + def getheader(self, name, default=None): + """Returns a given response header.""" + return self.urllib3_response.getheader(name, default) + + +class RESTClientObject(object): + + def __init__(self, configuration, pools_size=4, maxsize=None): + # urllib3.PoolManager will pass all kw parameters to connectionpool + # https://github.com/shazow/urllib3/blob/f9409436f83aeb79fbaf090181cd81b784f1b8ce/urllib3/poolmanager.py#L75 # noqa: E501 + # https://github.com/shazow/urllib3/blob/f9409436f83aeb79fbaf090181cd81b784f1b8ce/urllib3/connectionpool.py#L680 # noqa: E501 + # maxsize is the number of requests to host that are allowed in parallel # noqa: E501 + # Custom SSL certificates and client certificates: http://urllib3.readthedocs.io/en/latest/advanced-usage.html # noqa: E501 + + # cert_reqs + if configuration.verify_ssl: + cert_reqs = ssl.CERT_REQUIRED + else: + cert_reqs = ssl.CERT_NONE + + # ca_certs + if configuration.ssl_ca_cert: + ca_certs = configuration.ssl_ca_cert + else: + # if not set certificate file, use Mozilla's root certificates. + ca_certs = certifi.where() + + addition_pool_args = {} + if configuration.assert_hostname is not None: + addition_pool_args['assert_hostname'] = configuration.assert_hostname # noqa: E501 + + if maxsize is None: + if configuration.connection_pool_maxsize is not None: + maxsize = configuration.connection_pool_maxsize + else: + maxsize = 4 + + # https pool manager + if configuration.proxy: + self.pool_manager = urllib3.ProxyManager( + num_pools=pools_size, + maxsize=maxsize, + cert_reqs=cert_reqs, + ca_certs=ca_certs, + cert_file=configuration.cert_file, + key_file=configuration.key_file, + proxy_url=configuration.proxy, + **addition_pool_args + ) + else: + self.pool_manager = urllib3.PoolManager( + num_pools=pools_size, + maxsize=maxsize, + cert_reqs=cert_reqs, + ca_certs=ca_certs, + cert_file=configuration.cert_file, + key_file=configuration.key_file, + **addition_pool_args + ) + + def request(self, method, url, query_params=None, headers=None, + body=None, post_params=None, _preload_content=True, + _request_timeout=None): + """Perform requests. + + :param method: http request method + :param url: http request url + :param query_params: query parameters in the url + :param headers: http request headers + :param body: request json body, for `application/json` + :param post_params: request post parameters, + `application/x-www-form-urlencoded` + and `multipart/form-data` + :param _preload_content: if False, the urllib3.HTTPResponse object will + be returned without reading/decoding response + data. Default is True. + :param _request_timeout: timeout setting for this request. If one + number provided, it will be total request + timeout. It can also be a pair (tuple) of + (connection, read) timeouts. + """ + method = method.upper() + assert method in ['GET', 'HEAD', 'DELETE', 'POST', 'PUT', + 'PATCH', 'OPTIONS'] + + if post_params and body: + raise ValueError( + "body parameter cannot be used with post_params parameter." + ) + + post_params = post_params or {} + headers = headers or {} + + timeout = None + if _request_timeout: + if isinstance(_request_timeout, (int, ) if six.PY3 else (int, long)): # noqa: E501,F821 + timeout = urllib3.Timeout(total=_request_timeout) + elif (isinstance(_request_timeout, tuple) and + len(_request_timeout) == 2): + timeout = urllib3.Timeout( + connect=_request_timeout[0], read=_request_timeout[1]) + + if 'Content-Type' not in headers: + headers['Content-Type'] = 'application/json' + + try: + # For `POST`, `PUT`, `PATCH`, `OPTIONS`, `DELETE` + if method in ['POST', 'PUT', 'PATCH', 'OPTIONS', 'DELETE']: + if query_params: + url += '?' + urlencode(query_params) + if re.search('json', headers['Content-Type'], re.IGNORECASE): + request_body = None + if body is not None: + request_body = json.dumps(body) + r = self.pool_manager.request( + method, url, + body=request_body, + preload_content=_preload_content, + timeout=timeout, + headers=headers) + elif headers['Content-Type'] == 'application/x-www-form-urlencoded': # noqa: E501 + r = self.pool_manager.request( + method, url, + fields=post_params, + encode_multipart=False, + preload_content=_preload_content, + timeout=timeout, + headers=headers) + elif headers['Content-Type'] == 'multipart/form-data': + # must del headers['Content-Type'], or the correct + # Content-Type which generated by urllib3 will be + # overwritten. + del headers['Content-Type'] + r = self.pool_manager.request( + method, url, + fields=post_params, + encode_multipart=True, + preload_content=_preload_content, + timeout=timeout, + headers=headers) + # Pass a `string` parameter directly in the body to support + # other content types than Json when `body` argument is + # provided in serialized form + elif isinstance(body, str): + request_body = body + r = self.pool_manager.request( + method, url, + body=request_body, + preload_content=_preload_content, + timeout=timeout, + headers=headers) + else: + # Cannot generate the request from given parameters + msg = """Cannot prepare a request message for provided + arguments. Please check that your arguments match + declared content type.""" + raise ApiException(status=0, reason=msg) + # For `GET`, `HEAD` + else: + r = self.pool_manager.request(method, url, + fields=query_params, + preload_content=_preload_content, + timeout=timeout, + headers=headers) + except urllib3.exceptions.SSLError as e: + msg = "{0}\n{1}".format(type(e).__name__, str(e)) + raise ApiException(status=0, reason=msg) + + if _preload_content: + r = RESTResponse(r) + + # In the python 3, the response.data is bytes. + # we need to decode it to string. + if six.PY3: + r.data = r.data.decode('utf8') + + # log response body + logger.debug("response body: %s", r.data) + + if not 200 <= r.status <= 299: + raise ApiException(http_resp=r) + + return r + + def GET(self, url, headers=None, query_params=None, _preload_content=True, + _request_timeout=None): + return self.request("GET", url, + headers=headers, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + query_params=query_params) + + def HEAD(self, url, headers=None, query_params=None, _preload_content=True, + _request_timeout=None): + return self.request("HEAD", url, + headers=headers, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + query_params=query_params) + + def OPTIONS(self, url, headers=None, query_params=None, post_params=None, + body=None, _preload_content=True, _request_timeout=None): + return self.request("OPTIONS", url, + headers=headers, + query_params=query_params, + post_params=post_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + + def DELETE(self, url, headers=None, query_params=None, body=None, + _preload_content=True, _request_timeout=None): + return self.request("DELETE", url, + headers=headers, + query_params=query_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + + def POST(self, url, headers=None, query_params=None, post_params=None, + body=None, _preload_content=True, _request_timeout=None): + return self.request("POST", url, + headers=headers, + query_params=query_params, + post_params=post_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + + def PUT(self, url, headers=None, query_params=None, post_params=None, + body=None, _preload_content=True, _request_timeout=None): + return self.request("PUT", url, + headers=headers, + query_params=query_params, + post_params=post_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + + def PATCH(self, url, headers=None, query_params=None, post_params=None, + body=None, _preload_content=True, _request_timeout=None): + return self.request("PATCH", url, + headers=headers, + query_params=query_params, + post_params=post_params, + _preload_content=_preload_content, + _request_timeout=_request_timeout, + body=body) + + +class ApiException(Exception): + + def __init__(self, status=None, reason=None, http_resp=None): + if http_resp: + self.status = http_resp.status + self.reason = http_resp.reason + self.body = http_resp.data + self.headers = http_resp.getheaders() + else: + self.status = status + self.reason = reason + self.body = None + self.headers = None + + def __str__(self): + """Custom error messages for exception""" + error_message = "({0})\n"\ + "Reason: {1}\n".format(self.status, self.reason) + if self.headers: + error_message += "HTTP response headers: {0}\n".format( + self.headers) + + if self.body: + error_message += "HTTP response body: {0}\n".format(self.body) + + return error_message diff --git a/requirements.txt b/requirements.txt new file mode 100644 index 0000000..bafdc07 --- /dev/null +++ b/requirements.txt @@ -0,0 +1,5 @@ +certifi >= 14.05.14 +six >= 1.10 +python_dateutil >= 2.5.3 +setuptools >= 21.0.0 +urllib3 >= 1.15.1 diff --git a/setup.py b/setup.py new file mode 100644 index 0000000..07eeffe --- /dev/null +++ b/setup.py @@ -0,0 +1,39 @@ +# coding: utf-8 + +""" + Narmi Banking API + + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + + OpenAPI spec version: 0.1.0 + Contact: contact@narmitech.com +""" + + +from setuptools import setup, find_packages # noqa: H301 + +NAME = "banking-client" +VERSION = "1.0.0" +# To install the library, run the following +# +# python setup.py install +# +# prerequisite: setuptools +# http://pypi.python.org/pypi/setuptools + +REQUIRES = ["urllib3 >= 1.15", "six >= 1.10", "certifi", "python-dateutil"] + +setup( + name=NAME, + version=VERSION, + description="Narmi Banking API", + author_email="contact@narmitech.com", + url="", + keywords=["Narmi Banking API"], + install_requires=REQUIRES, + packages=find_packages(), + include_package_data=True, + long_description="""\ + ## Introduction This API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. ### Schema JSON is returned by all API responses, including errors. All timestamps return in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`. ## Access All API requests must be made over HTTPS. API requests without authentication will also fail. Authentication to the API is via bearer authorization, for example using curl this would be `-H \"Authorization: Bearer $SECRET_KEY\"`. Your API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such source code pushed to Github, client-side code, and so forth. ### Request Signing Requests to the production API must be signed, this requires use of the secret returned alongside the API token. This is done following [the draft specification on HTTP request signing](https://tools.ietf.org/html/draft-cavage-http-signatures-08). This is a simple of example of signing only the `Date` header: ``` token='1234acdefghijk' secret='acdefghijk1234' date=`date -u +'%Y-%m-%dT%H:%M:%SZ'` signature=`echo -n \"date: $date\" | openssl dgst -sha256 -binary -hmac \"$secret\" | base64` curl -H \"Authorization: Bearer $token\" -H \"Date: $date\" -H \"Signature: keyId=\\\"$token\\\",algorithm=\\\"hmac-sha256\\\",headers=\\\"date\\\",signature=\\\"$signature\\\"\" 'https://api.example.com/v1/accounts/' ``` For the production api, the following components of the signature are required: * (request-target) psuedo header * `Host` header * `Date` header * `Content-Type` header * `Digest` header containing a digest of SHA-256 digest of the request body * `Content-Length` header A full signature header would look like: ``` Signature: keyId=\"1234acdefghijk\",algorithm=\"hmac-sha256\",headers=\"(request-target),date,host,content-type,digest,content-length\",signature=\"zxywut321asdf\" ``` These signatures increase the security of production data in three ways: verifying the identity of the requester, protecting data in transit, and reducing the window of replay attacks. Request signatures ensure that the request has been sent by someone with a valid access key and secret - even if the key was seen in transit, the secret should never be exposed and the signature depends on having a valid key and secret. In addition, this prevents tampering with a request while it's in transit, since some of the request elements are used to calculate a digest of the request, and the resulting hash value is included as part of the request. If the value of the digest calculated by the API doesn't match, the digest in the request the API denies the request. Finally, because a request must reach the API within five minutes of the timestamp in the request, a request is valid only for those five minutes. ## Versions and resource stability When we make backwards-incompatible changes to the API, we release new versions. All requests will use your account API settings, unless you override the API version. To set the API version on a specific request, send a `API-Version: '1234567'` header. ### Stability Within any given version of the API, any given resource (eg. /foos, /foo or /foos/:id/bars) has a specified level of stability. The stability of a resource is specified in the stability property. The stability of a resource specifies what changes will be made to the resource and how changes will be communicated. The possible types of changes are detailed below. All changes are communicated in the api changelog. There are three levels of stability: prototype, development, and production. #### Prototype A prototype resource is experimental and major changes are likely. In time, a prototype resource may or may not advance to production. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one week notice * Deprecated resources will remain available for at least one month after deprecation #### Development A Development resource is a work-in-progress, but major changes should be infrequent. Development resources should advance to production stability in time. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may be made with one month notice * Deprecated resources will remain available for at least six months after deprecation #### Production A production resources is complete and major changes will no longer occur. * Compatible and emergency changes may be made with no advance notice * Disruptive changes may not occur, instead a new major version is developed * Deprecated resources will remain available for at least twelve months after deprecation ### Deprecation Deprecated resources have a deprecated_at date property which is also displayed in the documentation. Deprecated resources will keep working for at least as long after deprecation as mandated by their stability: 1 month for prototype resources, 6 month for development resources and 12 months for production resources. Deprecated resources will not change stability. Once a resource has been completely deactivated, it will return HTTP 410 for all requests. ### Types of changes #### Compatible change Small in scope and unlikely to break or change semantics of existing methods. * Add resources, methods and attributes * Change documentation * Change undocumented behavior #### Disruptive change May have larger impact and effort will be made to provide migration paths as needed. * Change semantics of existing methods * Remove resources, methods and attributes #### Emergency change May have larger impact, but are unavoidable due to legal compliance, security vulnerabilities or violation of specification. ## Requests and responses ### Requests An endpoint's name indicates the type of data it handles and the action it performs on that data. The most common actions are: | Action | HTTP Method | Description | | ------ | ------------ | ----------- | | Create | POST | Creates and persists an entity of the corresponding type. | | List | GET | Returns all instances of a particular entity that match query parameters you provide. | | Retrieve | GET | Returns the single instance of an entity that matches the identifier you provide. | | Update | PUT | Modifies the existing entity that matches the identifier you provide. | | Delete | DELETE | Deletes the existing entity that matches the identifier you provide. Deleted entities cannot be retrieved or undeleted. | All requests must include a header indicating the format of the resposne to be returned: ``` Accept: application/json ``` #### Providing parameters The way you provide parameters to a request depends on the HTTP method of the request. ##### `GET` and `DELETE` For GET and DELETE requests, you provide parameters in a query string you append to your request's URL. For example, ``` /v1/locations/$LOCATION_ID/transactions?sort_order=ASC ``` Values for query parameters must be URL-escaped. ##### `POST`, `PUT` and `PATCH` For `POST`, `PUT` and `PATCH` requests, you instead provide parameters as JSON in the body of your request. POST and PUT requests must include one additional header: ``` Content-Type: application/json ``` And in the body of the request: ``` { \"given_name\": \"Amelia\", \"family_name\": \"Earhart\" } ``` ### Responses [Conventional HTTP response codes](https://httpstatuses.com/) indicate the success or failure of an API request, not all errors map cleanly onto HTTP response codes, however. In general: | HTTP Response code | Indication | | ------------------ | ---------- | | 2xx | success | | 4xx | an error that failed given the information provided (e.g., a required parameter was omitted, or the configuration does is invalid, etc.) | | 5xx | 5xx range indicate an error processing the request | #### Response bodies When a request is successful, a response body will typically be sent back in the form of a JSON object and include a `Content-Type: application/json` header. One exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. #### Response meta-information Responses will have a [top level `meta` key](http://jsonapi.org/format/#document-meta) with meta information associated with the request. Common keys include: | key | description | example | | --- | ----------- | ------- | | deprecated_at | | | | stability | | | | total | used in paginating responses | | #### Errors Failing responses will have an appropriate status and a JSON body containing more details about a particular error. | Name | Type | Description | Example | | ---- | ---- | ----------- | ---------- | | id | string | id of error raised | \"rate_limit\" | | message | string | end user message of error raised | \"Your account reached the API limit. Please wait a few minutes before making new requests\" | | url | string | reference url with more information about the error | https://example.com/developer/articles/rate-limits | ## Pagination Requests that return multiple items will be paginated to 25 items by default. You can specify subsequent pages with the `page` query parameter. For some resources, you can also set a custom page size up to `100` with the `per_page` parameter. A top level object in the response body named `links` will contain full URLs to access the next and previous pages of the response. ``` { ... \"links\": { \"next\": \"https://api.example.com/v1/accounts?page=2\", \"previous\": \"https://api.example.com/v1/accounts?page=1\" } ... } ``` For endpoints that return resources that have an inherent temporal order (for example transactions, for which one transaction must follow another), cursors are supported. The `before` and `after` query parameters allow cursor like pagination, where the value of each is the id of the resource to continue pagination. ## Filtering List (index) endpoints sometimes expose query parameters which allow the responses to be limited to resources matching the given filters. In the case that an invalid filter value is specified a status code of 404 with a detailed explanation is returned. ## Working with money We support different currencies, for resources in all of these currencies, the amount is in the smallest common currency unit - this is the amount in cents (or pence, or similarly named unit). For example, to specify for $1.00 or 1.00, you would set amount=100 (100 cents of the respective currency). For zero-decimal currencies, we use the regular denomination. For example, a transaction of 1 Yen, you should set amount=1 (1 JPY), since 1 is the smallest currency unit. ## Request IDs Each API request has an associated request identifier in the response headers, under Request-Id. You can also find request identifiers in the URLs of individual request logs in your Dashboard. If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution. # noqa: E501 + """ +) diff --git a/test-requirements.txt b/test-requirements.txt new file mode 100644 index 0000000..2702246 --- /dev/null +++ b/test-requirements.txt @@ -0,0 +1,5 @@ +coverage>=4.0.3 +nose>=1.3.7 +pluggy>=0.3.1 +py>=1.4.31 +randomize>=0.13