/
NZ Banking Data API Specification v2.0-rc1

NZ Banking Data API Specification v2.0-rc1

Version Control

Version

Date

Author

Comments

Version

Date

Author

Comments

1.0.0

01 March 2019

Payments NZ API Working Group

Baseline

v2.0-draft1

Jun 4, 2019 

@Gavin Wong (Unlicensed)

Updates:

  • Combined duplication in draft1-Overview, "Payments NZ API Standards Overview" and "Steps" into one draft1-Overview section

  • Updated draft1-OverviewDiagram to reflect change in terminology in draft1-Steps

  • Updated draft1-Steps to:

    • Step 1: Agree Consent

    • Step 2: Create Consent

    • Step 3: Authorise Consent

    • Step 4: Access Protected Resources

    • Step 5: Retrieve Consent Status

  • draft1-MessageSigning section updated to reflect that "Message signing must not be implemented"

  • Updated draft1-UniqueIdentifiers(IdFields) "An API Provider that chooses to populate optional Id fields must ensure that the values are unique and immutable." to "An API Provider must ensure that populated Id fields values are unique and immutable." as this statement applies to mandatory Id fields also.

  • Consolidated duplication in draft1-Actors section - two tables to one table

  • Updated draft1-DateFormats - example header date from UTC to GMT as per standard

  • Updated draft1-ResourceURIPathStructure to align with OBIE v3.1.2 - but removed the PSD2 role from the path

  • Renamed NZ Banking Data API Specification v2.0-draft3#draft1-403(Forbidden)v/s404(NotFound)v/s501(NotImplemented) section to include 501 (Not Implemented)

  • Updated draft1-RequestHeaders:

    • x-fapi-customer-last-logged-time updated to x-fapi-auth-date (per latest FAPI spec). Aligned definition of date type (per OBIE v3.1.2 spec)

    • Accept header - reworded for clarity that "For requests to API endpoints that respond only with JSON, the Accept header must be set to value application/json." from "If specified, it must indicate that the only a JSON response is accepted (e.g by setting the value to application/json) as a content header for all endpoints that respond with JSON."

  • Updated draft1-ResponseHeaders - Content-Type aligned with Accept header rewording; updated Content-Type to Mandatory (align with OBIE v3.1.2)

  • Updated section title "Return & Error Codes" to draft1-HTTPStatusCodes

  • Update draft1-Idempotency: 

    • To reflect guidance is for "If an idempotency key is required for an API endpoint" rather than "If idempotency is implemented for an API endpoint" (align OBIE v3.1.2)

    • To also reflect that the Third Party must not modify headers or parameters in an idempotent request - updated "The Third Party must not change the request body while using the same x-idempotency-key. " to "The Third Party must not change any part of an API request (i.e., parameters, header or body) while using the same x-idempotency-key. "

  • Updated draft1-Pagination section to clarify must, should, may behaviour. As per previous NZ WG decision - First and Last links are now mandatory.

  • Updated draft1-Archiving to refer to consent instead of intent

  • Separated "Scope and Grant Types" section to draft1-Scopes and draft1-SupportedGrantTypes

  • Reworded NZ Banking Data API Specification v2.0-draft3#draft1-ConsentAuthorisation section to make authorisation flow generic (not specific to the redirect flow)

  • Updated section heading "Changes to an Intent's Authorised State:" to draft1-ChangestoConsentStatus

  • Moved "Effect of Token Expiry on an Intent's Authorized State" section to new section on draft1-TokenExpiry, and clarified how access and refresh token expiration are communicated (per OBIE v3.1.2)

  • Aligned draft1-UsageExamples to rest of the specification

Additions:

Removed:

  • Reference in draft1-Standards to "The initial scope of these Standards is limited to current scope - i.e., PNZ API pilot. However, the intention is that the scope of the Standards will extend to include additional resources and APIs."

  • Reference in draft1-AgnostictoPaymentSchemes to "further mapping guidance to ensure that differences are understood between the Open Banking Payment API standard, and BECS payments"

  • Removed from draft1-RequestHeaders the x-fapi-financial-id (update to FAPI) and x-jws-signature headers (as per scope)

  • Removed from draft1-ResponseHeaders x-jws-signature header (as per scope)

Errata:

v2.0-draft2

Jul 8, 2019 

@Gavin Wong (Unlicensed)

Updates:

Additions:

Removed:

  • References to "intent-id" - the Security Profile will be updated to explain that the "intent-id" within the profile is the ConsentId

  • Removed references to "payments" and "accounts" scopes in draft2-Pre-Conditions as these are duplicated

  • Reference to "Payments" member in draft2-Links section

Errata:

v2.0-draft3

Oct 1, 2019 

@Gavin Wong (Unlicensed)

Updates:

Additions:

Errata:

  • Typos

Overview

The NZ Banking Data API Specification was designed to create an API based payments ecosystem for NZ and simplify partnering in the payments industry. These standards enable Banks to develop API endpoints to an agreed standard so that Third Parties can build web and mobile applications that make it easier for banking customers to pay for goods and services. This main specification provides a description of the elements that are common across all the NZ Banking Data APIs.

This specification should be read in conjunction with the individual NZ Banking API Specifications for:

  • Account Information API Specification

  • Payment Initiation API Specification

The PNZ API standards are based on the UK Open Banking standard. The PNZ API standards include adjustments to and place limitations on the UK Open Banking standard to make the standards more suitable to the NZ market. The Open Banking standard is now in the public domain; the PNZ API standards are not in the public domain as they are currently under development. Access to the PNZ API standards is currently limited to those organisations approved/authorised to operate in the NZ payments API ecosystem - Bank's and Third Parties. Approval and authorisation is managed by Payments NZ.

Overview Diagram

The figure below provides a general outline of a flow using the NZ Banking Data APIs.

Steps

Step 1: Agree Consent

  • This flow begins with a Customer consenting to allow a Third Party to access the Customer's protected resources with the API Provider.

Step 2: Create Consent

  • The Third Party connects to the API Provider that services the Customer's account(s) and creates a consent resource.

  • The API Provider responds with an identifier for the consent resource (the ConsentId).

Step 3: Authorise Consent

  • The Third Party initiates the authorisation flow for the Customer to authorise the consent.

  • The Customer authorises the consent with the API Provider. The Customer will only be able to authorise or reject the consent details in its entirety.

Step 4: Access Protected Resources

  • The API Provider authenticates the Third Party and Customer has authorised consent for the request before providing access to protected resources.

Step 5: Retrieve Consent Status

  • The Third Party may retrieve the status of the consent (with the ConsentId).

Document Structure

This document consists of the following parts:

  • Overview: Provides an overview of the Payments NZ API Standards and the key decisions and principles that contributed to the specification.

  • Basics: The section begins with an introduction to how the APIs are used.

  • Security & Access Control: Specifies the means for Third Parties and Customers to authenticate themselves and provide consent.

  • Data Model: Describes the data model for the API payloads.

Known Issues

This document and its sub-pages must be read in conjunction with the Known Issues Log.

Design Principles

RESTful APIs

The API adheres to RESTful API concepts where possible and sensible to do so.

However, the priority is to have an API that is simple to understand and easy to use. In instances where following RESTful principles would be convoluted and complex, the principles have not been followed.

References:

  • Best Practice has also been taken from the Data Description Language for APIs; JSON API : http://jsonapi.org/

  • The Interface Description Language used is the Swagger Specification version 2.0 (also known as Open API) : http://swagger.io/

Standards

The PNZ API Working Group principles for developing API standards:

  • PNZ API Working Group will adopt existing standards where relevant/appropriate to minimise re-inventing the wheel.

  • PNZ API Working Group will work with other relevant bodies to align with, contribute to and/or adopt other Standards work, especially relating to Open Banking UK.

Extensibility

It is intended that the API flows will be extended to cater for more complex use-cases in subsequent releases, and we have kept this in mind during the design.

Idempotency

Idempotency is difficult to implement consistently and leverage consistently. 

As a result, idempotency is used sparingly in these specifications; with a preference to allow Third Parties to simply re-submit a request under failure conditions.

APIs have been defined to be idempotent, where not doing so would cause a poor Customer user-experience or increase false positive risk indicators.

Message Signing

Message signing must not be implemented for the Account Information API and Payment Initiation API request and responses.

Message Encryption

Message encryption must not be implemented for the Account Information API and Payment Initiation API request and responses.

Agnostic to Payment Schemes

The API will be designed so that it is agnostic to the underlying payment scheme that is responsible for carrying out the payment.

Status Codes

API responses use two status codes that serve two different purposes:

  • The HTTP Status Code reflects the outcome of the API call (the HTTP operation on the resource). Granular Functional Error Codes are specified as part of API Error Response Structure.

  • The Status field in a resource payload reflects the status of the resource.

Communicating a rejection status is done in two ways:

  • If the API Provider establishes a rejection scenario with payload or any contextual error during the API call, the API Provider must reject the request immediately with a 400 (Bad Request).

  • If the API Provider establishes a rejection scenario with the consent after the API call, the API Provider must set the Status of the consent resource to Rejected.

Unique Identifiers (Id Fields)

A REST resource should have a unique identifier (e.g. a primary key) that may be used to identify the resource. These unique identifiers are used to construct URLs to identify and address specific resources.

However, considering that some of the resources described in this specification do not have a primary key in the system of record, the Id fields will be optional for some resources.

An API Provider must ensure that populated Id fields values are unique and immutable.

Categorisation of Implementation Requirements

The functionality, endpoints and fields within each resource are categorised as 'Mandatory' or 'Optional'.

API Providers must make documentation available to Third Parties (e.g. on their developer portals) specifying which 'Optional' endpoints and fields are implemented for any given implementation of the specification.

Mandatory

For functionalities and endpoints: 

  • An API Provider must implement an endpoint that is marked Mandatory.

  • An API Provider must implement functionality that is marked Mandatory.

For fields:

  • A Third Party must specify the value of a Mandatory field.

  • An API Provider must process a Mandatory field when provided by the Third Party in an API request.

  • An API Provider must include meaningful values for Mandatory fields in an API response.

Optional

For functionalities and endpoints:

  • An API Provider may implement an Optional endpoint.

  • An API Provider may implement Optional functionality.

For fields:

  • A Third Party may specify the value of an Optional field.

  • An API Provider must process an Optional field when provided by the Third Party in an API request. If the API Provider cannot support a particular value in an Optional field, the API Provider must reject the request and respond with an error.

  • An API Provider may specify the value of an Optional field in an API response.

Open Banking UK

The principles we have applied to re-use of the Open Banking UK specifications are:

  • Only resources that are required will be included in the API specification.

  • We will modify Open Banking UK elements where the existing standard does not cater for the NZ Market (such as adding the "BECSElectronicCredit" Scheme). 

Basics

Actors

In the NZ context, there are three main actors (API Provider, Third Party, and Customer).

The upstream Open Banking UK standard uses PSD2 parlance and acronyms that are not applicable or relevant to the New Zealand market. Below is a summary of the NZ equivalent for many common PSD2 terms.

Actor

Type

PSD2 Actor

NZ Description

Actor

Type

PSD2 Actor

NZ Description

API Provider

Legal Entity

Account Servicing Payment Service Provider (ASPSP)

API Provider refers to a Registered Bank or Non-Bank Deposit Taker that has been accredited by the Payments NZ API Standards Body to utilise its API specifications and standards, and contribute to the standards ecosystem. The API Provider provides APIs in a manner that complies with the API Standards (e.g. Account Information and Payment Initiation APIs), and connects those APIs with a Third Party(s).

Third Party

Legal Entity

Third Party Provider (TPP)

  • Account Information Service Provider (AISP)

  • Payment Initiation Service Provider (PISP)

Third Party refers to a legal entity that has been accredited by the Payments NZ API Standards Body to utilise its API specifications and standards, and contribute to the standards ecosystem. The Third Party is the entity that consumes an API in a manner that complies with the API Standards.

References to a "Third Party" in the specification relate to a piece of registered software with an API Provider (with a specific client_id).

A Third Party may engage in either or both of these services:

  • Payment initiation services

  • Account information services

Customer

Person

Payment Service User (PSU)

Individuals who operate retail banking accounts who make use of an account information service or payment service. The banking accounts may be personal accounts or associated with businesses, trusts, etc.

Merchant

Legal Entity



Merchant refers to a legal entity that interacts with the Customer and Third Party in an interaction not defined within the API specifications and standards.

Character Encoding

The API requests and responses must use a UTF-8 character encoding. This is the default character encoding for JSON (RFC 7158 - Section 8.1).

However, an API Provider's downstream system may not accept some UTF-8 characters, such as emoji characters (e.g. "Happy Birthday 🎂🎂!" may not be an acceptable Payment Reference). If the API Provider rejects the message with a UTF-8 character that cannot be processed, the API Provider must respond with an HTTP 400 (Bad Request) status code.

Date Formats

An API Provider must accept all valid ISO-8601 date formats including its permitted variations (e.g. variations in how the timezone is defined, dates with or with a seconds or milliseconds part etc.) in the requests.

All dates in the JSON payloads are represented in ISO 8601 date-time format. All date-time fields in responses must include the timezone. For Example:

2017-04-05T10:43:07+00:00

All dates in the query string (e.g., filter parameters) are represented in ISO 8601 date-time format and must not include the timezone.

If the DateTime contains a timezone, the API Provider must ignore the timezone component. The filter values will be assumed to refer to the same timezone as the timezone in which the resource is maintained.

For example:

2017-04-05T10:43:07 2017-04-05

All dates in the HTTP headers are represented as RFC 7231 Full Dates. An example is below:

Sun, 10 Sep 2017 19:43:31 GMT

All dates in the JWT claims are expressed as a JSON number, representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. 

//Sun, 12 Feb 2018 14:45:00 UTC 1518446700

Resource URI Path Structure

The path of the URI must follow the structure below (from the OB API Release Management document).

  • [participant-path-prefix]/open-banking-nz/[version]/[resource]/[resource-id]/[sub-resource]

This consists of the following elements:

  • [participant-path-prefix]
    An optional API Provider specific path prefix.

  • open-banking-nz
    The constant string "open-banking-nz".

  • [version]
    The version of the APIs expressed as /v[major-version].[minor-version]/.

  • [resource]/[resource-id]
    Details the resource.

  • [sub-resource]
    Details the sub-resource.

An API Provider must use the same [participant-path-prefix] and host name for all its NZ Banking Data API resources.

Examples:

https://superbank.com/apis/open-banking-nz/v2.0/domestic-payment-consents https://superbank.com/apis/open-banking-nz/v2.0/domestic-payments https://superbank.com/apis/open-banking-nz/v2.0/account-access-consents https://superbank.com/apis/open-banking-nz/v2.0/accounts

For brevity, the APIs are referred to by their resource names in these documents and in all examples.

Headers

Request Headers

The following headers should be inserted by the Third Party in each API call:

Header Value

Notes

POST Requests

GET Requests

DELETE Requests

Header Value

Notes

POST Requests

GET Requests

DELETE Requests

x-fapi-auth-date

The time when the Customer last logged in with the Third Party. The value is supplied as a HTTP-date as in section 7.1.1.1 of [RFC7231].

E.g., x-fapi-auth-date: Tue, 11 Sep 2012 19:43:31 GMT

May use

May use

May use

x-fapi-customer-ip-address

The Customer's IP address if the Customer is currently logged in with the Third Party.

May use

May use

May use

x-fapi-interaction-id

An RFC4122 UID used as a correlation Id.

If provided, the API Provider must "play back" this value in the x-fapi-interaction-id response header.

May use

May use

May use

Authorization

Standard HTTP Header. 

Allows credentials to be provided to the Authorisation / Resource Server depending on the type of resource being requested. For OAuth 2.0 / OIDC, this comprises of either the Basic / Bearer Authentication Schemes.

Must use

Must use

Must use

Content-Type

Standard HTTP Header.

Represents the format of the payload being provided in the request.

This must be set to application/json.

If set to any other value, the API Provider must respond with a 415 (Unsupported Media Type).

Must use

Must not use

Must not use

Accept

Standard HTTP Header.

Determines the Content-Type that is required from the server.

  • For requests to API endpoints that respond only with JSON, the Accept header must be set to value application/json.

  • For requests to API endpoints that do not respond with JSON (e.g., GET /statements/{StatementId}/file), the API Provider must specify the available options on their developer portals.

If set to an unacceptable value, the API Provider must respond with a 406 (Not Acceptable).

If not specified, the default is application/json.

May use

May use

May use

x-idempotency-key

Custom HTTP Header.

Unique request identifier to support idempotency.

Must be specified for POST requests to idempotent resource endpoints.

Must not be specified for other requests.

Must use if endpoint is an idempotent endpoint.

Must not use if endpoint is not an idempotent endpoint.

Must not use

Must not use

x-customer-user-agent

The header indicates the user-agent that the Customer is using.

The Third Party may populate this field with the user-agent indicated by the Customer.

If the Customer is using a Third Party mobile app, the Third Party must ensure that the user-agent string is different from browser based user-agent strings.

May use

May use

May use

x-merchant-ip-address

The Merchant's IP address if the Third Party is interacting with a Merchant.

May use

May use

May use

Whether the Customer is present or not-present is identified via the x-fapi-customer-ip-address header. If the Customer IP address is supplied, it is inferred that the Customer is present during the interaction.

The implications to this are:

  • API Providers will need to rely on the Third Party's assertion.

Response Headers

Header Value

Notes

Mandatory ?

Header Value

Notes

Mandatory ?

Content-Type

Standard HTTP Header.

Represents the format of the payload returned in the response.

  • For responses to API endpoints that respond only with JSON, the API Provider must return Content-Type: application/json as a content header in response to requests.

  • For responses to API endpoints that do not respond with JSON, the API Provider must return the relevant Content-Type as the content header in response to requests.

Must use

x-fapi-interaction-id

An RFC4122 UID used as a correlation Id.

The API Provider must set the response header x-fapi-interaction-id to the value received from the corresponding FAPI client request header or to a RFC4122 UUID value if the request header was not provided to track the interaction. The header must be returned for both successful and error responses.

Must use

Retry-After



Header indicating the time (in seconds) that the Third Party should wait before retrying an operation.

The API Provider determines the rate limits and retry time frames.

The API Provider should include this header along with responses with the HTTP status code of 429 (Too Many Requests).

May use

Location

Header indicating the location of the resource created by the request.

May use

HTTP Status Codes

The following are the HTTP response codes for the different HTTP methods - across all API endpoints.

An API Provider may return other standard HTTP status codes (e.g. from gateways and other edge devices) as described in RFC 7231 - Section 6.

An API Provider must respond with error response in the OAuth/OIDC flow with mandatory alignment of error codes to those specified in OpenID Connect Core Specification Section 3.1.2.6.

An API Provider must respond with the NZ Banking Data Error Response Structure for all errors during API Calls.

Situation

HTTP Status

Notes

Returned by POST

Returned by GET

Returned by DELETE

Situation

HTTP Status

Notes

Returned by POST

Returned by GET

Returned by DELETE

GET request completed successfully.

200 OK



No

Yes

No

POST request completed successfully.

201 Created

The operation results in the creation of a new resource.

Yes

No

No

DELETE request completed successfully.

204 No Content



No

No

Yes

Request has malformed, missing or non-compliant JSON body, URL parameters or header fields.

400 Bad Request

The requested operation will not be carried out.

Yes

Yes

Yes

Authorization header missing or invalid token

401 Unauthorized

The operation was refused access.

Re-authenticating the Customer may result in an appropriate token that may be used.

Yes

Yes

Yes

Token has incorrect scope or a security policy was violated.

403 Forbidden

The operation was refused access.

Re-authenticating the Customer is unlikely to remediate the situation.

Yes

Yes

Yes

The Third Party tried to access the resource with a method that is not supported.

405 Method Not Allowed



Yes

Yes

Yes

The request contained an Accept header that requested a content-type other than application/json and a character set other than UTF-8

406 Not Acceptable



Yes

Yes

Yes

The operation was refused because the payload is in a format not supported by this method on the target resource.

415 Unsupported Media Type



Yes

No

No

The operation was refused as too many requests have been made within a certain timeframe.

429 Too Many Requests

API Providers may throttle requests when they are made in excess of their fair usage policy.

API Providers must document their fair usage policies in their developer portals.

The API Provider must respond with this status if it throttles the request.

The API Provider should include a Retry-After header in the response indicating how long the Third Party must wait before retrying the operation.

Yes

Yes

Yes

Something went wrong on the API gateway or micro-service

500 Internal Server Error

The operation failed.

Yes

Yes

Yes

The Third Party tried to access a resource that has not been implemented by the API Provider

501 Not Implemented



Yes

Yes

Yes

Service version deprecation

503 Service Unavailable

Where an API is deprecated and no longer operationally supported by an API Provider, its URI path may still be active and accept API requests. In this context it is recommended that a 503 Service Unavailable be returned so that the Third Party is aware of the API version being offline.

Yes

Yes

Yes

403 (Forbidden) v/s 404 (Not Found) v/s 501 (Not Implemented)

When a Third Party tries to request a resource URL with a resource Id that does not exist, the API Provider must respond with a 403 (Forbidden) rather than a 404 (Not Found). This is so API Providers do not accidentally disclose the existence of a resource.

E.g., if a Third Party tries to GET /domestic-payments/22289 where 22289 is not a valid DomesticPaymentId, the API Provider must respond with a 403 (Forbidden).

If a Third Party tries to request a resource URL that results in no business data being returned (e.g. a request to retrieve standing order on an account that does not have standing orders), the API Provider must respond with a 200 (OK) and set the array to be empty.

If an API Provider has not implemented an optional API, the API Provider must respond with a 501 (Not Implemented) for requests to that URL.

The table below illustrates some examples of expected behaviour:

Situation

Request

Response

Situation

Request

Response

Third Party attempts to retrieve a payment with an DomesticPaymentId that does not exist

GET /domestic-payments/1001

403 (Forbidden)

Third Party attempts to retrieve a resource that is in the specification, but not implemented by the API Provider.

E.g., an API Provider has chosen not to implement the bulk direct-debit endpoint

GET /direct-debits

501 (Not Implemented)

Third Party attempts to retrieve standing orders for an AccountId that exists, but does not have any standing orders

GET /accounts/1000/standing-orders

200 (OK)

 

{ "Data": { "StandingOrder": [] }, "Links": { "Self": "https://api.alphabank.com/open-banking-nz/v2.0/accounts/1000/standing-orders/" }, "Meta": { "TotalPages": 1 } }

403 (Forbidden)

When a Third Party tries to access a resource that it does not have permission to access, the API Provider must return a 403 (Forbidden), with an optional body with Error Response.

The situation could arise when:

  • The Third Party uses an access token that does not have the appropriate scope to access the requested resource.

  • The Third Party attempted to access a resource with an Id that it does not have access to. E.g., an attempt to access GET /payments/1001 where a payment resource with Id 1001 belongs to another Third Party.

  • The Third Party tries to access an account information resource, and the Third Party does not have a consent authorisation with the right Permissions to access the requested resource. e.g., an attempt to access GET /standing-orders when the ReadStandingOrdersBasic permission was not included in the consent authorisation.

  • The Third Party tries to access an account/transaction resource and the Third Party does not have a consent authorisation for the AccountId. e.g., an attempt to access GET /accounts/2001 or GET /accounts/2001/transactions when the Customer has not selected AccountId 2001 for authorisation.

When the Third Party uses an access token that is no longer valid, the situation could potentially be remedied by asking the Customer to re-authenticate. This should be indicated by a 401 (Unauthorized) status code.

401 (Unauthorized)

When the Third Party uses an expired access token, the API Provider must return a 401 (Unauthorized) without any error response.

The situation could arise when an API Provider has chosen to expire an access token, reasons may include:

  1. The consent has expired (e.g., the expiration date time has lapsed)

  2. Suspicious usage of the access token or suspected fraud

  3. The Customer has revoked consent

This error can potentially be remedied by asking the Customer to re-authenticate or authenticate with the right permissions.

429 (Too Many Requests)

When a Third Party tries to access a resource too frequently the API Provider may return a 429 (Too Many Requests). This is a non functional requirement and is down to individual API Providers to decide throttling limits.

This situation could arise when:

  • A Third Party decides to implement "Real Time Payment Status" functionality for its users and implements this badly by polling a GET endpoint or an Idempotent POST endpoint in excess of the API Provider's fair usage policy to provide pseudo "real-time" Status updates to the user.

  • A Third Party decides to use the Single Immediate Payment endpoint as if it were a batch payment facility and sends a large number of payment requests in a very short space of time such that it exceeds the API Provider's fair usage policy. 

Pre-Conditions

The following pre-conditions must be satisfied in order to use these APIs:

Pre-conditions for Third Parties

  1. The Third Party must have completed onboarding with PNZ.

  2. The Third Party must have completed registration with each of the API Providers that it wants to transact with and have been issued with a client-id with required scopes.

  3. The Third Party must have valid network and signing certificates issued by one of the accepted Certificate Authorities.

Pre-conditions for API Providers

  1. The API Provider must have completed onboarding with PNZ.

  2. The API Provider must have valid network and signing certificates issued by one of the accepted Certificate Authorities.

Idempotency

An idempotency key is used to guard against the creation of duplicate resources when using the POST API endpoints (where indicated). 

If an idempotency key is required for an API endpoint: