Mock sample for your project: YNAB API Endpoints
Integrate with "YNAB API Endpoints" from youneedabudget.com in no time with Mockoon's ready to use mock sample
YNAB API Endpoints
youneedabudget.com
Version: 1.0.0
Speed up your application development by using "YNAB API Endpoints" ready-to-use mock sample. Mocking this API will help you accelerate your development lifecycles and allow you to stop relying on an external API to get the job done. No more API keys to provision, accesses to configure or unplanned downtime, just work.
Enhance your development infrastructure by mocking third party APIs during integrating testing.
Description
Our API uses a REST based design, leverages the JSON data format, and relies upon HTTPS for transport. We respond with meaningful HTTP response codes and if an error occurs, we include error details in the response body. API Documentation is at https://api.youneedabudget.com
Other APIs in the same category
ATM Locator API
hsbc.com
Tradeworks
magick.nu
Authentication is required to access all methods of the API. Enter username and password.
Credentials are automatically set as you type.
Credentials are automatically set as you type.
Paylocity API
paylocity.com
For general questions and support of the API, contact: [email protected]
Overview
Paylocity Web Services API is an externally facing RESTful Internet protocol. The Paylocity API uses HTTP verbs and a RESTful endpoint structure. OAuth 2.0 is used as the API Authorization framework. Request and response payloads are formatted as JSON.
Paylocity supports v1 and v2 versions of its API endpoints. v1, while supported, won't be enhanced with additional functionality. For direct link to v1 documentation, please click here. For additional resources regarding v1/v2 differences and conversion path, please contact [email protected].
Setup
Paylocity will provide the secure client credentials and set up the scope (type of requests and allowed company numbers). You will receive the unique client id, secret, and Paylocity public key for the data encryption. The secret will expire in 365 days.
Paylocity will send you an e-mail 10 days prior to the expiration date for the current secret. If not renewed, the second e-mail notification will be sent 5 days prior to secret's expiration. Each email will contain the code necessary to renew the client secret.
You can obtain the new secret by calling API endpoint using your current not yet expired credentials and the code that was sent with the notification email. For details on API endpoint, please see Client Credentials section.
Both the current secret value and the new secret value will be recognized during the transition period. After the current secret expires, you must use the new secret.
If you were unable to renew the secret via API endpoint, you can still contact Service and they will email you new secret via secure email.
When validating the request, Paylocity API will honor the defaults and required fields set up for the company default New Hire Template as defined in Web Pay.
Authorization
Paylocity Web Services API uses OAuth2.0 Authentication with JSON Message Format.
All requests of the Paylocity Web Services API require a bearer token which can be obtained by authenticating the client with the Paylocity Web Services API via OAuth 2.0.
The client must request a bearer token from the authorization endpoint:
auth-server for production: https://api.paylocity.com/IdentityServer/connect/token
auth-server for testing: https://apisandbox.paylocity.com/IdentityServer/connect/token
Paylocity reserves the right to impose rate limits on the number of calls made to our APIs. Changes to API features/functionality may be made at anytime with or without prior notice.
Authorization Header
The request is expected to be in the form of a basic authentication request, with the "Authorization" header containing the client-id and client-secret. This means the standard base-64 encoded user:password, prefixed with "Basic" as the value for the Authorization header, where user is the client-id and password is the client-secret.
Content-Type Header
The "Content-Type" header is required to be "application/x-www-form-urlencoded".
Additional Values
The request must post the following form encoded values within the request body:
granttype = clientcredentials
scope = WebLinkAPI
Responses
Success will return HTTP 200 OK with JSON content:
{
"access_token": "xxx",
"expires_in": 3600,
"token_type": "Bearer"
}
Encryption
Paylocity uses a combination of RSA and AES cryptography. As part of the setup, each client is issued a public RSA key.
Paylocity recommends the encryption of the incoming requests as additional protection of the sensitive data. Clients can opt-out of the encryption during the initial setup process. Opt-out will allow Paylocity to process unencrypted requests.
The Paylocity Public Key has the following properties:
2048 bit key size
PKCS1 key format
PEM encoding
Properties
key (base 64 encoded): The AES symmetric key encrypted with the Paylocity Public Key. It is the key used to encrypt the content. Paylocity will decrypt the AES key using RSA decryption and use it to decrypt the content.
iv (base 64 encoded): The AES IV (Initialization Vector) used when encrypting the content.
content (base 64 encoded): The AES encrypted request. The key and iv provided in the secureContent request are used by Paylocity for decryption of the content.
We suggest using the following for the AES:
CBC cipher mode
PKCS7 padding
128 bit block size
256 bit key size
Encryption Flow
Generate the unencrypted JSON payload to POST/PUT
Encrypt this JSON payload using your own key and IV (NOT with the Paylocity public key)
RSA encrypt the key you used in step 2 with the Paylocity Public Key, then, base64 encode the result
Base64 encode the IV used to encrypt the JSON payload in step 2
Put together a "securecontent" JSON object:
{
'secureContent' : {
'key' : -- RSA-encrypted & base64 encoded key from step 3,
'iv' : -- base64 encoded iv from step 4
'content' -- content encrypted with your own key from step 2, base64 encoded
}
}
Sample Example
{
"secureContent": {
"key": "eS3aw6H/qzHMJ00gSi6gQ3xa08DPMazk8BFY96Pd99ODA==",
"iv": "NLyXMGq9svw0XO5aI9BzWw==",
"content": "gAEOiQltO1w+LzGUoIK8FiYbU42hug94EasSl7N+Q1w="
}
}
Sample C# Code
using Newtonsoft.Json;
using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;
public class SecuredContent
{
[JsonProperty("key")]
public string Key { get; set; }
[JsonProperty("iv")]
public string Iv { get; set; }
[JsonProperty("content")]
public string Content { get; set; }
}
public class EndUserSecureRequestExample
{
public string CreateSecuredRequest(FileInfo paylocityPublicKey, string unsecuredJsonRequest)
{
string publicKeyXml = File.ReadAllText(paylocityPublicKey.FullName, Encoding.UTF8);
SecuredContent secureContent = this.CreateSecuredContent(publicKeyXml, unsecuredJsonRequest);
string secureRequest = JsonConvert.SerializeObject(new { secureContent });
return secureRequest;
}
private SecuredContent CreateSecuredContent(string publicKeyXml, string request)
{
using (AesCryptoServiceProvider aesCsp = new AesCryptoServiceProvider())
{
aesCsp.Mode = CipherMode.CBC;
aesCsp.Padding = PaddingMode.PKCS7;
aesCsp.BlockSize = 128;
aesCsp.KeySize = 256;
using (ICryptoTransform crt = aesCsp.CreateEncryptor(aesCsp.Key, aesCsp.IV))
{
using (MemoryStream outputStream = new MemoryStream())
{
using (CryptoStream encryptStream = new CryptoStream(outputStream, crt, CryptoStreamMode.Write))
{
byte[] encodedRequest = Encoding.UTF8.GetBytes(request);
encryptStream.Write(encodedRequest, 0, encodedRequest.Length);
encryptStream.FlushFinalBlock();
byte[] encryptedRequest = outputStream.ToArray();
using (RSACryptoServiceProvider crp = new RSACryptoServiceProvider())
{
crp.FromXmlstring(publicKeyXml);
byte[] encryptedKey = crp.Encrypt(aesCsp.Key, false);
return new SecuredContent()
{
Key = Convert.ToBase64string(encryptedKey),
Iv = Convert.ToBase64string(aesCsp.IV),
Content = Convert.ToBase64string(encryptedRequest)
};
}
}
}
}
}
}
}
Support
Questions about using the Paylocity API? Please contact [email protected].
Deductions (v1)
Deductions API provides endpoints to retrieve, add, update and delete deductions for a company's employees. For schema details, click here.
OnBoarding (v1)
Onboarding API sends employee data into Paylocity Onboarding to help ensure an easy and accurate hiring process for subsequent completion into Web Pay. For schema details, click here.
Overview
Paylocity Web Services API is an externally facing RESTful Internet protocol. The Paylocity API uses HTTP verbs and a RESTful endpoint structure. OAuth 2.0 is used as the API Authorization framework. Request and response payloads are formatted as JSON.
Paylocity supports v1 and v2 versions of its API endpoints. v1, while supported, won't be enhanced with additional functionality. For direct link to v1 documentation, please click here. For additional resources regarding v1/v2 differences and conversion path, please contact [email protected].
Setup
Paylocity will provide the secure client credentials and set up the scope (type of requests and allowed company numbers). You will receive the unique client id, secret, and Paylocity public key for the data encryption. The secret will expire in 365 days.
Paylocity will send you an e-mail 10 days prior to the expiration date for the current secret. If not renewed, the second e-mail notification will be sent 5 days prior to secret's expiration. Each email will contain the code necessary to renew the client secret.
You can obtain the new secret by calling API endpoint using your current not yet expired credentials and the code that was sent with the notification email. For details on API endpoint, please see Client Credentials section.
Both the current secret value and the new secret value will be recognized during the transition period. After the current secret expires, you must use the new secret.
If you were unable to renew the secret via API endpoint, you can still contact Service and they will email you new secret via secure email.
When validating the request, Paylocity API will honor the defaults and required fields set up for the company default New Hire Template as defined in Web Pay.
Authorization
Paylocity Web Services API uses OAuth2.0 Authentication with JSON Message Format.
All requests of the Paylocity Web Services API require a bearer token which can be obtained by authenticating the client with the Paylocity Web Services API via OAuth 2.0.
The client must request a bearer token from the authorization endpoint:
auth-server for production: https://api.paylocity.com/IdentityServer/connect/token
auth-server for testing: https://apisandbox.paylocity.com/IdentityServer/connect/token
Paylocity reserves the right to impose rate limits on the number of calls made to our APIs. Changes to API features/functionality may be made at anytime with or without prior notice.
Authorization Header
The request is expected to be in the form of a basic authentication request, with the "Authorization" header containing the client-id and client-secret. This means the standard base-64 encoded user:password, prefixed with "Basic" as the value for the Authorization header, where user is the client-id and password is the client-secret.
Content-Type Header
The "Content-Type" header is required to be "application/x-www-form-urlencoded".
Additional Values
The request must post the following form encoded values within the request body:
granttype = clientcredentials
scope = WebLinkAPI
Responses
Success will return HTTP 200 OK with JSON content:
{
"access_token": "xxx",
"expires_in": 3600,
"token_type": "Bearer"
}
Encryption
Paylocity uses a combination of RSA and AES cryptography. As part of the setup, each client is issued a public RSA key.
Paylocity recommends the encryption of the incoming requests as additional protection of the sensitive data. Clients can opt-out of the encryption during the initial setup process. Opt-out will allow Paylocity to process unencrypted requests.
The Paylocity Public Key has the following properties:
2048 bit key size
PKCS1 key format
PEM encoding
Properties
key (base 64 encoded): The AES symmetric key encrypted with the Paylocity Public Key. It is the key used to encrypt the content. Paylocity will decrypt the AES key using RSA decryption and use it to decrypt the content.
iv (base 64 encoded): The AES IV (Initialization Vector) used when encrypting the content.
content (base 64 encoded): The AES encrypted request. The key and iv provided in the secureContent request are used by Paylocity for decryption of the content.
We suggest using the following for the AES:
CBC cipher mode
PKCS7 padding
128 bit block size
256 bit key size
Encryption Flow
Generate the unencrypted JSON payload to POST/PUT
Encrypt this JSON payload using your own key and IV (NOT with the Paylocity public key)
RSA encrypt the key you used in step 2 with the Paylocity Public Key, then, base64 encode the result
Base64 encode the IV used to encrypt the JSON payload in step 2
Put together a "securecontent" JSON object:
{
'secureContent' : {
'key' : -- RSA-encrypted & base64 encoded key from step 3,
'iv' : -- base64 encoded iv from step 4
'content' -- content encrypted with your own key from step 2, base64 encoded
}
}
Sample Example
{
"secureContent": {
"key": "eS3aw6H/qzHMJ00gSi6gQ3xa08DPMazk8BFY96Pd99ODA==",
"iv": "NLyXMGq9svw0XO5aI9BzWw==",
"content": "gAEOiQltO1w+LzGUoIK8FiYbU42hug94EasSl7N+Q1w="
}
}
Sample C# Code
using Newtonsoft.Json;
using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;
public class SecuredContent
{
[JsonProperty("key")]
public string Key { get; set; }
[JsonProperty("iv")]
public string Iv { get; set; }
[JsonProperty("content")]
public string Content { get; set; }
}
public class EndUserSecureRequestExample
{
public string CreateSecuredRequest(FileInfo paylocityPublicKey, string unsecuredJsonRequest)
{
string publicKeyXml = File.ReadAllText(paylocityPublicKey.FullName, Encoding.UTF8);
SecuredContent secureContent = this.CreateSecuredContent(publicKeyXml, unsecuredJsonRequest);
string secureRequest = JsonConvert.SerializeObject(new { secureContent });
return secureRequest;
}
private SecuredContent CreateSecuredContent(string publicKeyXml, string request)
{
using (AesCryptoServiceProvider aesCsp = new AesCryptoServiceProvider())
{
aesCsp.Mode = CipherMode.CBC;
aesCsp.Padding = PaddingMode.PKCS7;
aesCsp.BlockSize = 128;
aesCsp.KeySize = 256;
using (ICryptoTransform crt = aesCsp.CreateEncryptor(aesCsp.Key, aesCsp.IV))
{
using (MemoryStream outputStream = new MemoryStream())
{
using (CryptoStream encryptStream = new CryptoStream(outputStream, crt, CryptoStreamMode.Write))
{
byte[] encodedRequest = Encoding.UTF8.GetBytes(request);
encryptStream.Write(encodedRequest, 0, encodedRequest.Length);
encryptStream.FlushFinalBlock();
byte[] encryptedRequest = outputStream.ToArray();
using (RSACryptoServiceProvider crp = new RSACryptoServiceProvider())
{
crp.FromXmlstring(publicKeyXml);
byte[] encryptedKey = crp.Encrypt(aesCsp.Key, false);
return new SecuredContent()
{
Key = Convert.ToBase64string(encryptedKey),
Iv = Convert.ToBase64string(aesCsp.IV),
Content = Convert.ToBase64string(encryptedRequest)
};
}
}
}
}
}
}
}
Support
Questions about using the Paylocity API? Please contact [email protected].
Deductions (v1)
Deductions API provides endpoints to retrieve, add, update and delete deductions for a company's employees. For schema details, click here.
OnBoarding (v1)
Onboarding API sends employee data into Paylocity Onboarding to help ensure an easy and accurate hiring process for subsequent completion into Web Pay. For schema details, click here.
Ntropy Transaction API
ntropy.network
Ntropy Transaction API for transaction classification & management
Contact Support:
Name: API Support
Email: [email protected]
Contact Support:
Name: API Support
Email: [email protected]
Xero OAuth 2 Identity Service API
These endpoints are related to managing authentication tokens and identity for Xero API
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
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
Afterbanks API
afterbanks.com
La estandarización de la conexión con cualquier banco en tiempo real.
Big Red Cloud API
bigredcloud.com
Welcome to the Big Red Cloud API
This API enables programmatic access to Big Red Cloud data.
We have used Swagger to auto generate the API documentation on this page, and it also enables direct interaction with the API in this page.
To get started, you will require an API Key - check out our guide at https://www.bigredcloud.com/support/generating-api-key-guide/ for information on how to get one.
Use the 'Enter API Key' button below to enter your API key and start interacting with your Big Red Cloud data right on this page.
The API key will be stored in your browsers local storage for convenience, but you will be able to delete it at any time if you wish.
For additional information on the API, check out our support article at https://www.bigredcloud.com/support/api/
This API enables programmatic access to Big Red Cloud data.
We have used Swagger to auto generate the API documentation on this page, and it also enables direct interaction with the API in this page.
To get started, you will require an API Key - check out our guide at https://www.bigredcloud.com/support/generating-api-key-guide/ for information on how to get one.
Use the 'Enter API Key' button below to enter your API key and start interacting with your Big Red Cloud data right on this page.
The API key will be stored in your browsers local storage for convenience, but you will be able to delete it at any time if you wish.
For additional information on the API, check out our support article at https://www.bigredcloud.com/support/api/
Billingo API v3
This is a Billingo API v3 documentation. Our API based on REST software architectural style. API has resource-oriented URLs, accepts JSON-encoded request bodies and returns JSON-encoded responses. To use this API you have to generate a new API key on our site. After that, you can test your API key on this page.