{
"openapi": "3.0.3",
"info": {
"title": "trustshare API",
"version": "1.0.24",
"termsOfService": "http://trustshare.co/facilitator-terms.pdf",
"contact": {
"name": "Support",
"email": "support@trustshare.co"
},
"description": "Welcome to the trustshare API Reference documentation. Here you can find detailed\ninformation about the endpoints we provide as well as the shape of entities within\nthe system.\n\n# Environments\nThe trustshare API has two environments, __Sandbox__ and __Live__. Both environments are available under\nthe same endpoint however API Keys and client secrets are prefixed with the environment name.\n- A __Sandbox__ API Key will be in the format: `sandbox_api_[0-9a-z]`.\n- A __Live__ API Key will be in the format: `live_api_[0-9a-z]`.\n\n## Sandbox\nOur __Sandbox__ environment endeavours to be as close to the __Live__ environment as possible, however,\nthere are a couple of limitations and features which should be noted.\n- Card payments take around 7 days to settle into accounts. In __Live__ this is generally closer to 2 days.\n- Manual inbound payments can only be \"faked\" in __Sandbox__ when they are less-than or equal-to `250,000.00`.\n- Open Banking in __Sandbox__ will always use a \"Mock Bank\" UI to accept the payment."
},
"servers": [
{
"url": "https://rest.trustshare.io"
}
],
"tags": [
{
"name": "Checkouts",
"description": "Checkouts represent a specific payment transaction between a buyer and one, or many, seller\n[Participants](/resources/participants) in the __trustshare__ API. {{ className: \"lead\" }}\n\nCheckouts are created once a [Payment Intent](/resources/payment-intents) has\nbeen confirmed by a participant. When a checkout is created, it contains all the relevant\ninformation about the transaction, including the type of payment, the amount, and\nthe buyer participant's details. The status of the checkout is updated as the\ntransaction progresses through different stages, such as expecting funds (`settling`) or\nreceipt of funds (`settled`).\n\nYou can optionally listen to [Webhooks](/webhooks) to be notified of changes in status to\na checkout object."
},
{
"name": "Inbounds",
"description": "Inbounds represent the physical receipt of funds into a [Project](/resources/projects)\nin the __trustshare__ API. {{ className: \"lead\" }}\n\nIf the inbound does not include an associated [Checkout](/resources/checkouts), it can be\nconsidered _unreconciled_. We do our best to reconcile to [Settlements](/resources/settlements),\neven if we cannot reconcile to a specific checkout, by taking various factors into account.\nIncluding amount and the source of funds.\n\nYou can be notified via [Webhooks](/webhooks) when funds settle into a project account\nyou hold."
},
{
"name": "Invoices",
"description": "Invoices represent a small wrapper around [Checkouts](/resources/checkouts) in the\n__trustshare__ API, that also provide collection credentials that can be displayed to your buyers. {{ className: \"lead\" }}\n\nAn invoice is created at the confirmation of an `invoice`-type [Payment Intent](/resources/payment-intents).\nIt provides direct access to collection details and credentials, which are not usually available\non checkouts.\n\nInvoices work in tandem with [Checkouts](/resources/checkouts), and you should rely on the associated\ncheckout's status to keep up-to-date with status of the invoice."
},
{
"name": "Outbounds",
"description": "Outbounds represent the movement of funds out of a [Project](/resources/projects) in the\n__trustshare__ API. {{ className: \"lead\" }}\n\nIf an outbound is made to an `unverified` [Participant](/resources/participants), the outbound\nwill be paused and an automated verification process will be sent to the participants provided\nemail. Once complete, the outbound will automatically continue the process.\n\nAPI initiated outbounds, ie. `release` and `refund`, can be created before any funds are available.\nWhen this occurs, the outbound will remain in the `awaiting_funds` status until funds are received.\nThey can also be scheduled to occur at a specific date in the future, in this case the verification\nrequirements will be eagerly achieved, ie. the verification email would be sent out at the\npoint of creation, rather than the scheduled payment date.\n\nThe status of the outbound is updated as the payment progresses through different stages,\nsuch as requiring participant verification (`paused`) or funds have left the system (`executed`).\n\nYou can optionally listen to [Webhooks](/webhooks) to be notified of changes in status to\nan outbound object.\n\n## Outbound types\n\nAn outbound can be of one of the following types:\n\n - `release` - A release is made from a [Settlement](/resources/settlements) or directly\n from the project balance. If released from a settlement, it can only target the seller\n [Participant](/resources/participants) defined in the settlement itself.\n - `refund` - A refund can only be made from a [Settlement](/resources/settlements) and\n will only target the buyer [Participant](/resources/participants) defined on the settlement.\n - `transfer` - A transfer outbound is created automatically as part of an _inter-project_\n [Transfer](/resources/transfers).\n - `payout` - A payout outbound is automatically created weekly that will send funds from\n your revenue account directly to your bank accounts provided during onboarding."
},
{
"name": "Participants",
"description": "Participants represent a buyer or seller in the __trustshare__ API. {{ className: \"lead\" }}\n\nIn most cases, participants receiving funds from [Projects](/resources/projects) are\nrequired to be verified using a [Verification](/resources/verifications).\n\nYou can either create, and verify, participants up-front or you can create them lazily as\npart of a [Payment Intent](/resources/payment-intents). In either case, you can provide as\nmuch, or as little, information about the participant as you wish. The only requirement is\nat least an email address. The more information you provide during the creation\nof a participant, the less information the participant will have to\nprovide during the verification process.\n\nThe email address is the primary identifier for a participant, you can create as many\nparticipants with the same email address as you like. You will find that depending on\nthe level of provided information you may receive a different unique identifier than you had previously.\nThis is expected, and _using any ID related to a specific email address will work_.\nVerification for a specific email address is inherited across all associated participants.\n\n