When sending a payment, creating a local withdrawal or ordering a conversion you can provide us a webhook (callback) URI - callbackUri. We will call it when a payment or withdrawal status changes.

We recommend API clients to generate and add ?signature=ASecretPerPaymentKey query to your callbackUri to make sure it's Flash Payments calling your webhook endpoint. For example:

https://my-webhooks.example.com/flash-payments?signature=oZaDlmfXbdXSKCnuWrvos2ImVBFX2Ru5

To avoid storing the signatures in a database we recommend generating them on the fly using a strong hash function or any kind of cryptography.

Example

You would need to implement two functions.

1. Function to generate "signature".

2. Function to verify the "signature".

Node.js pseudo code to generate a signature in your integration code.

The code above creates a callbackUri and externalId variables. Use both of them when creating a transfer in Flash Payments API.

Node.js pseudo code of your webhook HTTP request handler.

General information

Flash Payments API is GraphQL-based, offering simple and developer-friendly querying experience. All data is exchanged in JSON format.

Flash Payments API playground is located here: https://api.uat.flash-payments.com.au/

Complete API docs

This documentation website does not have full list of API fields and methods. This is intentional. The full list of the API calls you can performs and the data fields you can send/receive is listed in the API Playground (click "DOCS" on the right hand side).

High level feature overview

You can search, visualise, or extract your data using our FlashConnect interface.

Instant local Australian deposit (aka pay-in)

Once registration is complete, a dedicated BSB and Virtual Account Number (VAN) for use within Australia will be assigned to you.

Any funds deposited to your VAN would increase your Flash Payments balance. We store and retain the reference attached to each deposit (e.g., an invoice number) to support your reconciliation or reporting needs.

By default, only you can deposit into your VAN. Third-party deposits are also supported, but this feature must be enabled separately

Deposits are typically processed in real time, but depending on the bank, there may be a delay of up to 24 hours.

You can configure webhook notifications to receive alerts for every deposit made to your VAN. Please visit to set up your deposit webhook.

You can manually reject unwanted deposits via the interface. The funds will be returned to the original sender bank account.

The Flash Payments API enables you to withdraw funds from your Flash Payments balance. By default, only you are authorized to receive these withdrawals. Third-party withdrawals (also known as payouts) are available upon request and require separate activation.

If your payout involves a foreign exchange (FX) payment, it must be processed using the Australian Direct Entry system in accordance with legal requirements. Processing time may vary from immediate to a few hours. Other payouts are credited instantly.

If a payout fails, you will receive a webhook notification detailing the reason for the failure.

The payout remitter name is configurable. You can give us the remitter name as withdrawal.sender data property. This is especially useful for FX-linked payouts. If a Brazilian mama Katarina Oreiro sends money to her son in Australia, he will see his mom's name in the bank statement - "Payment from Katarina Oreiro".

Payouts can also be done via the interface.

You can send your Flash Payments balance internationally via our API and benefit from instant delivery to many countries with local instant payment systems (e.g. Philippines)

To initiate a payment, you must pre-create the sender and recipient via the API.

All entities in our database, including withdrawals, payments, senders, and recipients, can store your system’s unique identifier. Please refer to the externalId field in the .

Payment delivery times depend on the recipient's country. While many are processed quickly, some may take additional time. You’ll be notified via webhook whenever the payment status changes.

You can send funds through an international payment to your Flash Payments account. A webhook notification will be triggered when we detect payments from other countries.

The API token you generate expires in 4 hours. You can always use logout GraphQL mutation to expire it earlier.

You can't reset your own password until we verify your identity.

The interface supports Google and One-Time-Password logins.

Webhooks have cryptographic signatures.

IP address whitelisting feature is available from FlashConnect interface allowing login to our APIs from only preapproved addresses that you specify.

API rate limiting is in place to ensure stable performance of our service and prevent its potential abuse.

1. Contact with us via or by clicking the Intercom button on the bottom right of this page.

2. Explain what kind of services you are looking from Flash Payments.

3. We will examine your needs and explain how to get access to our UAT environment.

For more detailed instructions head to the page.

While we will endeavour to not introduce any breaking changes they might still occur in the future. In that case we will communicate about the upcoming changes via your registered email.

A sub-client lifecycle follows these stages.

A sub-client is created and has the temporary INITIATED status. At this stage, the request has been received and the system is currently processing it.

If processing is completed successfully, the sub-client automatically transitions to the ACTIVE. In this status, the sub-client is fully activated and approved.

If the sub-client requires manual compliance review, the sub-client moves from INITIATED to the temporary UNAPPROVED status. From this status it would eventually transition to either ACTIVE or FAILED_KYC. Typically, we can't disclose the exact reason of the KYC failure, while it mostly happens because we do not have risk appetite for your client.

You can deactivate the client (via API of Flash Connect), - it'd move from ACTIVE to DEACTIVATED. A sub-client in the DEACTIVATED status can be activated by you at any time, returning to ACTIVE.

At any point, a sub-client may be moved to DISABLED. In this status, the sub-client is disabled and cannot be enabled by you, and contacting support is required for further information.

You can create payouts via the createWithdrawal mutation.

You can retrieve your payouts via the withdrawals query.

Sometimes you'd need to understand the supported delivery methods using the availableDeliveryMethods query.

If you get instructed by another financial institution then you must submit their details too.

If the payouts didn't pass compliance we would reject it with a proper rejection code and descriptive message.

If you use our multi-currency feature, you can exchange currency and convert funds between your master accounts in real-time.

Conversion fees are detailed in your contract and vary based on your use case and risk assessment.

The GraphQL schema defines statuses like this:

enum ConversionStatus {
    INITIALISED
    PENDING
    CONVERTED
    FAILED
    CANCELLED
}

The status of a conversion can be any of the following:

• INITIALISED — A conversion record was created, but no further action has been taken. This status typically does not occur via the API.

• PENDING — The conversion is in progress. This is the usual status immediately after creation.

• CONVERTED — The conversion completed successfully. Your balances have been updated accordingly.

• FAILED — An error occurred during the conversion. This is usually a temporary state.

• CANCELLED — The conversion was not completed and has been cancelled. This action is typically performed by the Flash Payments operations team.

GraphQL Playground

All the GraphQL queries can be sent via the GraphQL Playground or as a HTTP POST request to https://api.uat.flash-payments.com.au. Example:

echo '{
  "query":
    "{
       quote(input: {
         fromCurrency: AUD, toCurrency: USD, size: 9.9, currency: AUD
       })
       {
         bid ask symbol timestamp inverted
       }
     }"
}' | curl -X POST 'https://api.uat.flash-payments.com.au' \
-H 'authorization: Bearer YOUR_TOKEN' \
-H 'content-type: application/json' \
-d @-

All the responses are JSON and have at least one property data and optional property errors.

{
  "data": { ... },
  "errors": [ ... ]
}

Some of the GraphQL query parameters are required, others are optional. To understand if a variable/property is required you would need to check the API schema.

• Go to the and click the button "DOCS" on the right.

• Browse through queries, mutations, input and output types. Find a variable/property which have an exclamation mark at the end. E.g. fromCurrency: FromCurrency!.

• The exclamation mark denotes that the variable/property is mandatory.

It is a good idea to always send custom user-agent HTTP header value when doing requests to Flash Payments API. Here is why:

• In case of troubleshooting we will be able to trace and mitigate your support questions faster.

• You might be blocked by our automated firewall if your user agent is something generic like curl, Java-http-client, python-requests, Ruby, etc.

Our API have smart monitoring and it may temporarily block your IP if it detects system misuse. For more information, please refer to the page.

Most documentation examples utilise typical GraphQL input data for successfully executing queries.

It's strongly encouraged that you always submit complete and accurate data, as this reduces our compliance team's reviewing efforts and, as a result, speeds up transactions and provides a great experience for your customers.

At the same time, we recognise that gathering complete customer information can be technically challenging, particularly regarding country-specific address details or account information. As a result, our API documentation emphasises the required input fields based on the principle of minimal necessity.

Please pay attention to the exclamation mark ( ! ) next to the field type in the API schema specification from the "Docs" section of our API Playground. Those are the required fields as it's demonstated on the screenshot below:

Please always verify that you have all required data to initiate a successful mutation or query.

Upon detecting a deposit in a Flash Payments Virtual Account Number (VAN), we immediately record it as a deposit in our system.

The status of a successful deposit goes through the following lifecycle

INITIALISED->REVIEWING→CONFIRMED

If you choose to reject a deposit, its status goes through the following lifecycle instead:

INITIALISED->REVIEWING→CONFIRMED→REFUNDING→REFUNDED

If Flash Payments Compliance choose to reject a deposit, its status lifecycle goes through following stages:

INITIALISED→REVIEWING→REFUNDING→REFUNDED

What we call "FX Payment" is a fully orchestrated account to account delivery of any currency(-ies) we support. Typical examples:

• You need to send from the EU to Australia. You would have a European virtual IBAN on your name. As soon as you deposit some EUR to it - you'll see a corresponding amount of AUD on your master balance in a matter of minutes, which you'll be able to use immediately.

• You need to fund someone's overseas IBAN in Euros. You send us the AUD and give us the recipient's details either via API or via you FlashConnect back-office GUI. We orchestrate the rest.

You can create payments. using the createPayment mutation.

You can your payments with the payments query.

But before you need to understand the supported delivery methods using the query.

Adverse Media Search (AMS) lets you screen an individual or organisation against web-based adverse media sources — news articles, court records, and other publicly available content.

You can run a search via the adverseMediaSearch mutation or past searches via the amsRequest and amsRequests queries. Scans run in the background and can take several minutes. Use webhooks or poll the amsRequest query to track progress. See AMS statuses for the full lifecycle.

Paste this query to the GraphQL Playground

The cleared is the Primary balance you see on the Flash Connect website.

The pending balance is typically not shown on the Flash Connect interface because it's rather short lived. If your Pending

The sub-client (aka merchant) feature allows you to create client accounts for deposit collection purposes. These virtual accounts can be issued to individuals, companies, or other organisations.

Each sub-client will receive a dedicated BSB and Vitrual Account Number (VAN) that you or your clients can use to accept and withdraw domestic AUD transfers within Australia.

The account name is your sub-client's name. For companies - it's their tradingAsName or legalName. For individuals - it's their fullName (firstName + middleName

If your withdrawal is canceled (aka rejected) by our AML and Compliance team, you'll receive the webhook containing both a rejection code (rejectCode) and a manually written rejection reason (statusMessage). You can find the same two properties within the GraphQL type.

Here is a current list of all possible rejectCodes, but please note this list can be extended with time.

Please also note that while the rejection codes are set, the corresponding free text statusMessage will have a case-by-case human written text explaining the root cause of the cancellation. We'll try to be as descriprive as possible taking into account the legal bounds (we are not allowed by the law to disclose certain information).

After fully registering with us, you get a BSB and a dedicated Virtual Account Number (VAN).

Every deposit to your VAN would increase your Flash Payments balance.

Every deposit can trigger a notification, keeping you informed in real time

The deposit data includes the payment reference (we call it externalReference in this API).

By default, only you are permitted to make deposits. However, we can enable third-party deposits for your account upon request. Once enabled, your account number functions as a local collection account, allowing others to deposit funds on your behalf.

We can also enable the

The GraphQL schema defines statuses like this:

The status of a payment can be any of the following:

Payment Statuses:

• INITIALISING – a draft payment. It may or may not have all required information to be executed. Typically, this never happens through the API. Can be created via the under certain circumstances.

• OPEN – The payment is in progress.

Here is the list of all possible CoP response codes.

1. - query bank information to validate if we support your BSB, IBAN, BIC (aka Swift code).

2. depositDetails - query the accounts you can send deposits to in order to increase your Flash Payments master balance.

This query returns the same data as the Download CSV button on the Account Statement page of the Flash Connect.

The dates must be any ISO 8601 formatted dates.

const bodyJSON = {
  variables

query($input: StatementQueryInput!) {

{
  "input": {
    "fromDate": "2023-08-28T00:00:00+03:00",
    "currency": "USD"
  }
}

{
  "data": {
    "statement": [
      {
        "success": true,
        "code": "GENERATED",
        "message": "Statement generated",
        "fromDate": "2023-08-27T21:00:00Z",
        "toDate": "2023-08-28T21:00:00Z",
        "rows": {
          [
            {
              "debit": 123.45,
              "credit": 0
            }
          ]
        }
      }
    ]
  }
}

The response dates are aways UTC. Timezones are always taken into account.

1. You create a withdrawal. Your balance goes down by the withdrawal amount plus fee. INITIALISED

   1. We might internally review the transaction. INITIALISED-> REVIEWING

   2. If review goes well it will become pending. REVIEWING→ PENDING

   3. Otherwise it gets cancelled. REVIEWING→ CANCELLED

2. The transaction is sent to the recipient bank for processing. INITIALISED → PENDING

3. PENDING →

   • CONFIRMED - the recipient bank has the money now. Does not mean the beneficiary account number was credited though. Mostly FINAL status. Except when bank decides to return the funds, the withdrawal gets refunded (see step 4).

4. The recipient bank decided to return this transaction back to Flash Payments.CONFIRMED → FAILED → REFUNDED - usual way - automatic refunding. Your balance goes up by the withdrawal amount, Flash Payments keeps the fee. FINAL status.

The payout passed our automated compliance checks and was processed successfully:

INITIALISED→PENDING→CONFIRMED

The payout was successfully processed after a manual compliance review:

INITIALISED→REVIEWING→PENDING→CONFIRMED

Recipient bank accepts the payout but then returns it:

INITIALISED→PENDING→CONFIRMED→FAILED→REFUNDED

Recipient bank rejects the payout:

INITIALISED→PENDING→FAILED→REFUNDED

Flash Payments Compliance team rejects the payout:

INITIALISED→REVIEWING→CANCELLED

To trigger a happy or unhappy path scenario, put the corresponding keyword in the externalReference field when you submit a withdrawal. The keyword instructs our system to automatically simulate that outcome instead of routing the withdrawal through the standard compliance and payout pipelines, which may require manual intervention by a compliance analyst. Typically, you want to adapt your system to handle the following common withdrawal scenarios:

1. Too long in the REVIEWING status

If your withdrawal is in this status this means that we are doing an internal review of it. It happens occasionally when you trigger our monitoring rules. Also, this means that we have sent your Compliance Team (or else) an email message requesting more information. You must respond. In other words, if there is a delay - it's on you. Because Flash Payments delivers all your transactions in real-time 24/7.

You can simulate the behaviour. Your externalReference must include this text: HALT_AML. For example: "testing HALT_AML attempt 2". The withdrawal will get stuck in REVIEWING forever.

We checked the data you sent us for withdrawal. We didn't like it. So we cancel it immediately.

You can simulate the behaviour. Your externalReference must include this text: FAIL_AML. For example: "testing FAIL_AML attempt 4". The withdrawal will be cancelled next moment after you submit it.

If our smart AML/TM checks stop your withdrawal for manual review, you can have it automatically pushed forward by including PUSH_AML in the externalReference. For example: "testing PUSH_AML attempt 5". This enables the transaction to continue as if it were approved by the compliance analyst. It can be particularly useful during your integration testing activities and also help with UAT regression testing later.

Please note that the REVIEWING status for this payout will be recorded on our end, and a withdrawal_reviewing webhook will be sent.

Whenever our Compliance team needs more details about specific withdrawal, you’ll receive an email with a link to the RFI form. The withdrawal will sit in REVIEWING until you respond to the RFI via the link in the email and a compliance analyst marks it satisfactory.

You can simulate the behaviour by including SEND_RFI text into the externalReference For example: "testing SEND_RFI attempt 3". The withdrawal remains in REVIEWING until you respond to the RFI. At that point, we will review your submission and provide feedback, and then manually push the transaction forward. The primary goal of this test is to familiarize your team with our RFI process and address any questions beforehand, ensuring a smooth transition to production.

A common scenario in the Australian domestic payment system involves a transaction that appears successful initially, but is later reversed by the recipient’s bank—sometimes days after processing. This can happen for various reasons, such as an invalid or closed account number, an account in the wrong currency, or other account-related issues.

You can simulate the behaviour. Your externalReference must include this text: FAIL_ACC. For example: "testing FAIL_ACC attempt 8". The withdrawal will be completed, and next moment failed and refunded.

Most common RFI status transitions follow one of these paths.

Happy path

PENDING → ASSESSING → CLOSED

1. It starts when our compliance review flags one of your transactions. An RFI is created with a list of questions and a response deadline. Status PENDING means the RFI is open for your response. Answer each question via before deadline. The status stays PENDING until all answers are received or the deadline passes.

2. The last open question is answered. Status ASSESSING means that all your answers have been received and are under our review. No action is required from you.

3. The review is completed. Status CLOSED means that the RFI is finalised. No further answers are accepted. Final status.

Declined or expired path

PENDING → CLOSED

An RFI can also move to CLOSED directly from PENDING when you , or when the deadline passes without a complete response from your end.

Cancelled path

PENDING → CANCELLED or ASSESSING → CANCELLED

Separately from your responses, our compliance team can withdraw an RFI when the information is no longer needed — for example the underlying transaction question was resolved another way. The RFI moves to CANCELLED, no further answers are accepted, and any linked deposits, withdrawals, or payments are left untouched and continue on their own lifecycle. You don't need to do anything — we notify you by email and via the rfi_cancelled webhook. Final status.

Each transition emits a :

Status message

The statusMessage field carries a meaningful explanation of the current status, for example "We are waiting for your replies" while PENDING, or "We assessed the information you provided" once CLOSED. The exact wording varies with the circumstances — treat it as display text, not as a value to parse.

Confirmation of Payee (CoP) is a security feature that verifies whether an account holder's name matches the account details you provide. It helps to:

• Reduce fraud by verifying the account holder's name before sending funds

• Prevent accidental payments to wrong accounts due to mistyped details

• Provide confidence that money is being sent to the intended recipient

• Alert you when the account name doesn't match or only partially matches

To verify account details, execute the confirmationOfPayee mutation. You must provide the accountIdType, the relevant account details, and the accountName you wish to verify.

The code field in the response indicates the .

The billable field indicates whether the CoP request may be subject to a fee.

Limits

This API apply various rate limits depending on the type of HTTP request or GraphQL query being executed, as well as the number of such requests. The rate-limiting mechanism is quite dynamic and is based on the IP address(es), error rates, HTTP headers, and the GraphQL queries.

We do not disclose the exact limits due to their complexity and our security policy. However, it's nearly impossible to reach the limits if your requests are properly formed.

When one of the numerous limits exceeds the API typically responds with

1. the HTTP status 429

2. the HTTP header:

3. and a JSON body:

Here are the common situations when you might get yourself temporarily blocked:

• When your requests produce numerous errors, e.g. malformed header, JSON body, or a GraphQL query.

• When you send too many requests without a valid Authorization header.

• When you send too many requests within a very short period.

Please contact our support team via the established communication channels. We will manually reset the counters for you.

For your initial tests, it may be easier and more practical to send data by embedding values directly into the GraphQL queries and mutations, as shown in the example below.

At the same time, to enable efficient and accurate handling of complex queries in code, we support sending GraphQL queries as JSON objects that consist of two properties: "query" and "variables". Here is how you can do it:

• Declare the $input variable in the QraphQL "query"

A Request for Information (RFI) is a compliance request raised by Flash Payments against deposits, withdrawals, or payments that require additional information before they can be released. RFIs are created on our side when a compliance review flags certain transactions — you cannot create RFIs via the API.

Each RFI carries a list of questions and a response deadline. There are two ways to respond:

• Via the API (this section) — receive a webhook, , n with text or documents, or if you cannot comply.

There are two places an RFI call can report a problem: the code field on the mutation reply payload, and the top-level GraphQL errors array.

Returned in the code field of AnswerRfiQuestionReply / DeclineRfiReply:

Address Cleanser is a data-standardisation and geocoding utility designed to ensure physical addresses exist and are correctly formatted. It standardises a supplied address against multiple geocoding providers and returns a suggested recommendation together with a score.

It helps you:

• Validate and standardise addresses before processing payments

• Reduce failed deliveries due to incorrect or unrecognised addresses

Use the declineRfi mutation when you are unable to provide the requested information — the API equivalent of "Unable to comply" on the secure form.

Declining:

• marks the RFI as CLOSED — an webhook is dispatched;

Event notifications with webhooks

Flash Payments uses webhooks to notify your application when a transaction event happens in your account. This includes status update of your withdrawal, clearing of the incoming deposit, and more.

With webhooks, you can subscribe to the events of interest to trigger a subsequent action within your integration.

There are two steps to begin using webhooks. Building a custom endpoint on your server and registering it via the FlashConnect settings.

Building webhook endpoint

Each time a transaction event happens, we will send a HTTP POST request to your endpoint(s) that are subscribed to that event. The payload with event data is in the JSON format and can be used immediately. Every webhook endpoint must acknowledge the request, and as we strongly advise, verify the webhook signature.

Acknowledging request

To acknowledge the receipt of the event, your endpoint must return 2xx HTTP status code. All other response codes, including 3xx codes, indicate that you did not receive the event.

If we do not receive 200 HTTP status code, we will make up to 3 more request attempts. There is 6, 60 and 600 seconds delay between each delivery attempt respectively. If all request attempts fail, we mark webhook request as failed and will no longer try to deliver it.

Each webhook request has a flashfx-request-id header with a string that uniquely identifies a webhook event. For example, if there are multiple delivery attempts for the webhook event, each request will hold the same flashfx-request-id. This can be used to check if the webhook event was already processed by your application.

We advise that you acknowledge webhook request as early as possible.

Securing the request

To ensure that webhook was sent by Flash Payments and not a third party, we include the cryptographic signature in each request’s flashfx-signature header.

Before you can verify a signature, you need to retrieve your endpoint’s secret from webhook settings in the . Each registered endpoint has a unique secret that is used to sign a payload delivered to you on each event. Steps to verify signature:

1. Extract signature from the request header

2. Compute HMAC with SHA256 function. Use your endpoint secret as key and JSON payload string as a message.

3. Compare signature in the header to the computed signature.

Here is a Node.js pseudo code to generate and compare signatures

And verifying signature

Testing your endpoint

To make sure your webhook endpoint is setup correctly, you can make a test HTTP request from the webhook settings. Click the "Send Test” button. You should receive a dummy request, which will need to be acknowledged the same way as your real webhook requests.

Then go to the history of the webhook requests and find the test request and response there.

Webhook requests come with event data. You can see all available event types in the settings. To subscribe, select which events you would like to receive and specify your endpoint. Please note, your endpoint must adhere to the HTTPS protocol for security reasons.

Query all deposits

const bodyJSON = {
  variables

query($input: DepositQueryInput!) {

{ 
  "input": {
  }
}

{
  "data": {
    "deposits": [
      {
        "id": "6053d4e0e3bc655e0598a742",
        "amount": 2000,
        "currency": "AUD",
        "status": "CONFIRMED",
        "statusMessage": "Transaction Confirmed",
        "externalId": "PR.1vcl",
        "externalReference": "FX1111",
        "subClient": null,
        "createdAt": "2021-03-18T22:32:01.010Z"
      },
      {
        "id": "6053d3319588389e1443587e",
        "amount": 40,
        "currency": "AUD",
        "status": "CONFIRMED",
        "statusMessage": "Transaction Confirmed",
        "externalId": "PR.1vci",
        "externalReference": "FX2121",
        "subClient": {
          "id": "5fb314cb9224595df522db61",
          "fullName": "John Doe",
          "status": "ACTIVE",
          "clientType": "INDIVIDUAL"
        },
        "createdAt": "2021-03-18T22:24:49.096Z"
      },
    ]
  }
}

Query deposit by ID

const bodyJSON = {
  variables

query($input: ID) {
  

{
  # there are more query parameters available, see the API schema
  "input": "6053d4e0e3bc655e0598a742"
}

{
  "data": {
    "deposit": {
      "id": "6053d4e0e3bc655e0598a742",
      "amount": 2000,
      "currency": "AUD",
      "status": "CONFIRMED",
      "statusMessage": "Transaction Confirmed",
      "externalId": "PR.1vcl",
      "externalReference": "KX23249",
      "createdAt": "2021-03-18T22:32:01.010Z"
    }
  }
}

Please verify that you have all the required data to initiate a successful payment transfer.

List all the available payment delivery methods

const bodyJSON = {
  variables

query($input: AvailableDeliveryMethodsInput!) {

{ 
  "input": {

{
  "data": {
    "availableDeliveryMethods": [
      {
        "country": "AE",
        "currency": "AED",
        "method": "ACC_NO",
        "requiredFields": [
          "bic",
          "accountNo"
        ]
      },
      {
        "country": "AT",
        "currency": "EUR",
        "method": "IBAN",
        "requiredFields": [
          "bic",
          "iban"
        ]
      },
...

The response above means that if you want to send euros to Austria (AT) then you'd need a BIC (aka SWIFT) code and an IBAN.

List some of the delivery methods

const bodyJSON = {
  variables: 

query($input: AvailableDeliveryMethodsInput!) {

{
  "input": {
    "country": "FR", 
    "currency": "EUR" 
  }
}

The response above means that to send euros to France (FR) you have to have ether of:

• BIC and an account number, or

• BIC and an IBAN.

Instructing Institution

Institution entity is a piece of information about the party who instructed you to make the withdrawal. This data is important for compliance within Australia. This is not the sender. If there is no other institution who has instructed this withdrawal, leave this blank and your own details will be used for compliance and auditing purposes.

Creating institutions

• via Flash Connect (you can copy an ID of an existing Institution).

• via API by invoking createInstitution mutation.

• by providing instructingInstitution object into createWithdrawal mutation.

To convert between, say, AUD and EUR you should:

1. Request a tradeable quote with applicability: CONVERSION.

2. Retrieve the quote ID from the response.

3. Reference the quote ID when creating the conversion.

Get a tradable quote ID:

Convert funds:

Retrieving all your conversions

const bodyJSON = {
  variables

 query($input: ConversionQueryInput!) {

 {
  "input": { 
  }
}

{
  "data": {
    "conversions": [
      {
        "id": "6b04c62ec0bf606bf216ae21",
        "fromCurrency": "AUD",
        "toCurrency": "EUR",
        "rate": 0.71
      },
      {
        "id": "6b04c6bfc0bf606bf216af06",
        "fromCurrency": "AUD",
        "toCurrency": "USD",
        "rate": 0.70
      },
      {
        "id": "6b04c8e3c0bf606bf216b026",
        "fromCurrency": "EUR",
        "toCurrency": "AUD",
        "rate": 0.71
      }
    ]
  }
}

Retrieving some of your conversions

const bodyJSON = {
  variables

query($input: ConversionQueryInput!) {

{
  "input": { 
    "statuses": "CONVERTED",
    "toCurrencies": ["EUR","USD"]
  }
}

{
  "data": {
    "conversions": [
      {
        "id": "6833ad9b4e94acce5d4a031b",
        "fromCurrency": "AUD",
        "toCurrency": "USD"
      },
      {
        "id": "678a18bb2879c374b378ee71",
        "fromCurrency": "AUD",
        "toCurrency": "EUR"
      }
    ]
  }
}

Retrieving a single conversion by ID

const bodyJSON = {
  variables: {
    input: "6b04c62ec0bf606bf216ae21",
  },
  query: `
query ($input: ID) {  
  conversion(id: $input) {
    status createdAt fromAmount toAmount 
  }
}`,
};

query($input: ID) {
  conversion(id: $input) {
    status
    createdAt
    fromAmount
    toAmount
    # there are many other properties
  }
}

{
  "input": "6b04c62ec0bf606bf216ae21"
}

{
  "data": {
    "conversion": {
      "status": "CONVERTED",
      "createdAt": "2024-08-13T05:45:28.698Z",
      "fromAmount": 1000,
      "toAmount": 710.01
    }
  }
}

1. You submit a search. The request is created and queued. INITIALISED

2. The background scan starts — web sources are fetched and analysed. INITIALISED → PENDING

3. PENDING →

   • COMPLETED — the scan finished successfully. Results are available in the results field. Final status.

   • FAILED — the scan could not be completed due to an error. The request is not billable. Final status.

Happy path

INITIALISED → PENDING → COMPLETED

Unhappy path

INITIALISED → PENDING → FAILED

Once a request reaches COMPLETED, the results field is populated with an array of AmsWebSearchResult objects. Each result represents a single web article found during the scan and includes:

Before doing any other API calls you have to obtain an auth token. It's a standard JWT token carrying the following payload:

The token lifetime is 4 hours at this time. We might change this value in the future.

To be more future-proof, it is recommended to parse the token payload and compare current time to the token's expiration time. JavaScript code:

1. After we enable you, go to the , click "DOCS" on the right to explore the possibilities.