FAQs

Australian Exchange Phases

Exchange phases are time periods during which different types of market activity can occur. Each market has a different sequence of exchange phases.

The following tables describe the exchange phases applicable to the Australian ITS markets. Times listed indicate the start of the exchange phase time period.

Note: Times are approximate. Please see the ASX website for more information about trading phases.​

Australian Equities - Exchange: ASX

Australian Warrants - Exchange: AXW

Australian Futures - Exchange: ASX24/SFE

Holding transaction quantities are always expressed as a positive integer

To determine the direction of movement, you’ll need to inspect the transactionCode field

Related API endpoints:

• /connect-data/equityholdingtransactions/v?

The transactionCode field may be used to identify whether the portfolio quantity has increased or decreased in response to a transaction. A list of possible codes is below, separated by direction.

Examples

• “quantity”: 1000 and “transactionCode”: “ADJ-INC”

  • This transaction increased the portfolio quantity by 1000 units.

• “quantity”: 500 and “transactionCode”: “ADJ-DEC”

  • This transaction decreased the portfolio quantity by 500 units.

Transaction codes

The /connect-data/equitycontractnotes/v1 endpoint may be queried at any time, including intra-day. However, the completeness and accuracy of the data depend on the following considerations:

Key Timing Considerations

• Intra-day adjustments:

In some cases, such as partially filled orders and rebookings, intra-day contract notes may be adjusted.

• Automated Finalisation:

The automatic finalisation of contract notes begins at 6:00pm. The runtime for this process will vary but should not exceed 10 minutes.

• Manual adjustments:

Additional manual adjustments may be applied and finalised between 6:00pm and 7:00pm. Such adjustments are most commonly related to corporate actions.

Recommendation for End-of-Day Reconciliation

To ensure complete and reliable data, we recommend querying the API no earlier than 7:15pm, ideally between 10pm-12am. This buffer allows time for all automated and manual processes to complete, minimizing the risk of missing or incorrect entries.

All times refer to the current local time in Sydney, NSW, Australia.

 Problem

Openmarkets APIs hide the complexities of connecting to multiple different systems. Occasionally though, the difference in timing between these systems will result in the data being slightly different.

This can be the case when a Stock Code is changed (which can happen for various reasons)

Sample Scenario

API Usage

• You receive trading order updates via the OMS Streaming API

• You check holdings levels via the Backoffice REST API

Market Scenario

• Friday afternoon at 3:00, the ASX Stock Code on one of your orders changes from ABC to ABCD due to a Split

• The stock code on the Streaming API reflects the new code of ABCD instead of ABC (this is almost instantaneous)

• Your system now checks the Backoffice API to get the holdings for stock ABCD and it returns an error saying that the stock code is invalid. This happens because the backoffice systems used by Openmarkets only update the stock codes once a day.

 Workaround

We’re aware that this situation is not ideal from a use case point of view. We are looking at options as to how we can handle this better. In the meantime, our recommendation is to:

1. Watch for errors where the Stock Code is invalid

2. In this case, set a delay to check for holdings again the next morning

Please note, we are aware that this is not the ideal user experience, and are working with our vendors towards a solution.

You can get lists such as the ASX 100, 200 etc and their securities by visiting the System Lists endpoint in the Market Data API.

Please see endpoint documentation for more info: Market Data API

You can also get the list of ASX listed companies on the ASX website: ASX listed companies

This is a step-by-step instruction on how to add a new client secret in the Openmarkets Developer Portal.

As we are in the process of migrating users to our new infrastructure, the ability to self-manage api client keys and secrets has been disabled. During this phase, if you require a new or rotated api client secret, please contact us at apisupport@openmarkets.com.au

Instructions

1. Go to https://dev.openmarkets.com.au/ and log in using your Openmarkets credentials.

2. Once logged in, expand the sidebar navigation menu on the left, go to the Account Management section and click on Clients.

   

3. Select the client you want to add a secret to.

   

4. Click on Add new client secret.

   

5. Provide a description for this client secret, then click the Add client secret button.

   

6. After submitting, the client secret will be displayed as seen on the image below. Make sure you save a copy of it before you leave the page.

   

7. Now you’re set up! Your client secret is ready to use.

After adding a new client secret, make sure to save a copy of the secret. If in case the copy is missing, you may also add another client secret instead.

Idempotency Key API Documentation

This guide provides information about the usage and significance of the "Idempotency-Key" attribute in the headers of some of our APIs. The "Idempotency-Key" attribute is required for certain API requests to ensure idempotent behavior and prevent unintended duplicate operations. Please read this documentation carefully to understand how and why Idempotency Keys are used.

Table of Contents

1. Introduction to Idempotency

2. Idempotency Key

3. Usage Guidelines

4. Benefits

5. Example

6. FAQs

1. What is Idempotency in APIs

Idempotency is a concept in API design where a given action can be performed multiple times, but the result remains the same as if it were only performed once. This means that making the same API request multiple times should have the same effect as making it just once. Idempotency is crucial for maintaining data consistency and avoiding unintended side effects.

2. Idempotency Key

The Idempotency-Key attribute is a unique identifier that you must include in the headers of certain API requests to ensure idempotent behavior. It is used to associate a specific request with a particular operation. When you include an Idempotency Key in your request, the server checks whether a request with the same key has been processed before. If it has, the server responds with the original response from the initial request. If not, the server processes the request and associates the Idempotency Key with the new operation.

3. Usage Guidelines

• The Idempotency-Key attribute is mandatory in the headers of API requests that support idempotency. If you omit this attribute, the request will fail (400).

• The Idempotency Key should ideally be a unique string, with UUID (Universally Unique Identifier) being a recommended choice, to guarantee uniqueness and minimize the chances of collisions.

• Ensure that you generate a new Idempotency Key for each new request. This is necessary to avoid issues with duplicate requests.

• If your request failed, you need to make a choice:

  • If you received a 400 with an error: there is no-need to auto-retry as you’ll get exactly the same response. You’ll need to fix the payload and POST again with a new idempotency-key

  • If you received a 500 or network issue, code for a retry using the same idempotency-key

4. Benefits

Using Idempotency Keys in your API requests offers several benefits:

• Preventing Duplicate Operations: By associating a unique Idempotency Key with each request, you can ensure that duplicate requests do not result in duplicate operations or unintended side effects.

• Reliable Retries: If a request fails or times out, you can retry it with the same Idempotency Key. This prevents the need to worry about whether the original request was successfully processed or not.

• Consistent State: Idempotency ensures that the system's state remains consistent regardless of how many times a request is made. This is especially important for financial transactions, inventory management, and other critical operations.

5. Example

Suppose you are making a POST request to create a new resource, such as creating an order. Here's how you would include the Idempotency-Key attribute in the request header using a GUID:

POST /sampleIdempotentAPI
Headers:
  Content-Type: application/json
  Idempotency-Key: c0670da4-e2a7-4d8e-b2f3-fd25c33f415c
Body:
{
  "sample": "Example Title",
  "quantity": 2
}

6. FAQs

Q: Can I reuse Idempotency Keys for different requests?
A: No, each Idempotency Key should be used for a single request. Generating a new key for each request ensures uniqueness and prevents conflicts.

Q: How long should I retain Idempotency Keys?
A: It's recommended to retain Idempotency Keys for a reasonable period, such as until you receive a response or until you can be reasonably sure that the request has been successfully processed.

Q: Are all API requests idempotent with the Idempotency Key?
A: No, only the API requests explicitly marked as supporting idempotency in the API documentation require the Idempotency-Key attribute for ensuring idempotent behavior.

For further assistance or inquiries, please contact our support team via the Openmarkets support system at https://openmarkets.atlassian.net/servicedesk/customer/portal/7

Idempotency Keys are required for some of our APIs to ensure data integrity and consistent behavior.

Overview:

This article provides a detailed overview of the intra-day process for activating new accounts and making them available for trading within the same day. It explains how new account submissions are processed and added to the trading platform.

1. Submission of New Accounts

• When an account submission is made via AO (Account Opening) API, it enters our system and undergoes a series of automated checks.

• If your organisation and ClientID are setup for automatic processing, submissions are generally processed automatically.

2. Processing Timeframe

• The account submission will typically take between 5-20 minutes to process, depending on factors such as data issues or validation concerns.

• In the event of any discrepancies or issues with the data, the process might be paused for manual review by the Operations team. Once resolved, the account proceeds to the next step.

• If there are no delays, the account will proceed to the next step.

3. Intra-Day Account Loading to Trading System (Openmarkets Trading System)

• Once the submission has been processed in our Backoffice system, it will be added to our Trading System.

• From the time the account is processed in the Backoffice, it will take up to 20 minutes to be added to the Trading System, depending on timing within the schedule.

4. Schedule & Availability

Once a submission is processed in the Backoffice, it is made available to be sent to the Trading System. However, it will only be added to the Trading System according to the following schedule:

• Morning load at 07:30 AEDT

• Intra-Day loads regularly between 09:30 and 14:45 AEDT

• Intra-Day loads regularly between 18:45 and 23:59 AEDT

• For submissions made outside these times, they will be picked up during the next cycle

Considerations and Exceptions

• Your organisation must be approved for and configured for automated processing and intra-day account creation

• Data and validation issues in the account submission may cause delays

• Accounts are only ready for trading once cash has been loaded. For custody accounts this will generally be instant.

• This knowledge base article has been provided as general information only and does not convey any guarantees or SLAs as to account availabilities. Please discuss with your relationship manager or the API team if you have questions around how your organisation is configured.

You can view the list and description of the various exchanges by visiting the Exchanges Information endpoint in the Market Data API.

Please see endpoint documentation for more info: Market Data API

This document explains the flow of status for an account management request

As the same set of status' apply to all types of Account Management requests, there may be some that are not relevant for a particular type of request

The status of an account management request reflects the progress of the request, and may be obtained using either:

• GET/v1/accounts/requests

• GET/v1/accounts/requests{requestId}

Status workflow

A request may flow through several statuses during its lifetime, beginning with Pending and ending with one of the Completed statuses. Once a request a request has reached a Completed status, no further changes will occur.

For example, in the case of a stock transfer request, it could progress as follows:

1. Pending - Openmarkets transfers team have received the request

2. Pending - the request is under review

3. Pending - the team have emailed the account’s advisor or admin team, for example to request a copy of ID.

4. Pending - the reply is under review

5. Pending - the request has been conveyed to the other broker

6. Pending - the other broker has responded that one of the parcels cannot be transferred. Openmarkets transfers team will inform the account’s adviser.

7. Completed - the eligible securities have been transferred

Status list

Sample response payload

{
  "results": [
    {
      "id": "5565d114-feb2-40f0-9771-6104bda02a1c",
      "requestType": "SrnStockTransfer",
      "status": "Completed",
      "subStatus": "Done",
      "accountNumber": "12345",
      "createdAtUtc": "2025-06-04T03:00:04.8433973"
    },
    {
      "id": "444819ea-f5b1-4578-b668-e8085f93dc40",
      "requestType": "HinStockTransfer",
      "status": "Completed",
      "subStatus": "Done",
      "accountNumber": "12345",
      "createdAtUtc": "2025-05-13T13:29:40.6089124"
    }
  ],
  "metadata": {
    "links": {
      "self": "/v1/accounts/requests?Limit=10&Offset=0",
      "next": "/v1/accounts/requests?Limit=10&Offset=10",
      "previous": null
    },
    "limit": 10,
    "offset": 0,
    "total": 30
  }
}

To obtain an authentication token, follow these detailed steps:

Endpoint

• URL: https://stage-identity.openmarkets.com.au/connect/token

• Method: POST

• Auth Type: Basic Auth

Authorization

• Username: Your clientID

• Password: Your clientSecret

Request Body

The request body must be in x-www-form-urlencoded format and include the following parameters:

• grant_type: client_credentials

• scope: The desired API scope (e.g., accounts-submissions)

Request Example

Here's an example of how to structure the request:

Request Headers

Authorization: Basic base64(clientID:clientSecret)
Content-Type: application/x-www-form-urlencoded

Request Body

grant_type=client_credentials&scope=your_api_scope

Example Request Using cURL

curl -X POST https://stage-identity.openmarkets.com.au/connect/token \
  -H "Authorization: Basic <base64_encoded_clientID:clientSecret>" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&scope=your_api_scope"

Replace <base64_encoded_clientID:clientSecret> with the Base64 encoded string of your clientID and clientSecret.

Using Postman

1. Open Postman: Download and install Postman if you haven’t already.

2. Create a New Request:

   • Click on the New button.

   • Select Request.

   • Name your request (e.g., "Get Auth Token") and select or create a collection to save it.

3. Configure the Request:

   • URL: https://stage-identity.openmarkets.com.au/connect/token

   • Method: POST

   • Authorization:

     • Go to the Authorization tab.

     • Select Basic Auth from the Type dropdown.

     • Enter your clientID as the Username.

     • Enter your clientSecret as the Password.

   • Headers:

     • Go to the Headers tab.

     • Ensure the Content-Type header is set to application/x-www-form-urlencoded. If not, add it manually.

   • Body:

     • Go to the Body tab.

     • Select the x-www-form-urlencoded option.

     • Add the following key-value pairs:

       • Key: grant_type, Value: client_credentials

       • Key: scope, Value: your_api_scope (replace your_api_scope with the actual scope you need)

4. Send the Request: Click the Send button.

5. View the Response: In the Body tab of the response section, you will see the JSON response containing your access_token.

Response

If the request is successful, you will receive a response containing the bearer token. Here's an example of the response:

{
  "access_token": "your_bearer_token",
  "expires_in": 3600,
  "token_type": "Bearer"
}

Usage

Use the access_token received in the response for authenticating your API calls. Include it in the Authorization header as a Bearer token.

Example API Call Using the Token

curl -X GET https://your-api-endpoint \
  -H "Authorization: Bearer your_bearer_token"

Summary

1. Send a POST request to https://stage-identity.openmarkets.com.au/connect/token.

2. Use Basic Auth with your clientID as the username and clientSecret as the password.

3. Include grant_type=client_credentials and scope=your_api_scope in the request body (in x-www-form-urlencoded format).

4. Obtain the access_token from the response.

5. Use the access_token as a Bearer token in your API calls.

This process will authenticate your requests and allow you to interact with the desired API scope securely.

Trading sessions are generic session states combining security trade statuses and exchange phases.

• The N/A trade session is used for miscellaneous security statuses. For securities with these statuses, any limits for the current exchange phase are applied.

When applying for a trading account on behalf of a trust, it is necessary to specify the trust type. Please review the below documentation to ensure these types are accurately represented.

• What is a trust?
• Identifying the trust type
• Supported trust types
  • SelfManagedSuperannuationFund
  • OtherRegulatedTrust
  • BareTrust
  • DiscretionaryTrust
  • FixedTrust
  • UnitTrust
  • OtherTrustType

What is a trust?

A trust is an entity which has trustees, assets, and beneficiaries. The trust is the legal vehicle which allows a trustee to hold assets on behalf of the beneficiaries.

Identifying the trust type

If an ABN has been registered for the trust, the trust type may be identifiable at ABN Lookup. The Australian Business Register also maintains a list of Entity Types, and a bulk extract of ABNs which includes the entity type of each entry.

Without an ABN, the type can be identified within the trust deed or equivalent governing document.

Supported trust types

The account opening API records the following trust types under data.trust.trustType. Please note that:

• The entity types listed are a representative sample rather than a comprehensive list.

• Some types may require a comprehensive document review by Openmarkets, prior to submitting an application.

• Please contact your Relationship Manager to discuss which types are supported under your agreement with Openmarkets.

SelfManagedSuperannuationFund

• Definition: A private super fund that is managed by its own members, for the sole purpose of providing retirement benefits to the members.

• Regulated: Yes. The regulator for SMSFs is the Australian Taxation Office.

• Entity types include: SMSF.

OtherRegulatedTrust

• Definition: Any trust, other than a self-managed superannuation fund, which is subject to oversight from an Australian statutory regulator.

• Regulated: Yes.

• Entity types include: Government superannuation fund, APRA-regulated superannuation fund, pooled superannuation fund, registered or unregistered managed investment scheme, approved deposit fund.

BareTrust

• Definition: A simple trust where the trustee's duties end at holding the assets, then conveying those assets to the beneficiary when instructed.

• Regulated: No.

• Entity types include: Bare trust, nominee trust, custodian trust, debt installment trust, passive trust, asset acquisition trust.

DiscretionaryTrust

• Definition: Any trust in which the trustee/s have discretion over how to distribute the trust's income.

• Regulated: No.

• Entity types include: Family trust, discretionary trading trust, discretionary investment trust.

FixedTrust

• Definition: A trust where the beneficiaries' entitlements to income and capital from the trust are fixed, rather than variable.

• Regulated: No.

• Entity types include: Fixed trust, government fixed trust.

UnitTrust

• Definition: Any trust where the trust assets are portioned into shares (units) and a specific number of shares is issued to each beneficiary (unit holder.)

• Regulated: No.

• Entity types include: Corporate unit trust, public unit trust.

OtherTrustType

• Definition: Any unregulated trust which does not fall under the above categories.

• Regulated: No.

• Entity types include: Testamentary trusts, executorial trusts, charitable trusts.

You can get the list of all available destinations, lifetimes and pricing instructions combinations by calling to the destination's endpoint in the OMS API.

Please see endpoint documentation for more info: OMS API Destinations

Code Description:

• CL - Call Due

• CP - Call Paid

• CT - Conditional Trading

• CB - Cum Bonus Issue

• XB - Ex Bonus Issue

• CC - Cum Capital Return

• XC - Ex Capital Return

• CD - Cum Dividend

• XD - Ex Dividend

• CE - Cum Entitlement

• XE - Ex Entitlement

• CQ - Cum Equal Access Scheme

• XQ - Ex Equal Access Scheme

• CI - Cum Interest

• XI - Ex Interest

• CZ - Cum Priority

• XZ - Ex Priority

• CR - Cum Rights Issue

• XR - Ex Rights Issue

• CF - Cum Takeover Offer

• XF - Ex Takeover Offer

• NX - New - Ex Interest

• PA - Protection Available

• PU - Protection Unavailable

• RE - Reconstructed

Reporting code is either Blank when not reporting or 'R' when reporting.

The Client Management API is used to create new trading accounts. Once the account creation is complete, an account code will be associated with it which can then be used to create orders in the OMS API.

Openmarkets APIs have rate limits in place to ensure reliability and protect from improper usage

What is rate limiting in the context of APIs?

Rate limiting is a mechanism implemented to control the number of requests a user or client can make to an API within a specified time period. It helps prevent abuse, ensures fair usage, and maintains the overall performance and availability of the API.

Why is rate limiting important?

Rate limiting is crucial for several reasons. It prevents excessive usage that could lead to server overload. It also safeguards against potential security threats and ensures a consistent and reliable experience for all users.

What are the rate limits applied to Openmarkets APIs?

This depends on the individual API.

We’ve listed the general guidelines below. Some endpoints will have more specific rate limits per endpoint. You’ll find these in the developer docs.

Authentication API

• 50 requests for tokens per 5 minutes

Order Management APIs (REST)

• 50 active requests at a time - A request is active between the time we receive it and the time we send a response or while an update subscription is active.

• 30 calls - of any kind per second.

• 10000 updates queued - between update subscription calls. If encountered, it is recommended to either increase the frequency of subscription calls or split the request in multiple ones.

• Test Environment Only 30000 requests per day - for Market Data API.

• Test Environment Only 10000 requests per day - for News API.

Backoffice APIs (REST)

• 1 request per minute

• Openmarkets recommend one call per 5 minutes

• We recommend limiting your query by your adviser code and today's date for the API endpoints that support it

Account Opening API

• Create Account Opening Submissions: 2 requests per second.

  • This limit is in place due to the encryption of content to ensure the security and performance of the API.

• Get Account Opening Submissions: 100 requests per second.

• Get Accounts: 5 requests per second.

• Stock Transfers: 5 requests per second.

Dividend discrepancies for foreign dividends can arise due to various reasons:

• Currency Conversion: Different methods of converting foreign currency into the local currency can lead to discrepancies in reported dividend amounts. Investors can verify currency conversion rates from reliable sources like the Australian Securities Exchange (ASX).

• Taxes: Withholding taxes imposed by the company's country or tax treaties between countries can affect the final dividend amount received by investors.

• Reporting Differences: Variations in reporting practices between companies and data providers may result in differences in the reported dividend amounts.