DealMakerAPI 0.74.1 → 0.78.4

Sign up to get free protection for your applications and to get access to all the features.
Files changed (147) hide show
  1. checksums.yaml +4 -4
  2. data/DealMakerAPI.gemspec +2 -2
  3. data/README.md +73 -47
  4. data/docs/CreateCorporationProfileRequest.md +6 -0
  5. data/docs/CreateIndividualProfileRequest.md +7 -1
  6. data/docs/CreateInvestorRequest.md +2 -0
  7. data/docs/CreateJointProfileRequest.md +6 -0
  8. data/docs/CreateTrustProfileRequest.md +6 -0
  9. data/docs/PatchCorporationProfileRequest.md +6 -0
  10. data/docs/PatchIndividualProfileRequest.md +7 -1
  11. data/docs/PatchJointProfileRequest.md +6 -0
  12. data/docs/PatchTrustProfileRequest.md +6 -0
  13. data/docs/V1EntitiesDealFundingMetrics.md +4 -0
  14. data/docs/V1EntitiesInvestor.md +2 -2
  15. data/docs/V1EntitiesInvestorProfileCorporation.md +4 -0
  16. data/docs/V1EntitiesInvestorProfileFieldsCorporation.md +6 -0
  17. data/docs/V1EntitiesInvestorProfileFieldsPrimaryHolder.md +6 -0
  18. data/docs/V1EntitiesInvestorProfileFieldsTrust.md +6 -0
  19. data/docs/V1EntitiesInvestorProfileIndividual.md +4 -0
  20. data/docs/V1EntitiesInvestorProfileJoint.md +4 -0
  21. data/docs/V1EntitiesInvestorProfileOwner.md +22 -0
  22. data/docs/V1EntitiesInvestorProfileTrust.md +4 -0
  23. data/lib/DealMakerAPI/api/company_api.rb +2 -2
  24. data/lib/DealMakerAPI/api/deal_api.rb +2 -2
  25. data/lib/DealMakerAPI/api/deal_setup_api.rb +2 -2
  26. data/lib/DealMakerAPI/api/default_api.rb +2 -2
  27. data/lib/DealMakerAPI/api/investor_api.rb +2 -2
  28. data/lib/DealMakerAPI/api/investor_profile_api.rb +2 -2
  29. data/lib/DealMakerAPI/api_client.rb +2 -2
  30. data/lib/DealMakerAPI/api_error.rb +2 -2
  31. data/lib/DealMakerAPI/configuration.rb +3 -3
  32. data/lib/DealMakerAPI/models/create_company_request.rb +2 -2
  33. data/lib/DealMakerAPI/models/create_corporation_profile_request.rb +33 -3
  34. data/lib/DealMakerAPI/models/create_deal_setup_request.rb +2 -2
  35. data/lib/DealMakerAPI/models/create_individual_profile_request.rb +36 -6
  36. data/lib/DealMakerAPI/models/create_investor_request.rb +13 -3
  37. data/lib/DealMakerAPI/models/create_joint_profile_request.rb +33 -3
  38. data/lib/DealMakerAPI/models/create_trust_profile_request.rb +33 -3
  39. data/lib/DealMakerAPI/models/patch_corporation_profile_request.rb +33 -3
  40. data/lib/DealMakerAPI/models/patch_individual_profile_request.rb +36 -6
  41. data/lib/DealMakerAPI/models/patch_investor_request.rb +2 -2
  42. data/lib/DealMakerAPI/models/patch_joint_profile_request.rb +33 -3
  43. data/lib/DealMakerAPI/models/patch_trust_profile_request.rb +33 -3
  44. data/lib/DealMakerAPI/models/post_webhooks_request.rb +2 -2
  45. data/lib/DealMakerAPI/models/put_webhooks_id_request.rb +2 -2
  46. data/lib/DealMakerAPI/models/update_investor_request.rb +2 -2
  47. data/lib/DealMakerAPI/models/v1_entities_address.rb +2 -2
  48. data/lib/DealMakerAPI/models/v1_entities_addresses.rb +2 -2
  49. data/lib/DealMakerAPI/models/v1_entities_attachment.rb +2 -2
  50. data/lib/DealMakerAPI/models/v1_entities_background_check_search.rb +2 -2
  51. data/lib/DealMakerAPI/models/v1_entities_company.rb +2 -2
  52. data/lib/DealMakerAPI/models/v1_entities_company_deal.rb +2 -2
  53. data/lib/DealMakerAPI/models/v1_entities_company_deals.rb +2 -2
  54. data/lib/DealMakerAPI/models/v1_entities_deal.rb +2 -2
  55. data/lib/DealMakerAPI/models/v1_entities_deal_enterprise.rb +2 -2
  56. data/lib/DealMakerAPI/models/v1_entities_deal_funding_metrics.rb +23 -3
  57. data/lib/DealMakerAPI/models/v1_entities_deal_investor_metrics.rb +2 -2
  58. data/lib/DealMakerAPI/models/v1_entities_deal_issuer.rb +2 -2
  59. data/lib/DealMakerAPI/models/v1_entities_deal_setup.rb +2 -2
  60. data/lib/DealMakerAPI/models/v1_entities_deal_setup_user.rb +2 -2
  61. data/lib/DealMakerAPI/models/v1_entities_deals.rb +2 -2
  62. data/lib/DealMakerAPI/models/v1_entities_investor.rb +13 -13
  63. data/lib/DealMakerAPI/models/v1_entities_investor_otp_access_link.rb +2 -2
  64. data/lib/DealMakerAPI/models/v1_entities_investor_profile_address.rb +2 -2
  65. data/lib/DealMakerAPI/models/v1_entities_investor_profile_corporation.rb +22 -3
  66. data/lib/DealMakerAPI/models/v1_entities_investor_profile_fields_account_holder.rb +2 -2
  67. data/lib/DealMakerAPI/models/v1_entities_investor_profile_fields_corporation.rb +33 -3
  68. data/lib/DealMakerAPI/models/v1_entities_investor_profile_fields_primary_holder.rb +33 -3
  69. data/lib/DealMakerAPI/models/v1_entities_investor_profile_fields_trust.rb +33 -3
  70. data/lib/DealMakerAPI/models/v1_entities_investor_profile_individual.rb +22 -3
  71. data/lib/DealMakerAPI/models/v1_entities_investor_profile_item.rb +2 -2
  72. data/lib/DealMakerAPI/models/v1_entities_investor_profile_joint.rb +22 -3
  73. data/lib/DealMakerAPI/models/v1_entities_investor_profile_owner.rb +240 -0
  74. data/lib/DealMakerAPI/models/v1_entities_investor_profile_trust.rb +22 -3
  75. data/lib/DealMakerAPI/models/v1_entities_investor_profiles.rb +2 -2
  76. data/lib/DealMakerAPI/models/v1_entities_investor_user.rb +2 -2
  77. data/lib/DealMakerAPI/models/v1_entities_investors.rb +2 -2
  78. data/lib/DealMakerAPI/models/v1_entities_subscription_agreement.rb +2 -2
  79. data/lib/DealMakerAPI/models/v1_entities_webhooks_deal.rb +2 -2
  80. data/lib/DealMakerAPI/models/v1_entities_webhooks_security_token.rb +2 -2
  81. data/lib/DealMakerAPI/models/v1_entities_webhooks_subscription.rb +2 -2
  82. data/lib/DealMakerAPI/models/v1_entities_webhooks_subscription_deal.rb +2 -2
  83. data/lib/DealMakerAPI/models/v1_entities_webhooks_subscription_deals.rb +2 -2
  84. data/lib/DealMakerAPI/version.rb +3 -3
  85. data/lib/DealMakerAPI.rb +3 -2
  86. data/spec/api/company_api_spec.rb +5 -5
  87. data/spec/api/deal_api_spec.rb +4 -4
  88. data/spec/api/deal_setup_api_spec.rb +3 -3
  89. data/spec/api/default_api_spec.rb +8 -8
  90. data/spec/api/investor_api_spec.rb +8 -8
  91. data/spec/api/investor_profile_api_spec.rb +13 -13
  92. data/spec/api_client_spec.rb +2 -2
  93. data/spec/configuration_spec.rb +2 -2
  94. data/spec/models/create_company_request_spec.rb +10 -10
  95. data/spec/models/create_corporation_profile_request_spec.rb +53 -35
  96. data/spec/models/create_deal_setup_request_spec.rb +9 -9
  97. data/spec/models/create_individual_profile_request_spec.rb +34 -16
  98. data/spec/models/create_investor_request_spec.rb +20 -14
  99. data/spec/models/create_joint_profile_request_spec.rb +46 -28
  100. data/spec/models/create_trust_profile_request_spec.rb +42 -24
  101. data/spec/models/patch_corporation_profile_request_spec.rb +41 -23
  102. data/spec/models/patch_individual_profile_request_spec.rb +33 -15
  103. data/spec/models/patch_investor_request_spec.rb +4 -4
  104. data/spec/models/patch_joint_profile_request_spec.rb +45 -27
  105. data/spec/models/patch_trust_profile_request_spec.rb +41 -23
  106. data/spec/models/post_webhooks_request_spec.rb +7 -7
  107. data/spec/models/put_webhooks_id_request_spec.rb +9 -9
  108. data/spec/models/update_investor_request_spec.rb +6 -6
  109. data/spec/models/v1_entities_address_spec.rb +8 -8
  110. data/spec/models/v1_entities_addresses_spec.rb +3 -3
  111. data/spec/models/v1_entities_attachment_spec.rb +5 -5
  112. data/spec/models/v1_entities_background_check_search_spec.rb +3 -3
  113. data/spec/models/v1_entities_company_deal_spec.rb +4 -4
  114. data/spec/models/v1_entities_company_deals_spec.rb +3 -3
  115. data/spec/models/v1_entities_company_spec.rb +11 -11
  116. data/spec/models/v1_entities_deal_enterprise_spec.rb +4 -4
  117. data/spec/models/v1_entities_deal_funding_metrics_spec.rb +20 -8
  118. data/spec/models/v1_entities_deal_investor_metrics_spec.rb +8 -8
  119. data/spec/models/v1_entities_deal_issuer_spec.rb +4 -4
  120. data/spec/models/v1_entities_deal_setup_spec.rb +11 -11
  121. data/spec/models/v1_entities_deal_setup_user_spec.rb +4 -4
  122. data/spec/models/v1_entities_deal_spec.rb +15 -15
  123. data/spec/models/v1_entities_deals_spec.rb +3 -3
  124. data/spec/models/v1_entities_investor_otp_access_link_spec.rb +3 -3
  125. data/spec/models/v1_entities_investor_profile_address_spec.rb +8 -8
  126. data/spec/models/v1_entities_investor_profile_corporation_spec.rb +23 -11
  127. data/spec/models/v1_entities_investor_profile_fields_account_holder_spec.rb +8 -8
  128. data/spec/models/v1_entities_investor_profile_fields_corporation_spec.rb +24 -6
  129. data/spec/models/v1_entities_investor_profile_fields_primary_holder_spec.rb +27 -9
  130. data/spec/models/v1_entities_investor_profile_fields_trust_spec.rb +24 -6
  131. data/spec/models/v1_entities_investor_profile_individual_spec.rb +21 -9
  132. data/spec/models/v1_entities_investor_profile_item_spec.rb +3 -3
  133. data/spec/models/v1_entities_investor_profile_joint_spec.rb +23 -11
  134. data/spec/models/v1_entities_investor_profile_owner_spec.rb +46 -0
  135. data/spec/models/v1_entities_investor_profile_trust_spec.rb +22 -10
  136. data/spec/models/v1_entities_investor_profiles_spec.rb +3 -3
  137. data/spec/models/v1_entities_investor_spec.rb +31 -31
  138. data/spec/models/v1_entities_investor_user_spec.rb +4 -4
  139. data/spec/models/v1_entities_investors_spec.rb +3 -3
  140. data/spec/models/v1_entities_subscription_agreement_spec.rb +4 -4
  141. data/spec/models/v1_entities_webhooks_deal_spec.rb +5 -5
  142. data/spec/models/v1_entities_webhooks_security_token_spec.rb +3 -3
  143. data/spec/models/v1_entities_webhooks_subscription_deal_spec.rb +6 -6
  144. data/spec/models/v1_entities_webhooks_subscription_deals_spec.rb +3 -3
  145. data/spec/models/v1_entities_webhooks_subscription_spec.rb +8 -8
  146. data/spec/spec_helper.rb +2 -2
  147. metadata +50 -46
@@ -1,12 +1,12 @@
1
1
  =begin
2
2
  #DealMaker API
3
3
 
4
- ## Introduction Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with, and offers support in 2 different languages. This is the technical documentation for our API. There are tutorials and examples of integrations with our API available on our [knowledge centre](https://help.dealmaker.tech/training-centre) as well. # Libraries - Javascript - Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. Before you [generate an access token](#how-to-generate-an-access-token) your must first [create an application](#create-an-application) on your portal and retrieve the your client ID and secret ## Create an Application DealMaker’s Web API v1 supports the use of OAuth applications. Applications can be generated in your [account](https://app.dealmaker.tech/developer/applications). To create an API Application, click on your user name in the top right corner to open a dropdown menu, and select \"Integrations\". Under the API settings tab, click the `Create New Application` button ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-1.png) Name your application and assign the level of permissions for this application ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-2.png) Once your application is created, save in a secure space your client ID and secret. **WARNING**: The secret key will not be visible after you click the close button ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-3.png) From the developer tab, you will be able to view and manage all the available applications ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-4.png) Each Application consists of a client id, secret and set of scopes. The scopes define what resources you want to have access to. The client ID and secret are used to generate an access token. You will need to create an application to use API endpoints. ## How to generate an access token After creating an application, you must make a call to obtain a bearer token using the Generate an OAuth token operation. This operation requires the following parameters: `token endpoint` - https://app.dealmaker.tech/oauth/token `grant_type` - must be set to `client_credentials` `client_id` - the Client ID displayed when you created the OAuth application in the previous step `client_secret` - the Client Secret displayed when you created the OAuth application in the previous step `scope` - the scope is established when you created the OAuth application in the previous step Note: The Generate an OAuth token response specifies how long the bearer token is valid for. You should reuse the bearer token until it is expired. When the token is expired, call Generate an OAuth token again to generate a new one. To use the access token, you must set a plain text header named `Authorization` with the contents of the header being “Bearer XXX” where XXX is your generated access token. ### Example #### Postman Here's an example on how to generate the access token with Postman, where `{{CLIENT_ID}}` and `{{CLIENT_SECRET}}` are the values generated after following the steps on [Create an Application](#create-an-application) ![Get access token postman example](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/token-postman.png) # Status Codes ## Content-Type Header All responses are returned in JSON format. We specify this by sending the Content-Type header. ## Status Codes Below is a table containing descriptions of the various status codes we currently support against various resources. Sometimes your API call will generate an error. Here you will find additional information about what to expect if you don’t format your request properly, or we fail to properly process your request. | Status Code | Description | | ----------- | ----------- | | `200` | Success | | `403` | Forbidden | | `404` | Not found | # Pagination Pagination is used to divide large responses is smaller portions (pages). By default, all endpoints return a maximum of 25 records per page. You can change the number of records on a per request basis by passing a `per_page` parameter in the request header parameters. The largest supported `per_page` parameter is 100. When the response exceeds the `per_page` parameter, you can paginate through the records by increasing the `offset` parameter. Example: `offset=25` will return 25 records starting from 26th record. You may also paginate using the `page` parameter to indicate the page number you would like to show on the response. Please review the table below for the input parameters ## Inputs | Parameter | Description | | ---------- | ------------------------------------------------------------------------------- | | `per_page` | Amount of records included on each page (Default is 25) | | `page` | Page number | | `offset` | Amount of records offset on the API request where 0 represents the first record | ## Response Headers | Response Header | Description | | --------------- | -------------------------------------------- | | `X-Total` | Total number of records of response | | `X-Total-Pages` | Total number of pages of response | | `X-Per-Page` | Total number of records per page of response | | `X-Page` | Number of current page | | `X-Next-Page` | Number of next page | | `X-Prev-Page` | Number of previous page | | `X-Offset` | Total number of records offset | # Search and Filtering (The q parameter) The q optional parameter accepts a string as input and allows you to filter the request based on that string. Please note that search strings must be encoded according to ASCII. For example, \"john+investor&#64;dealmaker.tech\" should be passed as “john%2Binvestor%40dealmaker.tech”. There are two main ways to filter with it. ## Keyword filtering Some keywords allow you to filter investors based on a specific “scope” of the investors, for example using the string “Invited” will filter all investors with the status invited, and the keyword “Has attachments” will filter investors with attachments. Here’s a list of possible keywords and the “scope” each one of the keywords filters by: | Keywords | Scope | Decoded Example | Encoded Example | | ---------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Signed on \\(date range\\) | Investors who signed in the provided date range | Signed on (date range) [2020-07-01:2020-07-31] | `Signed%20on%20%28date%20range%29%20%5B2020-07-01%3A2020-07-31%5D` | | Enabled for countersignature on \\(date range\\) | Investors who were enabled for counter signature in the provided date range | Enabled for countersignature on (date range) [2022-05-24:2022-05-25] | `Enabled%20for%20countersignature%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Accepted on \\(date range\\) | Investors accepted in the provided date rage | Accepted on (date range) [2022-05-24:2022-05-25] | `Accepted%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Offline | Investors added to the deal offline | Offline | `Offline` | | Online | Investors added to the deal online | Online | `Online` | | Signed | Investors who signed their agreement | Signed | `Signed` | | Waiting for countersignature | Investors who have signed and are waiting for counter signature | Waiting for countersignature | `Waiting%20for%20countersignature` | | Invited | Investors on the Invited Status | Invited | `Invited` | | Accepted | Investors in the Accepted Status | Accepted | `Accepted` | | Questionnaire in progress | All Investors who have not finished completing the questionnaire | Questionnaire in progress | `Questionnaire%20in%20progress` | | Has attachments | All Investors with attachments | Has attachments | `Has%20attachments` | | Has notes | All Investors with notes | Has notes | `Has%20notes` | | Waiting for co-signature | Investors who have signed and are waiting for co-signature | Waiting for co-signature | `Waiting%20for%20co-signature` | | Background Check Approved | Investors with approved background check | Background Check Approved | `Background%20Check%20Approved` | | Document Review Pending | Investors with pending review | Document Review Pending | `Document%20Review%20Pending` | | Document Upload Pending | Investors with pending documents to upload | Document Upload Pending | `Document%20Upload%20Pending` | | Required adjudicator review | Investors who are required to be review by the adjudicator | Required adjudicator review | `Required%20adjudicator%20review` | --- **NOTE** Filtering keywords are case sensitive and need to be encoded --- ## Search String Any value for the parameter which does not match one of the keywords listed above, will use fields like `first name`, `last name`, `email`, `tags` to search for the investor. For example, if you search “Robert”, because this does not match one of the keywords listed above, it will then return any investors who have the string “Robert” in their name, email, or tags fields. # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ------- | ----------------------------------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links - [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) - [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. The type of data that the webhooks include: - Investor Name - Date created - Email - Phone - Allocation - Attachments - Accredited investor status - Accredited investor category - Status (Draft, Invited, Accepted, Waiting) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: - Investor is created - Investor details are updated (any of the investor details above change or are updated) - Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: - The HTTPS URL where the request will be sent - Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. - An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` - Triggers every time a new investor is added to a deal 2. `investor.updated` - Triggers on updates to any of the following fields: 1. Status 2. Name 3. Email - (this is a user field so we trigger event for all investors with webhook subscription) 4. Allocated Amount 5. Investment Amount 6. Accredited investor fields 7. Adding or removing attachments 8. Tags - When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.deleted` - Triggers when the investor is removed from the deal - The investor key of the payload only includes investor ID - The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests - The request is a `POST` - The payload’s `content-type` is `application/json` - Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry - We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail - If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. | Key | Type | Description | | ----------------- | ------ | -------------------------------------------------------------------------------------- | | event | String | The event that triggered the call | | event_id | String | A unique identifier for the event | | deal<sup>\\*</sup> | Object | The deal in which the event occurred. It includes id, title, created_at and updated_at | <sup>\\*</sup>This field is not included when deleting a resource #### Common Properties (investor scope) Every event on this scope must contain an investor object, here are some properties that are common to this object on all events in the investor scope: | Key | Type | Description | | ------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------ | | id | Integer | The unique ID of the Investor | | name | String | Investor’s Name | | status | String | Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted | | email | String | | | phone_number | String | | | investment_amount | Double | | | allocated_amount | Double | | | accredited_investor | Object | See format in respective ticket | | attachments | Array of Objects | List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption) | | funding_state | String | Investor’s current funding state (unfunded, underfunded, funded, overfunded) | | funds_pending | Boolean | True if there are pending transactions, False otherwise | | created_at | Date | | | updated_at | Date | | | tags | Array of Strings | a list of the investor's tags, separated by comma. | ### investor.status >= signed Specific Properties | Key | Type | Description | | ---------------------- | ------ | ---------------------- | | subscription_agreement | object | id, url (expiring URL) | #### Investor Status Here is a brief description of each investor state: - **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal - **Invited:** the investor was added to the platform but hasn’t completed the questionnaire - **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) - **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal - **Accepted:** the investor's agreement was countersigned by the Signatory #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
4
+ ## Introduction Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with, and offers support in 2 different languages. This is the technical documentation for our API. There are tutorials and examples of integrations with our API available on our [knowledge centre](https://help.dealmaker.tech/training-centre) as well. # Libraries - Javascript - Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. Before you [generate an access token](#how-to-generate-an-access-token) your must first [create an application](#create-an-application) on your portal and retrieve the your client ID and secret ## Create an Application DealMaker’s Web API v1 supports the use of OAuth applications. Applications can be generated in your [account](https://app.dealmaker.tech/developer/applications). To create an API Application, click on your user name in the top right corner to open a dropdown menu, and select \"Integrations\". Under the API settings tab, click the `Create New Application` button ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-1.png) Name your application and assign the level of permissions for this application ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-2.png) Once your application is created, save in a secure space your client ID and secret. **WARNING**: The secret key will not be visible after you click the close button ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-3.png) From the developer tab, you will be able to view and manage all the available applications ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-4.png) Each Application consists of a client id, secret and set of scopes. The scopes define what resources you want to have access to. The client ID and secret are used to generate an access token. You will need to create an application to use API endpoints. ## How to generate an access token After creating an application, you must make a call to obtain a bearer token using the Generate an OAuth token operation. This operation requires the following parameters: `token endpoint` - https://app.dealmaker.tech/oauth/token `grant_type` - must be set to `client_credentials` `client_id` - the Client ID displayed when you created the OAuth application in the previous step `client_secret` - the Client Secret displayed when you created the OAuth application in the previous step `scope` - the scope is established when you created the OAuth application in the previous step Note: The Generate an OAuth token response specifies how long the bearer token is valid for. You should reuse the bearer token until it is expired. When the token is expired, call Generate an OAuth token again to generate a new one. To use the access token, you must set a plain text header named `Authorization` with the contents of the header being “Bearer XXX” where XXX is your generated access token. ### Example #### Postman Here's an example on how to generate the access token with Postman, where `{{CLIENT_ID}}` and `{{CLIENT_SECRET}}` are the values generated after following the steps on [Create an Application](#create-an-application) ![Get access token postman example](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/token-postman.png) # Status Codes ## Content-Type Header All responses are returned in JSON format. We specify this by sending the Content-Type header. ## Status Codes Below is a table containing descriptions of the various status codes we currently support against various resources. Sometimes your API call will generate an error. Here you will find additional information about what to expect if you don’t format your request properly, or we fail to properly process your request. | Status Code | Description | | ----------- | ----------- | | `200` | Success | | `403` | Forbidden | | `404` | Not found | # Pagination Pagination is used to divide large responses is smaller portions (pages). By default, all endpoints return a maximum of 25 records per page. You can change the number of records on a per request basis by passing a `per_page` parameter in the request header parameters. The largest supported `per_page` parameter is 100. When the response exceeds the `per_page` parameter, you can paginate through the records by increasing the `offset` parameter. Example: `offset=25` will return 25 records starting from 26th record. You may also paginate using the `page` parameter to indicate the page number you would like to show on the response. Please review the table below for the input parameters ## Inputs | Parameter | Description | | ---------- | ------------------------------------------------------------------------------- | | `per_page` | Amount of records included on each page (Default is 25) | | `page` | Page number | | `offset` | Amount of records offset on the API request where 0 represents the first record | ## Response Headers | Response Header | Description | | --------------- | -------------------------------------------- | | `X-Total` | Total number of records of response | | `X-Total-Pages` | Total number of pages of response | | `X-Per-Page` | Total number of records per page of response | | `X-Page` | Number of current page | | `X-Next-Page` | Number of next page | | `X-Prev-Page` | Number of previous page | | `X-Offset` | Total number of records offset | # Search and Filtering (The q parameter) The q optional parameter accepts a string as input and allows you to filter the request based on that string. Please note that search strings must be encoded according to ASCII. For example, \"john+investor&#64;dealmaker.tech\" should be passed as “john%2Binvestor%40dealmaker.tech”. There are two main ways to filter with it. ## Keyword filtering Some keywords allow you to filter investors based on a specific “scope” of the investors, for example using the string “Invited” will filter all investors with the status invited, and the keyword “Has attachments” will filter investors with attachments. Here’s a list of possible keywords and the “scope” each one of the keywords filters by: | Keywords | Scope | Decoded Example | Encoded Example | | ---------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Signed on \\(date range\\) | Investors who signed in the provided date range | Signed on (date range) [2020-07-01:2020-07-31] | `Signed%20on%20%28date%20range%29%20%5B2020-07-01%3A2020-07-31%5D` | | Enabled for countersignature on \\(date range\\) | Investors who were enabled for counter signature in the provided date range | Enabled for countersignature on (date range) [2022-05-24:2022-05-25] | `Enabled%20for%20countersignature%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Accepted on \\(date range\\) | Investors accepted in the provided date rage | Accepted on (date range) [2022-05-24:2022-05-25] | `Accepted%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Offline | Investors added to the deal offline | Offline | `Offline` | | Online | Investors added to the deal online | Online | `Online` | | Signed | Investors who signed their agreement | Signed | `Signed` | | Waiting for countersignature | Investors who have signed and are waiting for counter signature | Waiting for countersignature | `Waiting%20for%20countersignature` | | Invited | Investors on the Invited Status | Invited | `Invited` | | Accepted | Investors in the Accepted Status | Accepted | `Accepted` | | Questionnaire in progress | All Investors who have not finished completing the questionnaire | Questionnaire in progress | `Questionnaire%20in%20progress` | | Has attachments | All Investors with attachments | Has attachments | `Has%20attachments` | | Has notes | All Investors with notes | Has notes | `Has%20notes` | | Waiting for co-signature | Investors who have signed and are waiting for co-signature | Waiting for co-signature | `Waiting%20for%20co-signature` | | Background Check Approved | Investors with approved background check | Background Check Approved | `Background%20Check%20Approved` | | Document Review Pending | Investors with pending review | Document Review Pending | `Document%20Review%20Pending` | | Document Upload Pending | Investors with pending documents to upload | Document Upload Pending | `Document%20Upload%20Pending` | | Required adjudicator review | Investors who are required to be review by the adjudicator | Required adjudicator review | `Required%20adjudicator%20review` | --- **NOTE** Filtering keywords are case sensitive and need to be encoded --- ## Search String Any value for the parameter which does not match one of the keywords listed above, will use fields like `first name`, `last name`, `email`, `tags` to search for the investor. For example, if you search “Robert”, because this does not match one of the keywords listed above, it will then return any investors who have the string “Robert” in their name, email, or tags fields. # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ------- | ----------------------------------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links - [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) - [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. Some of the data that the webhooks include: - Investor Name - Date created - Email - Phone - Allocation - Attachments - Accredited investor status - Accredited investor category - State (Draft, Invited, Signed, Accepted, Waiting, Inactive) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: - Investor is created - Investor details are updated (any of the investor details above change or are updated) - Investor has signed their agreement - Invertor fully funded their investment - Investor has been accepted - Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: - The HTTPS URL where the request will be sent - Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. - The Deal(s) to include in the webhook subscription - An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` - Triggers every time a new investor is added to a deal 2. `investor.updated` - Triggers on updates to any of the following fields: - Status - Name - Email - (this is a user field so we trigger event for all investors with webhook subscription) - Allocated Amount - Investment Amount - Accredited investor fields - Adding or removing attachments - Tags - When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.signed` - Triggers when the investor signs their subscription agreement (terms and conditions) - When this happens the investor.state becomes `signed` - This event includes the same fields as the `investor.updated` event 4. `investor.funded` - Triggers when the investor becomes fully funded - This happens when the investor.funded_state becomes `funded` - This event includes the same fields as the `investor.updated` event 5. `investor.accepted` - Triggers when the investor is countersigned - When this happens the investor.state becomes `accepted` - This event includes the same fields as the `investor.updated` event 6. `investor.deleted` - Triggers when the investor is removed from the deal - The investor key of the payload only includes investor ID - The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests - The request is a `POST` - The payload’s `content-type` is `application/json` - Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry - We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail - If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. | Key | Type | Description | | ----------------- | ------ | -------------------------------------------------------------------------------------- | | event | String | The event that triggered the call | | event_id | String | A unique identifier for the event | | deal<sup>\\*</sup> | Object | The deal in which the event occurred. please see below for an example on the deal object<sup>\\*\\*</sup> | <sup>\\*</sup>This field is not included when deleting a resource <sup>\\*\\*</sup> Sample Deal Object in the webhook payload ```json \"deal\": { \"id\": 0, \"title\": \"string\", \"created_at\": \"2022-12-06T18:14:44.000Z\", \"updated_at\": \"2022-12-08T12:46:48.000Z\", \"state\": \"string\", \"currency\": \"string\", \"security_type\": \"string\", \"price_per_security\": 0.00, \"deal_type\": \"string\", \"minimum_investment\": 0, \"maximum_investment\": 0, \"issuer\": { \"id\": 0, \"name\": \"string\" }, \"enterprise\": { \"id\": 0, \"name\": \"string\" } } ``` #### Common Properties (investor scope) By design, we have incorporated on the webhooks payload the same investor-related fields included in the Investor model, for reference on the included fields, their types and values please click [here](https://docs.dealmaker.tech/#tag/investor_model). This will allow you to get all the necessary information you need about a particular investor without having to call the Get Investor by ID endpoint. | #### Investor State Here is a brief description of each investor state: - **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal - **Invited:** the investor was added to the platform but hasn’t completed the questionnaire - **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) - **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal - **Accepted:** the investor's agreement was countersigned by the Signatory - **Inactive** the investor is no longer eligible to participate in the offering. This may be because their warrant expired, they requested a refund, or they opted out of the offering #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
5
5
 
6
6
  The version of the OpenAPI document: 1.0.0
7
7
 
8
8
  Generated by: https://openapi-generator.tech
9
- OpenAPI Generator version: 6.5.0-SNAPSHOT
9
+ OpenAPI Generator version: 7.0.0-SNAPSHOT
10
10
 
11
11
  =end
12
12
 
@@ -27,13 +27,13 @@ describe DealMakerAPI::CreateCorporationProfileRequest do
27
27
  end
28
28
  describe 'test attribute "email"' do
29
29
  it 'should work' do
30
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
30
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
31
31
  end
32
32
  end
33
33
 
34
34
  describe 'test attribute "us_accredited_category"' do
35
35
  it 'should work' do
36
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
36
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
37
37
  # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["entity_owned_by_accredited_investors", "assets_other", "assets_family_office", "assets_benefit_plan", "assets_state_plan", "assets_501_c_3", "assets_corporation", "broker_or_dealer", "bank_3_a_2", "business_development_company", "private_business_development_company", "investment_company", "rural_business_investment_company", "insurance_company", "family_client", "not_accredited"])
38
38
  # validator.allowable_values.each do |value|
39
39
  # expect { instance.us_accredited_category = value }.not_to raise_error
@@ -43,187 +43,205 @@ describe DealMakerAPI::CreateCorporationProfileRequest do
43
43
 
44
44
  describe 'test attribute "name"' do
45
45
  it 'should work' do
46
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
46
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
47
47
  end
48
48
  end
49
49
 
50
50
  describe 'test attribute "country"' do
51
51
  it 'should work' do
52
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
52
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
53
53
  end
54
54
  end
55
55
 
56
56
  describe 'test attribute "street_address"' do
57
57
  it 'should work' do
58
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
58
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
59
59
  end
60
60
  end
61
61
 
62
62
  describe 'test attribute "unit2"' do
63
63
  it 'should work' do
64
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
64
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
65
65
  end
66
66
  end
67
67
 
68
68
  describe 'test attribute "city"' do
69
69
  it 'should work' do
70
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
70
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
71
71
  end
72
72
  end
73
73
 
74
74
  describe 'test attribute "region"' do
75
75
  it 'should work' do
76
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
76
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
77
77
  end
78
78
  end
79
79
 
80
80
  describe 'test attribute "postal_code"' do
81
81
  it 'should work' do
82
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
82
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
83
83
  end
84
84
  end
85
85
 
86
86
  describe 'test attribute "business_number"' do
87
87
  it 'should work' do
88
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
88
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
89
89
  end
90
90
  end
91
91
 
92
92
  describe 'test attribute "phone_number"' do
93
93
  it 'should work' do
94
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
94
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
95
+ end
96
+ end
97
+
98
+ describe 'test attribute "income"' do
99
+ it 'should work' do
100
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
101
+ end
102
+ end
103
+
104
+ describe 'test attribute "net_worth"' do
105
+ it 'should work' do
106
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
107
+ end
108
+ end
109
+
110
+ describe 'test attribute "reg_cf_prior_offerings_amount"' do
111
+ it 'should work' do
112
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
95
113
  end
96
114
  end
97
115
 
98
116
  describe 'test attribute "signing_officer_first_name"' do
99
117
  it 'should work' do
100
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
118
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
101
119
  end
102
120
  end
103
121
 
104
122
  describe 'test attribute "signing_officer_last_name"' do
105
123
  it 'should work' do
106
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
124
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
107
125
  end
108
126
  end
109
127
 
110
128
  describe 'test attribute "signing_officer_suffix"' do
111
129
  it 'should work' do
112
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
130
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
113
131
  end
114
132
  end
115
133
 
116
134
  describe 'test attribute "signing_officer_country"' do
117
135
  it 'should work' do
118
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
136
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
119
137
  end
120
138
  end
121
139
 
122
140
  describe 'test attribute "signing_officer_street_address"' do
123
141
  it 'should work' do
124
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
142
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
125
143
  end
126
144
  end
127
145
 
128
146
  describe 'test attribute "signing_officer_unit2"' do
129
147
  it 'should work' do
130
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
148
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
131
149
  end
132
150
  end
133
151
 
134
152
  describe 'test attribute "signing_officer_city"' do
135
153
  it 'should work' do
136
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
154
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
137
155
  end
138
156
  end
139
157
 
140
158
  describe 'test attribute "signing_officer_region"' do
141
159
  it 'should work' do
142
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
160
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
143
161
  end
144
162
  end
145
163
 
146
164
  describe 'test attribute "signing_officer_postal_code"' do
147
165
  it 'should work' do
148
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
166
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
149
167
  end
150
168
  end
151
169
 
152
170
  describe 'test attribute "signing_officer_date_of_birth"' do
153
171
  it 'should work' do
154
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
172
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
155
173
  end
156
174
  end
157
175
 
158
176
  describe 'test attribute "signing_officer_taxpayer_id"' do
159
177
  it 'should work' do
160
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
178
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
161
179
  end
162
180
  end
163
181
 
164
182
  describe 'test attribute "beneficial_owners_first_name"' do
165
183
  it 'should work' do
166
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
184
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
167
185
  end
168
186
  end
169
187
 
170
188
  describe 'test attribute "beneficial_owners_last_name"' do
171
189
  it 'should work' do
172
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
190
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
173
191
  end
174
192
  end
175
193
 
176
194
  describe 'test attribute "beneficial_owners_suffix"' do
177
195
  it 'should work' do
178
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
196
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
179
197
  end
180
198
  end
181
199
 
182
200
  describe 'test attribute "beneficial_owners_country"' do
183
201
  it 'should work' do
184
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
202
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
185
203
  end
186
204
  end
187
205
 
188
206
  describe 'test attribute "beneficial_owners_street_address"' do
189
207
  it 'should work' do
190
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
208
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
191
209
  end
192
210
  end
193
211
 
194
212
  describe 'test attribute "beneficial_owners_unit_2"' do
195
213
  it 'should work' do
196
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
214
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
197
215
  end
198
216
  end
199
217
 
200
218
  describe 'test attribute "beneficial_owners_city"' do
201
219
  it 'should work' do
202
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
220
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
203
221
  end
204
222
  end
205
223
 
206
224
  describe 'test attribute "beneficial_owners_region"' do
207
225
  it 'should work' do
208
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
226
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
209
227
  end
210
228
  end
211
229
 
212
230
  describe 'test attribute "beneficial_owners_postal_code"' do
213
231
  it 'should work' do
214
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
232
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
215
233
  end
216
234
  end
217
235
 
218
236
  describe 'test attribute "beneficial_owners_date_of_birth"' do
219
237
  it 'should work' do
220
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
238
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
221
239
  end
222
240
  end
223
241
 
224
242
  describe 'test attribute "beneficial_owners_taxpayer_id"' do
225
243
  it 'should work' do
226
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
244
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
227
245
  end
228
246
  end
229
247
 
@@ -1,12 +1,12 @@
1
1
  =begin
2
2
  #DealMaker API
3
3
 
4
- ## Introduction Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with, and offers support in 2 different languages. This is the technical documentation for our API. There are tutorials and examples of integrations with our API available on our [knowledge centre](https://help.dealmaker.tech/training-centre) as well. # Libraries - Javascript - Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. Before you [generate an access token](#how-to-generate-an-access-token) your must first [create an application](#create-an-application) on your portal and retrieve the your client ID and secret ## Create an Application DealMaker’s Web API v1 supports the use of OAuth applications. Applications can be generated in your [account](https://app.dealmaker.tech/developer/applications). To create an API Application, click on your user name in the top right corner to open a dropdown menu, and select \"Integrations\". Under the API settings tab, click the `Create New Application` button ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-1.png) Name your application and assign the level of permissions for this application ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-2.png) Once your application is created, save in a secure space your client ID and secret. **WARNING**: The secret key will not be visible after you click the close button ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-3.png) From the developer tab, you will be able to view and manage all the available applications ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-4.png) Each Application consists of a client id, secret and set of scopes. The scopes define what resources you want to have access to. The client ID and secret are used to generate an access token. You will need to create an application to use API endpoints. ## How to generate an access token After creating an application, you must make a call to obtain a bearer token using the Generate an OAuth token operation. This operation requires the following parameters: `token endpoint` - https://app.dealmaker.tech/oauth/token `grant_type` - must be set to `client_credentials` `client_id` - the Client ID displayed when you created the OAuth application in the previous step `client_secret` - the Client Secret displayed when you created the OAuth application in the previous step `scope` - the scope is established when you created the OAuth application in the previous step Note: The Generate an OAuth token response specifies how long the bearer token is valid for. You should reuse the bearer token until it is expired. When the token is expired, call Generate an OAuth token again to generate a new one. To use the access token, you must set a plain text header named `Authorization` with the contents of the header being “Bearer XXX” where XXX is your generated access token. ### Example #### Postman Here's an example on how to generate the access token with Postman, where `{{CLIENT_ID}}` and `{{CLIENT_SECRET}}` are the values generated after following the steps on [Create an Application](#create-an-application) ![Get access token postman example](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/token-postman.png) # Status Codes ## Content-Type Header All responses are returned in JSON format. We specify this by sending the Content-Type header. ## Status Codes Below is a table containing descriptions of the various status codes we currently support against various resources. Sometimes your API call will generate an error. Here you will find additional information about what to expect if you don’t format your request properly, or we fail to properly process your request. | Status Code | Description | | ----------- | ----------- | | `200` | Success | | `403` | Forbidden | | `404` | Not found | # Pagination Pagination is used to divide large responses is smaller portions (pages). By default, all endpoints return a maximum of 25 records per page. You can change the number of records on a per request basis by passing a `per_page` parameter in the request header parameters. The largest supported `per_page` parameter is 100. When the response exceeds the `per_page` parameter, you can paginate through the records by increasing the `offset` parameter. Example: `offset=25` will return 25 records starting from 26th record. You may also paginate using the `page` parameter to indicate the page number you would like to show on the response. Please review the table below for the input parameters ## Inputs | Parameter | Description | | ---------- | ------------------------------------------------------------------------------- | | `per_page` | Amount of records included on each page (Default is 25) | | `page` | Page number | | `offset` | Amount of records offset on the API request where 0 represents the first record | ## Response Headers | Response Header | Description | | --------------- | -------------------------------------------- | | `X-Total` | Total number of records of response | | `X-Total-Pages` | Total number of pages of response | | `X-Per-Page` | Total number of records per page of response | | `X-Page` | Number of current page | | `X-Next-Page` | Number of next page | | `X-Prev-Page` | Number of previous page | | `X-Offset` | Total number of records offset | # Search and Filtering (The q parameter) The q optional parameter accepts a string as input and allows you to filter the request based on that string. Please note that search strings must be encoded according to ASCII. For example, \"john+investor&#64;dealmaker.tech\" should be passed as “john%2Binvestor%40dealmaker.tech”. There are two main ways to filter with it. ## Keyword filtering Some keywords allow you to filter investors based on a specific “scope” of the investors, for example using the string “Invited” will filter all investors with the status invited, and the keyword “Has attachments” will filter investors with attachments. Here’s a list of possible keywords and the “scope” each one of the keywords filters by: | Keywords | Scope | Decoded Example | Encoded Example | | ---------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Signed on \\(date range\\) | Investors who signed in the provided date range | Signed on (date range) [2020-07-01:2020-07-31] | `Signed%20on%20%28date%20range%29%20%5B2020-07-01%3A2020-07-31%5D` | | Enabled for countersignature on \\(date range\\) | Investors who were enabled for counter signature in the provided date range | Enabled for countersignature on (date range) [2022-05-24:2022-05-25] | `Enabled%20for%20countersignature%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Accepted on \\(date range\\) | Investors accepted in the provided date rage | Accepted on (date range) [2022-05-24:2022-05-25] | `Accepted%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Offline | Investors added to the deal offline | Offline | `Offline` | | Online | Investors added to the deal online | Online | `Online` | | Signed | Investors who signed their agreement | Signed | `Signed` | | Waiting for countersignature | Investors who have signed and are waiting for counter signature | Waiting for countersignature | `Waiting%20for%20countersignature` | | Invited | Investors on the Invited Status | Invited | `Invited` | | Accepted | Investors in the Accepted Status | Accepted | `Accepted` | | Questionnaire in progress | All Investors who have not finished completing the questionnaire | Questionnaire in progress | `Questionnaire%20in%20progress` | | Has attachments | All Investors with attachments | Has attachments | `Has%20attachments` | | Has notes | All Investors with notes | Has notes | `Has%20notes` | | Waiting for co-signature | Investors who have signed and are waiting for co-signature | Waiting for co-signature | `Waiting%20for%20co-signature` | | Background Check Approved | Investors with approved background check | Background Check Approved | `Background%20Check%20Approved` | | Document Review Pending | Investors with pending review | Document Review Pending | `Document%20Review%20Pending` | | Document Upload Pending | Investors with pending documents to upload | Document Upload Pending | `Document%20Upload%20Pending` | | Required adjudicator review | Investors who are required to be review by the adjudicator | Required adjudicator review | `Required%20adjudicator%20review` | --- **NOTE** Filtering keywords are case sensitive and need to be encoded --- ## Search String Any value for the parameter which does not match one of the keywords listed above, will use fields like `first name`, `last name`, `email`, `tags` to search for the investor. For example, if you search “Robert”, because this does not match one of the keywords listed above, it will then return any investors who have the string “Robert” in their name, email, or tags fields. # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ------- | ----------------------------------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links - [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) - [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. The type of data that the webhooks include: - Investor Name - Date created - Email - Phone - Allocation - Attachments - Accredited investor status - Accredited investor category - Status (Draft, Invited, Accepted, Waiting) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: - Investor is created - Investor details are updated (any of the investor details above change or are updated) - Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: - The HTTPS URL where the request will be sent - Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. - An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` - Triggers every time a new investor is added to a deal 2. `investor.updated` - Triggers on updates to any of the following fields: 1. Status 2. Name 3. Email - (this is a user field so we trigger event for all investors with webhook subscription) 4. Allocated Amount 5. Investment Amount 6. Accredited investor fields 7. Adding or removing attachments 8. Tags - When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.deleted` - Triggers when the investor is removed from the deal - The investor key of the payload only includes investor ID - The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests - The request is a `POST` - The payload’s `content-type` is `application/json` - Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry - We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail - If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. | Key | Type | Description | | ----------------- | ------ | -------------------------------------------------------------------------------------- | | event | String | The event that triggered the call | | event_id | String | A unique identifier for the event | | deal<sup>\\*</sup> | Object | The deal in which the event occurred. It includes id, title, created_at and updated_at | <sup>\\*</sup>This field is not included when deleting a resource #### Common Properties (investor scope) Every event on this scope must contain an investor object, here are some properties that are common to this object on all events in the investor scope: | Key | Type | Description | | ------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------ | | id | Integer | The unique ID of the Investor | | name | String | Investor’s Name | | status | String | Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted | | email | String | | | phone_number | String | | | investment_amount | Double | | | allocated_amount | Double | | | accredited_investor | Object | See format in respective ticket | | attachments | Array of Objects | List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption) | | funding_state | String | Investor’s current funding state (unfunded, underfunded, funded, overfunded) | | funds_pending | Boolean | True if there are pending transactions, False otherwise | | created_at | Date | | | updated_at | Date | | | tags | Array of Strings | a list of the investor's tags, separated by comma. | ### investor.status >= signed Specific Properties | Key | Type | Description | | ---------------------- | ------ | ---------------------- | | subscription_agreement | object | id, url (expiring URL) | #### Investor Status Here is a brief description of each investor state: - **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal - **Invited:** the investor was added to the platform but hasn’t completed the questionnaire - **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) - **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal - **Accepted:** the investor's agreement was countersigned by the Signatory #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
4
+ ## Introduction Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with, and offers support in 2 different languages. This is the technical documentation for our API. There are tutorials and examples of integrations with our API available on our [knowledge centre](https://help.dealmaker.tech/training-centre) as well. # Libraries - Javascript - Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. Before you [generate an access token](#how-to-generate-an-access-token) your must first [create an application](#create-an-application) on your portal and retrieve the your client ID and secret ## Create an Application DealMaker’s Web API v1 supports the use of OAuth applications. Applications can be generated in your [account](https://app.dealmaker.tech/developer/applications). To create an API Application, click on your user name in the top right corner to open a dropdown menu, and select \"Integrations\". Under the API settings tab, click the `Create New Application` button ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-1.png) Name your application and assign the level of permissions for this application ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-2.png) Once your application is created, save in a secure space your client ID and secret. **WARNING**: The secret key will not be visible after you click the close button ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-3.png) From the developer tab, you will be able to view and manage all the available applications ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-4.png) Each Application consists of a client id, secret and set of scopes. The scopes define what resources you want to have access to. The client ID and secret are used to generate an access token. You will need to create an application to use API endpoints. ## How to generate an access token After creating an application, you must make a call to obtain a bearer token using the Generate an OAuth token operation. This operation requires the following parameters: `token endpoint` - https://app.dealmaker.tech/oauth/token `grant_type` - must be set to `client_credentials` `client_id` - the Client ID displayed when you created the OAuth application in the previous step `client_secret` - the Client Secret displayed when you created the OAuth application in the previous step `scope` - the scope is established when you created the OAuth application in the previous step Note: The Generate an OAuth token response specifies how long the bearer token is valid for. You should reuse the bearer token until it is expired. When the token is expired, call Generate an OAuth token again to generate a new one. To use the access token, you must set a plain text header named `Authorization` with the contents of the header being “Bearer XXX” where XXX is your generated access token. ### Example #### Postman Here's an example on how to generate the access token with Postman, where `{{CLIENT_ID}}` and `{{CLIENT_SECRET}}` are the values generated after following the steps on [Create an Application](#create-an-application) ![Get access token postman example](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/token-postman.png) # Status Codes ## Content-Type Header All responses are returned in JSON format. We specify this by sending the Content-Type header. ## Status Codes Below is a table containing descriptions of the various status codes we currently support against various resources. Sometimes your API call will generate an error. Here you will find additional information about what to expect if you don’t format your request properly, or we fail to properly process your request. | Status Code | Description | | ----------- | ----------- | | `200` | Success | | `403` | Forbidden | | `404` | Not found | # Pagination Pagination is used to divide large responses is smaller portions (pages). By default, all endpoints return a maximum of 25 records per page. You can change the number of records on a per request basis by passing a `per_page` parameter in the request header parameters. The largest supported `per_page` parameter is 100. When the response exceeds the `per_page` parameter, you can paginate through the records by increasing the `offset` parameter. Example: `offset=25` will return 25 records starting from 26th record. You may also paginate using the `page` parameter to indicate the page number you would like to show on the response. Please review the table below for the input parameters ## Inputs | Parameter | Description | | ---------- | ------------------------------------------------------------------------------- | | `per_page` | Amount of records included on each page (Default is 25) | | `page` | Page number | | `offset` | Amount of records offset on the API request where 0 represents the first record | ## Response Headers | Response Header | Description | | --------------- | -------------------------------------------- | | `X-Total` | Total number of records of response | | `X-Total-Pages` | Total number of pages of response | | `X-Per-Page` | Total number of records per page of response | | `X-Page` | Number of current page | | `X-Next-Page` | Number of next page | | `X-Prev-Page` | Number of previous page | | `X-Offset` | Total number of records offset | # Search and Filtering (The q parameter) The q optional parameter accepts a string as input and allows you to filter the request based on that string. Please note that search strings must be encoded according to ASCII. For example, \"john+investor&#64;dealmaker.tech\" should be passed as “john%2Binvestor%40dealmaker.tech”. There are two main ways to filter with it. ## Keyword filtering Some keywords allow you to filter investors based on a specific “scope” of the investors, for example using the string “Invited” will filter all investors with the status invited, and the keyword “Has attachments” will filter investors with attachments. Here’s a list of possible keywords and the “scope” each one of the keywords filters by: | Keywords | Scope | Decoded Example | Encoded Example | | ---------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Signed on \\(date range\\) | Investors who signed in the provided date range | Signed on (date range) [2020-07-01:2020-07-31] | `Signed%20on%20%28date%20range%29%20%5B2020-07-01%3A2020-07-31%5D` | | Enabled for countersignature on \\(date range\\) | Investors who were enabled for counter signature in the provided date range | Enabled for countersignature on (date range) [2022-05-24:2022-05-25] | `Enabled%20for%20countersignature%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Accepted on \\(date range\\) | Investors accepted in the provided date rage | Accepted on (date range) [2022-05-24:2022-05-25] | `Accepted%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Offline | Investors added to the deal offline | Offline | `Offline` | | Online | Investors added to the deal online | Online | `Online` | | Signed | Investors who signed their agreement | Signed | `Signed` | | Waiting for countersignature | Investors who have signed and are waiting for counter signature | Waiting for countersignature | `Waiting%20for%20countersignature` | | Invited | Investors on the Invited Status | Invited | `Invited` | | Accepted | Investors in the Accepted Status | Accepted | `Accepted` | | Questionnaire in progress | All Investors who have not finished completing the questionnaire | Questionnaire in progress | `Questionnaire%20in%20progress` | | Has attachments | All Investors with attachments | Has attachments | `Has%20attachments` | | Has notes | All Investors with notes | Has notes | `Has%20notes` | | Waiting for co-signature | Investors who have signed and are waiting for co-signature | Waiting for co-signature | `Waiting%20for%20co-signature` | | Background Check Approved | Investors with approved background check | Background Check Approved | `Background%20Check%20Approved` | | Document Review Pending | Investors with pending review | Document Review Pending | `Document%20Review%20Pending` | | Document Upload Pending | Investors with pending documents to upload | Document Upload Pending | `Document%20Upload%20Pending` | | Required adjudicator review | Investors who are required to be review by the adjudicator | Required adjudicator review | `Required%20adjudicator%20review` | --- **NOTE** Filtering keywords are case sensitive and need to be encoded --- ## Search String Any value for the parameter which does not match one of the keywords listed above, will use fields like `first name`, `last name`, `email`, `tags` to search for the investor. For example, if you search “Robert”, because this does not match one of the keywords listed above, it will then return any investors who have the string “Robert” in their name, email, or tags fields. # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ------- | ----------------------------------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links - [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) - [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. Some of the data that the webhooks include: - Investor Name - Date created - Email - Phone - Allocation - Attachments - Accredited investor status - Accredited investor category - State (Draft, Invited, Signed, Accepted, Waiting, Inactive) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: - Investor is created - Investor details are updated (any of the investor details above change or are updated) - Investor has signed their agreement - Invertor fully funded their investment - Investor has been accepted - Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: - The HTTPS URL where the request will be sent - Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. - The Deal(s) to include in the webhook subscription - An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` - Triggers every time a new investor is added to a deal 2. `investor.updated` - Triggers on updates to any of the following fields: - Status - Name - Email - (this is a user field so we trigger event for all investors with webhook subscription) - Allocated Amount - Investment Amount - Accredited investor fields - Adding or removing attachments - Tags - When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.signed` - Triggers when the investor signs their subscription agreement (terms and conditions) - When this happens the investor.state becomes `signed` - This event includes the same fields as the `investor.updated` event 4. `investor.funded` - Triggers when the investor becomes fully funded - This happens when the investor.funded_state becomes `funded` - This event includes the same fields as the `investor.updated` event 5. `investor.accepted` - Triggers when the investor is countersigned - When this happens the investor.state becomes `accepted` - This event includes the same fields as the `investor.updated` event 6. `investor.deleted` - Triggers when the investor is removed from the deal - The investor key of the payload only includes investor ID - The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests - The request is a `POST` - The payload’s `content-type` is `application/json` - Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry - We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail - If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. | Key | Type | Description | | ----------------- | ------ | -------------------------------------------------------------------------------------- | | event | String | The event that triggered the call | | event_id | String | A unique identifier for the event | | deal<sup>\\*</sup> | Object | The deal in which the event occurred. please see below for an example on the deal object<sup>\\*\\*</sup> | <sup>\\*</sup>This field is not included when deleting a resource <sup>\\*\\*</sup> Sample Deal Object in the webhook payload ```json \"deal\": { \"id\": 0, \"title\": \"string\", \"created_at\": \"2022-12-06T18:14:44.000Z\", \"updated_at\": \"2022-12-08T12:46:48.000Z\", \"state\": \"string\", \"currency\": \"string\", \"security_type\": \"string\", \"price_per_security\": 0.00, \"deal_type\": \"string\", \"minimum_investment\": 0, \"maximum_investment\": 0, \"issuer\": { \"id\": 0, \"name\": \"string\" }, \"enterprise\": { \"id\": 0, \"name\": \"string\" } } ``` #### Common Properties (investor scope) By design, we have incorporated on the webhooks payload the same investor-related fields included in the Investor model, for reference on the included fields, their types and values please click [here](https://docs.dealmaker.tech/#tag/investor_model). This will allow you to get all the necessary information you need about a particular investor without having to call the Get Investor by ID endpoint. | #### Investor State Here is a brief description of each investor state: - **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal - **Invited:** the investor was added to the platform but hasn’t completed the questionnaire - **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) - **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal - **Accepted:** the investor's agreement was countersigned by the Signatory - **Inactive** the investor is no longer eligible to participate in the offering. This may be because their warrant expired, they requested a refund, or they opted out of the offering #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
5
5
 
6
6
  The version of the OpenAPI document: 1.0.0
7
7
 
8
8
  Generated by: https://openapi-generator.tech
9
- OpenAPI Generator version: 6.5.0-SNAPSHOT
9
+ OpenAPI Generator version: 7.0.0-SNAPSHOT
10
10
 
11
11
  =end
12
12
 
@@ -27,13 +27,13 @@ describe DealMakerAPI::CreateDealSetupRequest do
27
27
  end
28
28
  describe 'test attribute "invoicing_email"' do
29
29
  it 'should work' do
30
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
30
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
31
31
  end
32
32
  end
33
33
 
34
34
  describe 'test attribute "issuer_industry"' do
35
35
  it 'should work' do
36
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
36
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
37
37
  # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["other", "beverage", "blockchain", "cannabis", "cpc", "gaming", "health", "industry", "mining", "real_estate", "retail", "tech", "psychedelics", "office_of_life_sciences", "office_of_energy_and_transportation", "office_of_real_estate_and_construction", "office_of_manufacturing", "office_of_technology", "office_of_trade_and_services", "office_of_finance", "office_of_international_corp_fin"])
38
38
  # validator.allowable_values.each do |value|
39
39
  # expect { instance.issuer_industry = value }.not_to raise_error
@@ -43,7 +43,7 @@ describe DealMakerAPI::CreateDealSetupRequest do
43
43
 
44
44
  describe 'test attribute "prohibited_industry"' do
45
45
  it 'should work' do
46
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
46
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
47
47
  # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["prohibited", "not_prohibited"])
48
48
  # validator.allowable_values.each do |value|
49
49
  # expect { instance.prohibited_industry = value }.not_to raise_error
@@ -53,7 +53,7 @@ describe DealMakerAPI::CreateDealSetupRequest do
53
53
 
54
54
  describe 'test attribute "offering_type"' do
55
55
  it 'should work' do
56
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
56
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
57
57
  # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["other", "canadian_private_placement", "regulation_a_plus_offering", "offering_memorandum", "regulation_cf_offering", "reg_d_506_c", "reg_d_506_b"])
58
58
  # validator.allowable_values.each do |value|
59
59
  # expect { instance.offering_type = value }.not_to raise_error
@@ -63,19 +63,19 @@ describe DealMakerAPI::CreateDealSetupRequest do
63
63
 
64
64
  describe 'test attribute "title"' do
65
65
  it 'should work' do
66
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
66
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
67
67
  end
68
68
  end
69
69
 
70
70
  describe 'test attribute "company_id"' do
71
71
  it 'should work' do
72
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
72
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
73
73
  end
74
74
  end
75
75
 
76
76
  describe 'test attribute "representative"' do
77
77
  it 'should work' do
78
- # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
78
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
79
79
  end
80
80
  end
81
81