Flywire API Basics

The Flywire API is an HTTP-based REST API that uses API Keys for authorization.

API request and response bodies are formatted in JSON.

Base URL

The base URL for the Flywire API is

https://api-platform.flywire.com/payments/v1/
You can check if the Flywire API is up and running on the status page: https://status.flywire.com

Registering for the Flywire API

You need to register an application in order to make requests to the Flywire API. To be able to register, you have to be a client of Flywire and have one or more recipients. Your application will have access to all the recipients that belong to a client.

Registering an application is a manual process at the moment. Please contact [email protected] to register and get the API Key for your application as well as a Shared Secret for validating notifications.

Authenticating your Requests

All requests to the Flywire API need to be authenticated with an API Key. You get your unique API Key after you’ve registered for the Flywire API.

To include your API Key in your requests, add your API Key in the header in the format:
X-Authentication-Key: {api_key}

curl https://base-url-placeholder/recipient
-X GET \
-H "Content-Type: application/json" \
-H "X-Authentication-Key: {api_key}" \

 

Format of Requests

Requests to the API are composed of the following components:

HTTP Method

GET: Retrieves data from a resource

POST: Creates a new entry

PUT: Fully updates a resource

PATCH: Partially updates a resource

DELETE: Deletes an existing resource

HTTP Parameters

Parameters that are added to the URL as query parameters. Some requests require HTTP parameters, some don't.

HTTP Headers

"Content-Type: application/json"

"X-Authentication-Key: {Your API Key}"

Base URL and Resource

Base URL followed by the resource to read or update, for example:

Production: https://api-platform.flywire.com/payments/v1/ payments

Sandbox: https://api-platform-sandbox.flywire.com/payments/v1/ payments

Body

A JSON required for most POST, PUT and PATCH requests.

curl https://base-url-placeholder/payments/UUI754118889/authorization_adjustments
-X POST \
-H "Content-Type: application/json" \
-H "X-Authentication-Key: {api_key}" \
-d '{
    "amount": 70000
}'

Format of Responses

Flywire uses conventional HTTP response codes to indicate the success or failure of an API request. Each request returns a success or error HTTP status code.

Success response codes (2xx)

Codes in the 2xx range indicate success.

Status code Description
200 - OK Request has been successfully processed.
201 - Created Create resource operation successfully performed.
204 - No content The update operation completed successfully. No response body returned.

Error response codes (4xx and 5xx)

See Error Handling Guide for details about error responses.

Rate Limits

The Flywire API limits how many requests you can send in a certain time to avoid traffic spikes.

 

Environment Rate Limit
Flywire API Production

500 requests per minute

Flywire API Sandbox

500 requests per minute

  • Rate limits are enforced per IP address, not per application.

  • If you exceed the rate limit, you will receive an 429 error message and you will be blocked from accessing the Flywire API for 10 minutes.

Pagination

If a request returns a lot of results you can use pagination to split the results up into smaller pieces. On the server side, pagination helps to reduce the payload which leads to better response times. On your side, it leads to a better user experience since instead of one long list they get a shorter list separated into multiple pages. This can be helpful especially on smaller screens like on mobile devices.

Pagination parameters and how to add them

Only endpoints that return lists support pagination.

Is there a default pagination?

If an endpoint supports pagination, the result will always be returned with default pagination.

The default setting is:

page=1 (start on page 1)

per_page=10 (display 10 entries per page)

You can change the pagination setting in your request via the pagination parameters.

How to use the pagination parameters in a requests

Pagination parameters are added as query parameters with the request in the format {endpoint_path}?page=2&per_page=10

curl https://base-url-placeholder/offers?amount=12000&country=US&recipient=FWU&page=1&per_page=10 \
-X GET \
-H "Content-Type: application/json" \
-H "X-Authentication-Key: {api_key}" \

Response example with pagination

The pagination parameters are followed by an array of the items of the current page. The number of items in the array depends on the per_page value, for example the array will contain 10 items if the per_page value is 10.

Parameters for pagination

{
  "total_entries": 1,
  "total_pages": 1,
  "page": 1,
  "per_page": 10,
  "payments": [
...
  ]
}

Currencies

Payer currency vs. recipient currency

When dealing with currencies, you have to keep in mind that there can be two different currencies involved in one payment if there is FX (Foreign Exchange) necessary for the payment. For example, the payer can pay in Indian Rupees (INR) and the recipient receives Dollars (USD). In that case, you have to look at the two different sides of the payment, the payer and the recipient:

  • Payer's side: The payer currency

    The payer currency is the currency the payer pays in. If the payer currency is different from the billing currency, it will be converted to the billing currency.
  • Recipient side: The billing currency

    The billing currency is the currency in which the recipient of the payment is billing their payer. The billing currency depends on the recipient's configuration and is defined when the recipient is set up by Flywire.

Subunits

Subunits are the smallest unit of a currency, defined by its decimal system.

  • Usually currencies have 2 decimal places. For example, 120.00 United States Dollars (USD) is represented as 12,000 cents (subunit to unit = 100).

  • Some currencies, like the Japanese Yen (JPY), do not have decimal places (subunit to unit = 1).

  • Some currencies, like the Vietnamese Dong (VND), have 1 decimal place (subunit to unit = 10).

  • Some currencies, like the Bahraini Dinar (BHD), have 3 decimal places (subunit to unit = 1,000).

Currency codes

Each currency has an ISO 4217 code.

Whenever you need to specify a currency in Flywire, use its ISO 4217 code, not the full name.

List of currency codes and subunits

Currency
ISO 4217 code
Currency Full Name Subunit to Unit
AED United Arab Emirates Dirhams 100
AFN Afghan afghanis 100
AMD Armenian drams 100
ANG Netherlands Antillean guilders 100
AOA Angolan kwanzas 100
ARS Argentine pesos 100
AUD Australian Dollars 100
AWG Aruban florin 100
AZN Azerbaijani Manat 100
BAM Bosnia and Herzegovina convertible marks 100
BBD Barbadian dollars 100
BDT Bangladeshi takas 100
BGN Bulgarian Levs 100
BHD Bahraini Dinars 1,000
BIF Burundian franc 100
BMD Bermudian Dollars 100
BND Brunei dollar 100
BOB Bolivian Bolivianos 100
BRL Brazilian Reals 100
BSD Bahamian Dollars 100
BTN Bhutanese ngultrum 100
BWP Botswana pula 100
BZD Belize dollars 100
CAD Canadian Dollars 100
CDF Congolese francs 100
CHF Swiss Francs 100
CLP Chilean pesos 1
CNH Chinese Yuan (Offshore) Renminbi 100
CNY Chinese Yuan Renminbi 100
COP Colombian pesos 100
CRC Costa Rican colones 100
CVE Cape Verdean escudos 100
CZK Czech Korunas 100
DJF Djiboutian francs 100
DKK Danish Kroner 100
DOP Dominican pesos 100
DZD Algerian dinars 100
EGP Egyptian pounds 100
ERN Eritrean Nakfas 100
ETB Ethiopian Birrs 100
EUR Euros 100
FJD Fijian Dollars 100
FKP Falkland Islands pounds 100
GBP British Pounds 100
GEL Georgian lari 100
GHS Ghana cedis 100
GIP Gibraltar Pounds 100
GMD Gambian dalasis 100
GNF Guinean francs 100
GTQ Guatemalan Quetzals 100
GYD Guyanaese Dollars 100
HKD Hong Kong Dollars 100
HNL Honduran lempiras 100
HRK Croatian Kunas 100
HTG Haitian gourdes 100
HUF Hungarian Forints 100
IDR Indonesian Rupiahs 100
ILS Israeli New Sheqels 100
INR Indian Rupees 100
ISK Icelandic krónur 100
JMD Jamaican dollars 100
JOD Jordanian Dinars 100
JPY Japanese Yen 1
KES Kenyan Shillings 100
KGS Kyrgyzstani Som 100
KHR Cambodian Riels 100
KMF Comorian francs 100
KRW South Korean Won 100
KWD Kuwaiti Dinars 1,000
KYD Cayman Island Dollars 100
KZT Kazakhstani tenge 100
LAK Lao kip 100
LBP Lebanese Pounds 100
LKR Sri Lankan rupees 100
LRD Liberian dollars 100
LSL Lesotho maloti 100
LYD Libyan Dinars 1,000
MAD Moroccan Dirhams 100
MDL Moldovan lei 100
MGA Malagasy ariary 5
MKD Macedonian denari 100
MMK Myanmar kyat 100
MNT Mongolian tugriks 100
MOP Macau Patacas 100
MUR Mauritian Rupees 100
MVR Maldivian Rufiyaas 100
MWK Malawian kwachas 100
MXN Mexican Pesos 100
MYR Malaysian Ringgits 100
MZN Mozambican meticais 100
NAD Namibian Dollars 100
NGN Nigerian Naira 100
NIO Nicaraguan córdobas 100
NOK Norwegian Kroner 100
NPR Nepalese rupees 100
NZD New Zealand Dollars 100
OMR Omani Rials 1,000
PAB Panamanian Balboas 100
PEN Peruvian Nuevo Sols 100
PGK Papua New Guinean kina 100
PHP Philippine Pisos 100
PKR Pakistani rupees 100
PLN Polish złoties 100
PYG Paraguayan guaranies 100
QAR Qatari Riyals 100
RON Romanian Leus 100
RSD Serbian Dinars 100
RWF Rwandan francs 100
SAR Saudi Riyals 100
SBD Solomon Islands dollars 100
SCR Seychellois rupees 100
SEK Swedish Kronor 100
SGD Singapore Dollars 100
SHP Saint Helena pounds 100
SLL Sierra Leonean leones 100
SOS Somali shillings 100
SRD Surinamese dollars 100
STD São Tomé and Príncipe dobras 100
SZL Swazi Lilangenis 100
THB Thai Bahts 100
TJS Tajikistani somoni 100
TND Tunisian Dinars 1,000
TOP Tongan paʻanga 100
TRY Turkish Liras 100
TTD Trinidad and Tobago Dollars 100
TWD New Taiwan Dollars 100
TZS Tanzanian shillings 100
UAH Ukrainian Hryvnia 100
UGX Ugandan shillings 100
USD United States Dollars 100
UYU Uruguayan pesos 100
UZS Uzbekistan So'm 100
VND Vietnamese Dong 10
VUV Vanuatu vatu 1
WST Samoan tālā 100
XAF CFA francs 100
XCD East Caribbean dollars 100
XOF West African CFA francs 100
XPF French Pacific Francs 100
YER Yemeni Rials 100
ZAR South African Rands 100
ZMW Zambian kwacha 100

Localization

The Flywire payment experience is localized, which means you can return results like field labels in different languages.

Not all resources support localization. You can find the information if a resource supports localization in the resource description.

The parameter for localization is called locale,

The default setting is US English (en). You can change the language by simply adding the locale parameter to a request in the following format:
https://api-platform.flywire.com/payments/v1/recipients/FWU?locale=zh-CN

Supported language values for the locale parameter

Language Value for locale
English en
Spanish es-ES
Chinese zh-CN
Korean ko
Portuguese pt-PT
Japanese ja
French fr-FR
Bahasa Indonesia id
Arabic ar
Vietnamese vi
Italian it-IT
German de-DE

Tip: Changing the text direction in browsers

The default text direction in browsers is left-to-right. If your localization is in a language that is written from right to left (for example Arabic), you need to change the text direction settings for your UI. To change the text direction to right-to-left, set the HTML dir attribute to rtl on the element that renders the text.

<div dir="rtl">
...
</div>

Example for a localized recipient object

This example shows a localized response for a recipient object.

In this example, the following fields are returned in Chinese:

fields array

view_options object

The view options contain additional information about how to display this field in your PayEx portal.

items array


  "id": "FWU",
  "name": "Flywire University",
...				
  "fields": [
   {
    "id": "student_id",
...
    "pattern_message": "FWU ID 以 F 开头,后接 8 位数字",
    "value": "",
    "view_options": {
       "section_identifier": "student_information",
       "section_name": "学生信息",
       "section_description": null,
       "label": "学号",
...					
       }
    }, 
    ...
    ],
  "items": [
        {
            "id": "default",
            "currency": "USD",
            "label": "金额"
        }
    ],
...					
    }
}

API Versioning

The Flywire API is constantly evolving. The changes made to the API can either be breaking or non-breaking changes:

  • Non-breaking changes add or change features without interfering with your system that sends requests to the API. This means you don't have to worry about non-breaking changes. You can choose to benefit from the new features or just ignore them.

  • Breaking changes however can interfere with the system you've set up. If Flywire introduces breaking changes, a new version of the API will be created. That way, you can choose if you want to keep using the old API version (your current system will still be working) or if you want to benefit from the changes and use the new API version. In that case, it is likely that you have to update your system for API requests.

Non-breaking Changes

The following changes to the Flywire API are considered non-breaking. You'll also find tips how to future-proof your system by keeping possible non-breaking changes in mind.

Endpoints and parameters:

  • Adding new API endpoints.

  • Adding new parameters to the responses from existing API endpoints.

  • Re-ordering parameters returned from existing API endpoints.

    Tip for backwards compatibility:

    Since the order of parameters can change (either by adding new parameters or by re-ordering existing ones), make sure your system doesn't rely on the order parameters come back in the responses. For example, don't use logic like "use the first parameter of the response" but always use the actual name of the parameter instead. Re-naming a parameter is a breaking change that will result in a new API version, which means your code will always work with the version it has been set up for.

  • Adding optional request parameters to existing API endpoints.

  • Altering the format or length of IDs and references.

    Tip for backwards compatibility:

    Do not add strict validation rules for the format and length of ID and reference parameters.

Notifications:

  • Adding new notifications for new event types.

  • Adding new parameters to the existing notifications payload.

Sandbox:

  • Adding new sandbox features.

  • Altering status change times of the existing sandbox features.

    Tip for backwards compatibility:

    Testing notifications in the sandbox works by putting a payment through different stages within a certain amount of time. These time intervals might change. Don't set your test system up to expect fixed time intervals.

Errors:

  • Altering the message attributes returned by validation failures / other errors.

Breaking Changes

Breaking changes will result in a new version of the Flywire API. Here are some examples of breaking changes:

  • Renaming of parameters.

  • Renaming of endpoints.

  • Deprecating endpoints.