Mock sample for your project: Up API

Integrate with "Up API" from up.com.au in no time with Mockoon's ready to use mock sample

Up API

up.com.au

Version: v1


Use this API in your project

Speed up your application development by using "Up API" ready-to-use mock sample. Mocking this API will allow you to start working in no time. No more accounts to create, API keys to provision, accesses to configure, unplanned downtime, just work.
It also improves your integration tests' quality and reliability by accounting for random failures, slow response time, etc.

Description

The Up API gives you programmatic access to your balances and
transaction data. You can request past transactions or set up
webhooks to receive real-time events when new transactions hit your
account. It’s new, it’s exciting and it’s just the beginning.

Other APIs in the same category

Storecove API

storecove.com
Storecove API

ATM Locator API

hsbc.com

API v1.0.0

envoice.in
Run in Postman
or
View Postman docs
Quickstart
Visit github to view the quickstart tutorial.
Tutorial for running the API in postman
Click on ""Run in Postman"" button
postman - tutorial - 1
---
A new page will open.
Click the ""Postman for windows"" to run postman as a desktop app.
Make sure you have already installed Postman.
postman - tutorial - 2
---
In chrome an alert might show up to set a default app for opening postman links. Click on ""Open Postman"".
postman - tutorial - 3
---
The OpenAPI specification will be imported in Postman as a new collection named ""Envoice api""
postman - tutorial - 4
---
When testing be sure to check and modify the environment variables to suit your api key and secret. The domain is set to envoice's endpoint so you don't really need to change that.
\*Eye button in top right corner
postman - tutorial - 5
postman - tutorial - 6
---
You don't need to change the values of the header parameters, because they will be replaced automatically when you send a request with real values from the environment configured in the previous step.
postman - tutorial - 7
---
Modify the example data to suit your needs and send a request.
postman - tutorial - 8
Webhooks
Webhooks allow you to build or set up Envoice Apps which subscribe to invoice activities.
When one of those events is triggered, we'll send a HTTP POST payload to the webhook's configured URL.
Webhooks can be used to update an external invoice data storage.
In order to use webhooks visit this link and add upto 10 webhook urls that will return status 200 in order to signal that the webhook is working.
All nonworking webhooks will be ignored after a certain period of time and several retry attempts.
If after several attempts the webhook starts to work, we will send you all activities, both past and present, in chronological order.
The payload of the webhook is in format:

Open Data API

openbanking.org.uk
Latest Swagger specification for OpenData

Nordigen Account Information Services API

nordigen.com

Portfolio Optimizer

Portfolio Optimizer is a Web API to optimize the composition of investment portfolios (collection of financial assets such as stocks, bonds, ETFs, crypto-currencies) using modern portfolio theory-like algorithms (mean-variance, etc.).
API General Information
Portfolio Optimizer is based on REST for easy integration, uses JSON for the exchange of data and uses the two most common HTTP verbs (GET, POST) to represent the actions.
Portfolio Optimizer is also as secured as a Web API could be:
256-bit HTTPS Encryption
No usage of cookies
No usage of personal data
API Headers
The following HTTP header(s) are required when calling Portfolio Optimizer endpoints:
Content-type: application/json
This header specifies that the data provided in input to the endpoint is in JSON format
The following HTTP header(s) are optional when calling Portfolio Optimizer endpoints:
X-API-Key:
This header enables authenticated users to provide their private API key in order to benefit from higher API limits
API Key
Portfolio Optimizer is free to use, but not free to run.
In order to obtain an API key and benefit from higher API limits, a small participation to Portfolio Optimizer running costs is required.
This participation takes the form of coffee(s), with one coffee = one month of usage.
Notes:
> * Please make sure not to expose your API key publicly!
API Limits
Portfolio Optimizer comes with fairly reasonable API limits.
For anonymous users:
The API requests are restricted to a subset of all the available endpoints and/or endpoints features
The API requests are limited to 1 request per second for all the anonymous users combined, with concurrent requests rejected
The API requests are limited to 1 second of execution time
The API requests are limited to 20 assets, 100 portfolios, 500 series data points and 5 factors
For authenticated users with an API key:
The API requests have access to all the available endpoints and endpoints features
The API requests are limited to 10000 requests per 24 hour per API key, with concurrent requests queued
The API requests are limited to 2.5 seconds of execution time
The API requests are limited to 100 assets, 500 portfolios, 2500 series data points and 25 factors
> Notes:
> * It is possible to further relax the API limits, or to disable the API limits alltogether; please contact the support for more details.
> * Information on the API rate limits are provided in response messages HTTP headers x-ratelimit-*:
> * x-ratelimit-limit-second, the limit on the number of API requests per second
> * x-ratelimit-remaining-second, the number of remaining API requests in the current second
> * x-ratelimit-limit-minute, the limit on the number of API requests per minute
> * ...
API Regions
Portfolio Optimizer servers are located in Western Europe.
> Notes:
> * It is possible to deploy Portfolio Optimizer in other geographical regions, for example to improve the API latency; please contact the support for more details.
API Response Codes
Standard HTTP response codes are used by Portfolio Optimizer to provide details on the status of API requests.
| HTTP Code | Description | Notes |
| --------- | ----------- | ----- |
| 200 | Request successfully processed | - |
| 400 | Request failed to be processed because of incorrect content | The response message body contains information on the incorrect content |
| 401 | Request failed to be processed because of invalid API key | - |
| 404 | Request failed to be processed because of non existing endpoint | The requested endpoint might exist, but needs to be accessed with another HTTP method (e.g., POST instead of GET) |
| 429 | Request failed to be processed because of API limits violated | The response message HTTP headers x-ratelimit-* contain information on the API limits |
| 500 | Request failed to be processed because of an internal error | Something went wrong on Portfolio Optimizer side, do not hesitate to report the issue |
| 502 | Request failed to be processed because of a temporary connectivity error | Something went wrong on Portfolio Optimizer side, please check the API status and do not hesitate to report the issue |
API Status
Portfolio Optimizer is monitored 24/7 by UptimeRobot.
Support
For any issue or question about Portfolio Optimizer, please do not hesitate to contact the support.

IBKR 3rd Party Web API

interactivebrokers.com
Interactive Brokers Web API for 3rd Party Companies

VAT API

vatapi.com
A developer friendly API to help your business achieve VAT compliance

Swiss NextGen Banking API-Framework

Summary
The Swiss NextGen API is based on the NextGenPSD2 Framework Version 1.3.4 of the Berlin Group which offers a modern, open, harmonised and interoperable set of
Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely.
The NextGen Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards
in Europe and, aligned with the goals of the Euro Retail Payments Board,
enables European banking customers to benefit from innovative products and services ('Banking as a Service')
by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data.
The Swiss edtion refines the message formats specific to Switzerland and defines some matching examples.
The possible Approaches are:
Redirect SCA Approach
(Not recommended by obp.ch community) OAuth SCA Approach
(Not recommended by obp.ch community) Decoupled SCA Approach
(Not recommended by obp.ch community) Embedded SCA Approach without SCA method
(Not recommended by obp.ch community) Embedded SCA Approach with only one SCA method available
(Not recommended by obp.ch community) Embedded SCA Approach with Selection of a SCA method
Not every message defined in this API definition is necessary for all approaches.
Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional
Therefore for a particular implementation of a compliant API it is only necessary to support
a certain subset of the methods defined in this API definition.
**Please have a look at the implementation guidelines if you are not sure
which message has to be used for the approach you are going to use.**
Some General Remarks Related to this version of the OpenAPI Specification:
This API definition is based on the Implementation Guidelines of the Berlin Group API.
It is not a replacement in any sense.
The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group API.
This API definition contains the REST-API for requests from the PISP to the ASPSP.
This API definition contains the messages for all different approaches defined in the Implementation Guidelines.
According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md]
"If in is "header" and the name field is "Accept", "Content-Type" or "Authorization", the parameter definition SHALL be ignored."
The element "Accept" will not be defined in this file at any place.
The elements "Content-Type" and "Authorization" are implicitly defined by the OpenApi tags "content" and "security".
There are several predefined types which might occur in payment initiation messages,
but are not used in the standard JSON messages in the Implementation Guidelines.
Therefore they are not used in the corresponding messages in this file either.
We added them for the convenience of the user.
If there is a payment product, which needs these fields, one can easily use the predefined types.
But the ASPSP need not to accept them in general.
**We omit the definition of all standard HTTP header elements (mandatory/optional/conditional)
except they are mentioned in the Implementation Guidelines.**
Therefore the implementer might add these in his own realisation of a comlient API in addition to the elements defined in this file.
General Remarks on Data Types
The Berlin Group definition of UTF-8 strings in context of the API have to support at least the following characters
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ' +
Space

1Forge Finance APIs

Stock and Forex Data and Realtime Quotes

Sonar Trading

sonar.trading
Currency Authority: Exchange Rate of 1453 country currencies and crypto currencies

PayRun.IO

Open, scableable, transparent payroll API.