Changelog
Send WebsiteStatus Page
Back to All
improved

API Schema Optimisations

July 16th, 2024 by Jake Wauchope

Overview

We're making a number of small changes to the API 2.0 specification to bring it up to industry best practises. These changes, whilst extensive, are all fairly minor and have no material impact on how the API is used.

Version Impacted: V2.0

Date Effective: 26 of July 2024

Updates to endpoint paths

We have updated all our endpoint names to make collections pluralised as is industry best practise in addition to hyphenating path names where multiple words exist. This has no impact on the functionality of each endpoint but helps to ensure clarity when reading the specification.

Updates to nested GET responses

We are updating how our GET endpoints response where nested objects existing (for example, payinAddresses are nested underneath wallets and paymentAddresses are nested underneath recipients). Since there are use cases where a wallet or recipient has a large number of nested sub-objects, we will be removing the sub-objects from the GET endpoint of the parent object (ie removing payinAddresses from GET/wallets/{walletId}). This is to prevent issues with payload size and unnecessary data transmission when the sub-objects are not required. These sub-objects can still be obtained using the relevant GET endpoints (for example, to get payinAddresses you can use GET/wallets/{walletId}/payin-Addresses).

Impacted Objects:

  • wallets and nested payinAddresses
  • recipients and nested paymentAddresses
  • trades and nested payouts

Updates to sensitive information in GET responses

In many instances, sensitive information is required to be given to Send through our POST endpoints in order to onboard a new account, or verify a new recipient. This sensitive information is handled with the upmost care once within Sends systems. In order to prevent any possibility of sensitive information leaks, Send will be removing this information from our GET endpoints. Send will however, still provide critical operational information in the GET responses, including: status, contact information and other non-sensitive data.

Impacted Endpoints:

  • All Accounts Endpoints
  • All Recipient Endpoints

Other minor changes

Along with the above updates, we've made a bunch of other minor quality of life improvements to our API2.0 spec. They are detailed below.

  • Added the ability to assign a payout an externalReference when creating it through POST/Trades.
  • Updated GET request pagination metadata naming (functionality remains the same).
  • Updated birthDate in POST/accounts/individual to dateOfBirth.
  • Made the physicalAddress.postCode field within POST/recipients to now be optional.
  • Fixed a typo on the description of POST/sandbox/payins.
  • Added the trust.registrationNumber and trust.physicalAddress fields to our POST/Accounts endpoints.
  • Updated the description on GET/rate-sheets/{rateSheetId}.
  • Updated the description on GET/payment.
  • Removed the need to supply a walletId and currency in the payinAddress object when you are creating a wallet and payinAddress together.
  • Removed trust.trustTrustees from our POST/Accounts endpoints.
  • Added a new list endpoint for fetching paymentAddresses - GET/recipients/{recipientId}/paymentAddresses.
  • Updated the DELETE/Webhooks 204 success response to include no response body.
  • Updated the payment status list to include the full list of possible payment statuses and to bring it into line with our payment status guide.
  • Added the optional field accountName within the paymentAddress object.
  • Made reference options in the post/payment/payout endpoint.

📘

Got Questions?

Got questions or concerns about this change? Head over to our Discussion Board and leave us a note.