DealMakerAPI 0.79.1 → 0.81.2

Sign up to get free protection for your applications and to get access to all the features.
Files changed (162) hide show
  1. checksums.yaml +4 -4
  2. data/DealMakerAPI.gemspec +1 -1
  3. data/README.md +16 -5
  4. data/docs/AddDocumentRequest.md +24 -0
  5. data/docs/CreateCorporationProfileRequest.md +3 -1
  6. data/docs/CreateIndividualProfileRequest.md +3 -1
  7. data/docs/CreateJointProfileRequest.md +3 -1
  8. data/docs/CreateTrustProfileRequest.md +3 -1
  9. data/docs/DealApi.md +71 -0
  10. data/docs/EditInvestorTagsRequest.md +20 -0
  11. data/docs/InvestorApi.md +212 -0
  12. data/docs/PatchCorporationProfileRequest.md +3 -1
  13. data/docs/PatchIndividualProfileRequest.md +3 -1
  14. data/docs/PatchJointProfileRequest.md +3 -1
  15. data/docs/PatchTrustProfileRequest.md +3 -1
  16. data/docs/ShareholderApi.md +141 -0
  17. data/docs/UpdateInvestorRequest.md +3 -1
  18. data/docs/V1EntitiesBackgroundCheckSearch.md +6 -2
  19. data/docs/V1EntitiesInvestorProfileCorporation.md +3 -1
  20. data/docs/V1EntitiesInvestorProfileIndividual.md +3 -1
  21. data/docs/V1EntitiesInvestorProfileJoint.md +3 -1
  22. data/docs/V1EntitiesInvestorProfileTrust.md +3 -1
  23. data/docs/V1EntitiesShareholder.md +22 -0
  24. data/docs/V1EntitiesShareholders.md +18 -0
  25. data/docs/V1EntitiesShareholdersTags.md +20 -0
  26. data/lib/DealMakerAPI/api/company_api.rb +1 -1
  27. data/lib/DealMakerAPI/api/deal_api.rb +67 -1
  28. data/lib/DealMakerAPI/api/deal_setup_api.rb +1 -1
  29. data/lib/DealMakerAPI/api/default_api.rb +1 -1
  30. data/lib/DealMakerAPI/api/investor_api.rb +234 -1
  31. data/lib/DealMakerAPI/api/investor_profile_api.rb +1 -1
  32. data/lib/DealMakerAPI/api/shareholder_api.rb +148 -0
  33. data/lib/DealMakerAPI/api_client.rb +1 -1
  34. data/lib/DealMakerAPI/api_error.rb +1 -1
  35. data/lib/DealMakerAPI/configuration.rb +1 -1
  36. data/lib/DealMakerAPI/models/add_document_request.rb +296 -0
  37. data/lib/DealMakerAPI/models/create_company_request.rb +1 -1
  38. data/lib/DealMakerAPI/models/create_corporation_profile_request.rb +25 -3
  39. data/lib/DealMakerAPI/models/create_deal_setup_request.rb +1 -1
  40. data/lib/DealMakerAPI/models/create_individual_profile_request.rb +25 -3
  41. data/lib/DealMakerAPI/models/create_investor_request.rb +1 -1
  42. data/lib/DealMakerAPI/models/create_joint_profile_request.rb +25 -3
  43. data/lib/DealMakerAPI/models/create_trust_profile_request.rb +25 -3
  44. data/lib/DealMakerAPI/models/edit_investor_tags_request.rb +273 -0
  45. data/lib/DealMakerAPI/models/patch_corporation_profile_request.rb +25 -3
  46. data/lib/DealMakerAPI/models/patch_individual_profile_request.rb +25 -3
  47. data/lib/DealMakerAPI/models/patch_investor_request.rb +1 -1
  48. data/lib/DealMakerAPI/models/patch_joint_profile_request.rb +25 -3
  49. data/lib/DealMakerAPI/models/patch_trust_profile_request.rb +25 -3
  50. data/lib/DealMakerAPI/models/post_webhooks_request.rb +1 -1
  51. data/lib/DealMakerAPI/models/put_webhooks_id_request.rb +1 -1
  52. data/lib/DealMakerAPI/models/update_investor_request.rb +15 -5
  53. data/lib/DealMakerAPI/models/v1_entities_address.rb +1 -1
  54. data/lib/DealMakerAPI/models/v1_entities_addresses.rb +1 -1
  55. data/lib/DealMakerAPI/models/v1_entities_attachment.rb +1 -1
  56. data/lib/DealMakerAPI/models/v1_entities_background_check_search.rb +25 -5
  57. data/lib/DealMakerAPI/models/v1_entities_company.rb +1 -1
  58. data/lib/DealMakerAPI/models/v1_entities_company_deal.rb +1 -1
  59. data/lib/DealMakerAPI/models/v1_entities_company_deals.rb +1 -1
  60. data/lib/DealMakerAPI/models/v1_entities_deal.rb +1 -1
  61. data/lib/DealMakerAPI/models/v1_entities_deal_enterprise.rb +1 -1
  62. data/lib/DealMakerAPI/models/v1_entities_deal_funding_metrics.rb +1 -1
  63. data/lib/DealMakerAPI/models/v1_entities_deal_investor_metrics.rb +1 -1
  64. data/lib/DealMakerAPI/models/v1_entities_deal_issuer.rb +1 -1
  65. data/lib/DealMakerAPI/models/v1_entities_deal_setup.rb +1 -1
  66. data/lib/DealMakerAPI/models/v1_entities_deal_setup_user.rb +1 -1
  67. data/lib/DealMakerAPI/models/v1_entities_deals.rb +1 -1
  68. data/lib/DealMakerAPI/models/v1_entities_investor.rb +1 -1
  69. data/lib/DealMakerAPI/models/v1_entities_investor_otp_access_link.rb +1 -1
  70. data/lib/DealMakerAPI/models/v1_entities_investor_profile_address.rb +1 -1
  71. data/lib/DealMakerAPI/models/v1_entities_investor_profile_corporation.rb +13 -3
  72. data/lib/DealMakerAPI/models/v1_entities_investor_profile_fields_account_holder.rb +1 -1
  73. data/lib/DealMakerAPI/models/v1_entities_investor_profile_fields_corporation.rb +1 -1
  74. data/lib/DealMakerAPI/models/v1_entities_investor_profile_fields_primary_holder.rb +1 -1
  75. data/lib/DealMakerAPI/models/v1_entities_investor_profile_fields_trust.rb +1 -1
  76. data/lib/DealMakerAPI/models/v1_entities_investor_profile_individual.rb +13 -3
  77. data/lib/DealMakerAPI/models/v1_entities_investor_profile_item.rb +1 -1
  78. data/lib/DealMakerAPI/models/v1_entities_investor_profile_joint.rb +13 -3
  79. data/lib/DealMakerAPI/models/v1_entities_investor_profile_owner.rb +1 -1
  80. data/lib/DealMakerAPI/models/v1_entities_investor_profile_trust.rb +13 -3
  81. data/lib/DealMakerAPI/models/v1_entities_investor_profiles.rb +1 -1
  82. data/lib/DealMakerAPI/models/v1_entities_investor_user.rb +1 -1
  83. data/lib/DealMakerAPI/models/v1_entities_investors.rb +1 -1
  84. data/lib/DealMakerAPI/models/v1_entities_shareholder.rb +240 -0
  85. data/lib/DealMakerAPI/models/v1_entities_shareholders.rb +220 -0
  86. data/lib/DealMakerAPI/models/v1_entities_shareholders_tags.rb +229 -0
  87. data/lib/DealMakerAPI/models/v1_entities_subscription_agreement.rb +1 -1
  88. data/lib/DealMakerAPI/models/v1_entities_webhooks_deal.rb +1 -1
  89. data/lib/DealMakerAPI/models/v1_entities_webhooks_security_token.rb +1 -1
  90. data/lib/DealMakerAPI/models/v1_entities_webhooks_subscription.rb +1 -1
  91. data/lib/DealMakerAPI/models/v1_entities_webhooks_subscription_deal.rb +1 -1
  92. data/lib/DealMakerAPI/models/v1_entities_webhooks_subscription_deals.rb +1 -1
  93. data/lib/DealMakerAPI/version.rb +2 -2
  94. data/lib/DealMakerAPI.rb +7 -1
  95. data/spec/api/company_api_spec.rb +1 -1
  96. data/spec/api/deal_api_spec.rb +14 -1
  97. data/spec/api/deal_setup_api_spec.rb +1 -1
  98. data/spec/api/default_api_spec.rb +1 -1
  99. data/spec/api/investor_api_spec.rb +43 -1
  100. data/spec/api/investor_profile_api_spec.rb +1 -1
  101. data/spec/api/shareholder_api_spec.rb +59 -0
  102. data/spec/api_client_spec.rb +1 -1
  103. data/spec/configuration_spec.rb +1 -1
  104. data/spec/models/add_document_request_spec.rb +56 -0
  105. data/spec/models/create_company_request_spec.rb +1 -1
  106. data/spec/models/create_corporation_profile_request_spec.rb +11 -1
  107. data/spec/models/create_deal_setup_request_spec.rb +1 -1
  108. data/spec/models/create_individual_profile_request_spec.rb +11 -1
  109. data/spec/models/create_investor_request_spec.rb +1 -1
  110. data/spec/models/create_joint_profile_request_spec.rb +11 -1
  111. data/spec/models/create_trust_profile_request_spec.rb +11 -1
  112. data/spec/models/edit_investor_tags_request_spec.rb +44 -0
  113. data/spec/models/patch_corporation_profile_request_spec.rb +11 -1
  114. data/spec/models/patch_individual_profile_request_spec.rb +11 -1
  115. data/spec/models/patch_investor_request_spec.rb +1 -1
  116. data/spec/models/patch_joint_profile_request_spec.rb +11 -1
  117. data/spec/models/patch_trust_profile_request_spec.rb +11 -1
  118. data/spec/models/post_webhooks_request_spec.rb +1 -1
  119. data/spec/models/put_webhooks_id_request_spec.rb +1 -1
  120. data/spec/models/update_investor_request_spec.rb +7 -1
  121. data/spec/models/v1_entities_address_spec.rb +1 -1
  122. data/spec/models/v1_entities_addresses_spec.rb +1 -1
  123. data/spec/models/v1_entities_attachment_spec.rb +1 -1
  124. data/spec/models/v1_entities_background_check_search_spec.rb +13 -1
  125. data/spec/models/v1_entities_company_deal_spec.rb +1 -1
  126. data/spec/models/v1_entities_company_deals_spec.rb +1 -1
  127. data/spec/models/v1_entities_company_spec.rb +1 -1
  128. data/spec/models/v1_entities_deal_enterprise_spec.rb +1 -1
  129. data/spec/models/v1_entities_deal_funding_metrics_spec.rb +1 -1
  130. data/spec/models/v1_entities_deal_investor_metrics_spec.rb +1 -1
  131. data/spec/models/v1_entities_deal_issuer_spec.rb +1 -1
  132. data/spec/models/v1_entities_deal_setup_spec.rb +1 -1
  133. data/spec/models/v1_entities_deal_setup_user_spec.rb +1 -1
  134. data/spec/models/v1_entities_deal_spec.rb +1 -1
  135. data/spec/models/v1_entities_deals_spec.rb +1 -1
  136. data/spec/models/v1_entities_investor_otp_access_link_spec.rb +1 -1
  137. data/spec/models/v1_entities_investor_profile_address_spec.rb +1 -1
  138. data/spec/models/v1_entities_investor_profile_corporation_spec.rb +7 -1
  139. data/spec/models/v1_entities_investor_profile_fields_account_holder_spec.rb +1 -1
  140. data/spec/models/v1_entities_investor_profile_fields_corporation_spec.rb +1 -1
  141. data/spec/models/v1_entities_investor_profile_fields_primary_holder_spec.rb +1 -1
  142. data/spec/models/v1_entities_investor_profile_fields_trust_spec.rb +1 -1
  143. data/spec/models/v1_entities_investor_profile_individual_spec.rb +7 -1
  144. data/spec/models/v1_entities_investor_profile_item_spec.rb +1 -1
  145. data/spec/models/v1_entities_investor_profile_joint_spec.rb +7 -1
  146. data/spec/models/v1_entities_investor_profile_owner_spec.rb +1 -1
  147. data/spec/models/v1_entities_investor_profile_trust_spec.rb +7 -1
  148. data/spec/models/v1_entities_investor_profiles_spec.rb +1 -1
  149. data/spec/models/v1_entities_investor_spec.rb +1 -1
  150. data/spec/models/v1_entities_investor_user_spec.rb +1 -1
  151. data/spec/models/v1_entities_investors_spec.rb +1 -1
  152. data/spec/models/v1_entities_shareholder_spec.rb +46 -0
  153. data/spec/models/v1_entities_shareholders_spec.rb +34 -0
  154. data/spec/models/v1_entities_shareholders_tags_spec.rb +40 -0
  155. data/spec/models/v1_entities_subscription_agreement_spec.rb +1 -1
  156. data/spec/models/v1_entities_webhooks_deal_spec.rb +1 -1
  157. data/spec/models/v1_entities_webhooks_security_token_spec.rb +1 -1
  158. data/spec/models/v1_entities_webhooks_subscription_deal_spec.rb +1 -1
  159. data/spec/models/v1_entities_webhooks_subscription_deals_spec.rb +1 -1
  160. data/spec/models/v1_entities_webhooks_subscription_spec.rb +1 -1
  161. data/spec/spec_helper.rb +1 -1
  162. metadata +71 -47
@@ -3,7 +3,7 @@
3
3
 
4
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
- The version of the OpenAPI document: 1.0.0
6
+ The version of the OpenAPI document: 1.75.0
7
7
 
8
8
  Generated by: https://openapi-generator.tech
9
9
  OpenAPI Generator version: 7.0.0-SNAPSHOT
@@ -18,9 +18,12 @@ module DealMakerAPI
18
18
  # User email which is associated with investor profile (required).
19
19
  attr_accessor :email
20
20
 
21
- # The accredited investor information.
21
+ # The United States accredited investor information.
22
22
  attr_accessor :us_accredited_category
23
23
 
24
+ # The Canadian accredited investor information.
25
+ attr_accessor :ca_accredited_investor
26
+
24
27
  # The name of the trust (required).
25
28
  attr_accessor :name
26
29
 
@@ -117,6 +120,7 @@ module DealMakerAPI
117
120
  {
118
121
  :'email' => :'email',
119
122
  :'us_accredited_category' => :'us_accredited_category',
123
+ :'ca_accredited_investor' => :'ca_accredited_investor',
120
124
  :'name' => :'name',
121
125
  :'date' => :'date',
122
126
  :'country' => :'country',
@@ -153,6 +157,7 @@ module DealMakerAPI
153
157
  {
154
158
  :'email' => :'String',
155
159
  :'us_accredited_category' => :'String',
160
+ :'ca_accredited_investor' => :'String',
156
161
  :'name' => :'String',
157
162
  :'date' => :'String',
158
163
  :'country' => :'String',
@@ -208,6 +213,10 @@ module DealMakerAPI
208
213
  self.us_accredited_category = attributes[:'us_accredited_category']
209
214
  end
210
215
 
216
+ if attributes.key?(:'ca_accredited_investor')
217
+ self.ca_accredited_investor = attributes[:'ca_accredited_investor']
218
+ end
219
+
211
220
  if attributes.key?(:'name')
212
221
  self.name = attributes[:'name']
213
222
  end
@@ -340,6 +349,8 @@ module DealMakerAPI
340
349
  return false if @email.nil?
341
350
  us_accredited_category_validator = EnumAttributeValidator.new('String', ["entity_owned_by_accredited_investors", "broker_or_dealer", "assets_trust", "not_accredited"])
342
351
  return false unless us_accredited_category_validator.valid?(@us_accredited_category)
352
+ ca_accredited_investor_validator = EnumAttributeValidator.new('String', ["p", "w"])
353
+ return false unless ca_accredited_investor_validator.valid?(@ca_accredited_investor)
343
354
  true
344
355
  end
345
356
 
@@ -353,6 +364,16 @@ module DealMakerAPI
353
364
  @us_accredited_category = us_accredited_category
354
365
  end
355
366
 
367
+ # Custom attribute writer method checking allowed values (enum).
368
+ # @param [Object] ca_accredited_investor Object to be assigned
369
+ def ca_accredited_investor=(ca_accredited_investor)
370
+ validator = EnumAttributeValidator.new('String', ["p", "w"])
371
+ unless validator.valid?(ca_accredited_investor)
372
+ fail ArgumentError, "invalid value for \"ca_accredited_investor\", must be one of #{validator.allowable_values}."
373
+ end
374
+ @ca_accredited_investor = ca_accredited_investor
375
+ end
376
+
356
377
  # Checks equality by comparing each attribute.
357
378
  # @param [Object] Object to be compared
358
379
  def ==(o)
@@ -360,6 +381,7 @@ module DealMakerAPI
360
381
  self.class == o.class &&
361
382
  email == o.email &&
362
383
  us_accredited_category == o.us_accredited_category &&
384
+ ca_accredited_investor == o.ca_accredited_investor &&
363
385
  name == o.name &&
364
386
  date == o.date &&
365
387
  country == o.country &&
@@ -394,7 +416,7 @@ module DealMakerAPI
394
416
  # Calculates hash code according to all attributes.
395
417
  # @return [Integer] Hash code
396
418
  def hash
397
- [email, us_accredited_category, name, date, country, street_address, unit2, city, region, postal_code, phone_number, income, net_worth, reg_cf_prior_offerings_amount, trustees_first_name, trustees_last_name, trustees_suffix, trustees_country, trustees_street_address, trustees_unit_2, trustees_city, trustees_region, trustees_postal_code, trustees_date_of_birth, trustees_taxpayer_id].hash
419
+ [email, us_accredited_category, ca_accredited_investor, name, date, country, street_address, unit2, city, region, postal_code, phone_number, income, net_worth, reg_cf_prior_offerings_amount, trustees_first_name, trustees_last_name, trustees_suffix, trustees_country, trustees_street_address, trustees_unit_2, trustees_city, trustees_region, trustees_postal_code, trustees_date_of_birth, trustees_taxpayer_id].hash
398
420
  end
399
421
 
400
422
  # Builds the object from hash
@@ -0,0 +1,273 @@
1
+ =begin
2
+ #DealMaker API
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. 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
+
6
+ The version of the OpenAPI document: 1.75.0
7
+
8
+ Generated by: https://openapi-generator.tech
9
+ OpenAPI Generator version: 7.0.0-SNAPSHOT
10
+
11
+ =end
12
+
13
+ require 'date'
14
+ require 'time'
15
+
16
+ module DealMakerAPI
17
+ class EditInvestorTagsRequest
18
+ # The list of tags.
19
+ attr_accessor :tags
20
+
21
+ # The type of request for the tag(s): \"append\" or \"replace\".
22
+ attr_accessor :mode
23
+
24
+ class EnumAttributeValidator
25
+ attr_reader :datatype
26
+ attr_reader :allowable_values
27
+
28
+ def initialize(datatype, allowable_values)
29
+ @allowable_values = allowable_values.map do |value|
30
+ case datatype.to_s
31
+ when /Integer/i
32
+ value.to_i
33
+ when /Float/i
34
+ value.to_f
35
+ else
36
+ value
37
+ end
38
+ end
39
+ end
40
+
41
+ def valid?(value)
42
+ !value || allowable_values.include?(value)
43
+ end
44
+ end
45
+
46
+ # Attribute mapping from ruby-style variable name to JSON key.
47
+ def self.attribute_map
48
+ {
49
+ :'tags' => :'tags',
50
+ :'mode' => :'mode'
51
+ }
52
+ end
53
+
54
+ # Returns all the JSON keys this model knows about
55
+ def self.acceptable_attributes
56
+ attribute_map.values
57
+ end
58
+
59
+ # Attribute type mapping.
60
+ def self.openapi_types
61
+ {
62
+ :'tags' => :'Array<String>',
63
+ :'mode' => :'String'
64
+ }
65
+ end
66
+
67
+ # List of attributes with nullable: true
68
+ def self.openapi_nullable
69
+ Set.new([
70
+ ])
71
+ end
72
+
73
+ # Initializes the object
74
+ # @param [Hash] attributes Model attributes in the form of hash
75
+ def initialize(attributes = {})
76
+ if (!attributes.is_a?(Hash))
77
+ fail ArgumentError, "The input argument (attributes) must be a hash in `DealMakerAPI::EditInvestorTagsRequest` initialize method"
78
+ end
79
+
80
+ # check to see if the attribute exists and convert string to symbol for hash key
81
+ attributes = attributes.each_with_object({}) { |(k, v), h|
82
+ if (!self.class.attribute_map.key?(k.to_sym))
83
+ fail ArgumentError, "`#{k}` is not a valid attribute in `DealMakerAPI::EditInvestorTagsRequest`. Please check the name to make sure it's valid. List of attributes: " + self.class.attribute_map.keys.inspect
84
+ end
85
+ h[k.to_sym] = v
86
+ }
87
+
88
+ if attributes.key?(:'tags')
89
+ if (value = attributes[:'tags']).is_a?(Array)
90
+ self.tags = value
91
+ end
92
+ end
93
+
94
+ if attributes.key?(:'mode')
95
+ self.mode = attributes[:'mode']
96
+ else
97
+ self.mode = 'append'
98
+ end
99
+ end
100
+
101
+ # Show invalid properties with the reasons. Usually used together with valid?
102
+ # @return Array for valid properties with the reasons
103
+ def list_invalid_properties
104
+ invalid_properties = Array.new
105
+ if @tags.nil?
106
+ invalid_properties.push('invalid value for "tags", tags cannot be nil.')
107
+ end
108
+
109
+ invalid_properties
110
+ end
111
+
112
+ # Check to see if the all the properties in the model are valid
113
+ # @return true if the model is valid
114
+ def valid?
115
+ return false if @tags.nil?
116
+ mode_validator = EnumAttributeValidator.new('String', ["append", "replace"])
117
+ return false unless mode_validator.valid?(@mode)
118
+ true
119
+ end
120
+
121
+ # Custom attribute writer method checking allowed values (enum).
122
+ # @param [Object] mode Object to be assigned
123
+ def mode=(mode)
124
+ validator = EnumAttributeValidator.new('String', ["append", "replace"])
125
+ unless validator.valid?(mode)
126
+ fail ArgumentError, "invalid value for \"mode\", must be one of #{validator.allowable_values}."
127
+ end
128
+ @mode = mode
129
+ end
130
+
131
+ # Checks equality by comparing each attribute.
132
+ # @param [Object] Object to be compared
133
+ def ==(o)
134
+ return true if self.equal?(o)
135
+ self.class == o.class &&
136
+ tags == o.tags &&
137
+ mode == o.mode
138
+ end
139
+
140
+ # @see the `==` method
141
+ # @param [Object] Object to be compared
142
+ def eql?(o)
143
+ self == o
144
+ end
145
+
146
+ # Calculates hash code according to all attributes.
147
+ # @return [Integer] Hash code
148
+ def hash
149
+ [tags, mode].hash
150
+ end
151
+
152
+ # Builds the object from hash
153
+ # @param [Hash] attributes Model attributes in the form of hash
154
+ # @return [Object] Returns the model itself
155
+ def self.build_from_hash(attributes)
156
+ new.build_from_hash(attributes)
157
+ end
158
+
159
+ # Builds the object from hash
160
+ # @param [Hash] attributes Model attributes in the form of hash
161
+ # @return [Object] Returns the model itself
162
+ def build_from_hash(attributes)
163
+ return nil unless attributes.is_a?(Hash)
164
+ attributes = attributes.transform_keys(&:to_sym)
165
+ self.class.openapi_types.each_pair do |key, type|
166
+ if attributes[self.class.attribute_map[key]].nil? && self.class.openapi_nullable.include?(key)
167
+ self.send("#{key}=", nil)
168
+ elsif type =~ /\AArray<(.*)>/i
169
+ # check to ensure the input is an array given that the attribute
170
+ # is documented as an array but the input is not
171
+ if attributes[self.class.attribute_map[key]].is_a?(Array)
172
+ self.send("#{key}=", attributes[self.class.attribute_map[key]].map { |v| _deserialize($1, v) })
173
+ end
174
+ elsif !attributes[self.class.attribute_map[key]].nil?
175
+ self.send("#{key}=", _deserialize(type, attributes[self.class.attribute_map[key]]))
176
+ end
177
+ end
178
+
179
+ self
180
+ end
181
+
182
+ # Deserializes the data based on type
183
+ # @param string type Data type
184
+ # @param string value Value to be deserialized
185
+ # @return [Object] Deserialized data
186
+ def _deserialize(type, value)
187
+ case type.to_sym
188
+ when :Time
189
+ Time.parse(value)
190
+ when :Date
191
+ Date.parse(value)
192
+ when :String
193
+ value.to_s
194
+ when :Integer
195
+ value.to_i
196
+ when :Float
197
+ value.to_f
198
+ when :Boolean
199
+ if value.to_s =~ /\A(true|t|yes|y|1)\z/i
200
+ true
201
+ else
202
+ false
203
+ end
204
+ when :Object
205
+ # generic object (usually a Hash), return directly
206
+ value
207
+ when /\AArray<(?<inner_type>.+)>\z/
208
+ inner_type = Regexp.last_match[:inner_type]
209
+ value.map { |v| _deserialize(inner_type, v) }
210
+ when /\AHash<(?<k_type>.+?), (?<v_type>.+)>\z/
211
+ k_type = Regexp.last_match[:k_type]
212
+ v_type = Regexp.last_match[:v_type]
213
+ {}.tap do |hash|
214
+ value.each do |k, v|
215
+ hash[_deserialize(k_type, k)] = _deserialize(v_type, v)
216
+ end
217
+ end
218
+ else # model
219
+ # models (e.g. Pet) or oneOf
220
+ klass = DealMakerAPI.const_get(type)
221
+ klass.respond_to?(:openapi_one_of) ? klass.build(value) : klass.build_from_hash(value)
222
+ end
223
+ end
224
+
225
+ # Returns the string representation of the object
226
+ # @return [String] String presentation of the object
227
+ def to_s
228
+ to_hash.to_s
229
+ end
230
+
231
+ # to_body is an alias to to_hash (backward compatibility)
232
+ # @return [Hash] Returns the object in the form of hash
233
+ def to_body
234
+ to_hash
235
+ end
236
+
237
+ # Returns the object in the form of hash
238
+ # @return [Hash] Returns the object in the form of hash
239
+ def to_hash
240
+ hash = {}
241
+ self.class.attribute_map.each_pair do |attr, param|
242
+ value = self.send(attr)
243
+ if value.nil?
244
+ is_nullable = self.class.openapi_nullable.include?(attr)
245
+ next if !is_nullable || (is_nullable && !instance_variable_defined?(:"@#{attr}"))
246
+ end
247
+
248
+ hash[param] = _to_hash(value)
249
+ end
250
+ hash
251
+ end
252
+
253
+ # Outputs non-array value in the form of hash
254
+ # For object, use to_hash. Otherwise, just return the value
255
+ # @param [Object] value Any valid value
256
+ # @return [Hash] Returns the value in the form of hash
257
+ def _to_hash(value)
258
+ if value.is_a?(Array)
259
+ value.compact.map { |v| _to_hash(v) }
260
+ elsif value.is_a?(Hash)
261
+ {}.tap do |hash|
262
+ value.each { |k, v| hash[k] = _to_hash(v) }
263
+ end
264
+ elsif value.respond_to? :to_hash
265
+ value.to_hash
266
+ else
267
+ value
268
+ end
269
+ end
270
+
271
+ end
272
+
273
+ end
@@ -3,7 +3,7 @@
3
3
 
4
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
- The version of the OpenAPI document: 1.0.0
6
+ The version of the OpenAPI document: 1.75.0
7
7
 
8
8
  Generated by: https://openapi-generator.tech
9
9
  OpenAPI Generator version: 7.0.0-SNAPSHOT
@@ -15,9 +15,12 @@ require 'time'
15
15
 
16
16
  module DealMakerAPI
17
17
  class PatchCorporationProfileRequest
18
- # The accredited investor information.
18
+ # The United States accredited investor information.
19
19
  attr_accessor :us_accredited_category
20
20
 
21
+ # The Canadian accredited investor information.
22
+ attr_accessor :ca_accredited_investor
23
+
21
24
  # Corporation name.
22
25
  attr_accessor :name
23
26
 
@@ -113,6 +116,7 @@ module DealMakerAPI
113
116
  def self.attribute_map
114
117
  {
115
118
  :'us_accredited_category' => :'us_accredited_category',
119
+ :'ca_accredited_investor' => :'ca_accredited_investor',
116
120
  :'name' => :'name',
117
121
  :'country' => :'country',
118
122
  :'street_address' => :'street_address',
@@ -148,6 +152,7 @@ module DealMakerAPI
148
152
  def self.openapi_types
149
153
  {
150
154
  :'us_accredited_category' => :'String',
155
+ :'ca_accredited_investor' => :'String',
151
156
  :'name' => :'String',
152
157
  :'country' => :'String',
153
158
  :'street_address' => :'String',
@@ -199,6 +204,10 @@ module DealMakerAPI
199
204
  self.us_accredited_category = attributes[:'us_accredited_category']
200
205
  end
201
206
 
207
+ if attributes.key?(:'ca_accredited_investor')
208
+ self.ca_accredited_investor = attributes[:'ca_accredited_investor']
209
+ end
210
+
202
211
  if attributes.key?(:'name')
203
212
  self.name = attributes[:'name']
204
213
  end
@@ -304,6 +313,8 @@ module DealMakerAPI
304
313
  def valid?
305
314
  us_accredited_category_validator = 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"])
306
315
  return false unless us_accredited_category_validator.valid?(@us_accredited_category)
316
+ ca_accredited_investor_validator = EnumAttributeValidator.new('String', ["a", "b", "c", "d", "f", "g", "h", "i", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "x"])
317
+ return false unless ca_accredited_investor_validator.valid?(@ca_accredited_investor)
307
318
  true
308
319
  end
309
320
 
@@ -317,12 +328,23 @@ module DealMakerAPI
317
328
  @us_accredited_category = us_accredited_category
318
329
  end
319
330
 
331
+ # Custom attribute writer method checking allowed values (enum).
332
+ # @param [Object] ca_accredited_investor Object to be assigned
333
+ def ca_accredited_investor=(ca_accredited_investor)
334
+ validator = EnumAttributeValidator.new('String', ["a", "b", "c", "d", "f", "g", "h", "i", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "x"])
335
+ unless validator.valid?(ca_accredited_investor)
336
+ fail ArgumentError, "invalid value for \"ca_accredited_investor\", must be one of #{validator.allowable_values}."
337
+ end
338
+ @ca_accredited_investor = ca_accredited_investor
339
+ end
340
+
320
341
  # Checks equality by comparing each attribute.
321
342
  # @param [Object] Object to be compared
322
343
  def ==(o)
323
344
  return true if self.equal?(o)
324
345
  self.class == o.class &&
325
346
  us_accredited_category == o.us_accredited_category &&
347
+ ca_accredited_investor == o.ca_accredited_investor &&
326
348
  name == o.name &&
327
349
  country == o.country &&
328
350
  street_address == o.street_address &&
@@ -357,7 +379,7 @@ module DealMakerAPI
357
379
  # Calculates hash code according to all attributes.
358
380
  # @return [Integer] Hash code
359
381
  def hash
360
- [us_accredited_category, name, country, street_address, unit2, city, region, postal_code, business_number, phone_number, income, net_worth, reg_cf_prior_offerings_amount, signing_officer_first_name, signing_officer_last_name, signing_officer_suffix, signing_officer_country, signing_officer_street_address, signing_officer_unit2, signing_officer_city, signing_officer_region, signing_officer_postal_code, signing_officer_date_of_birth, signing_officer_taxpayer_id].hash
382
+ [us_accredited_category, ca_accredited_investor, name, country, street_address, unit2, city, region, postal_code, business_number, phone_number, income, net_worth, reg_cf_prior_offerings_amount, signing_officer_first_name, signing_officer_last_name, signing_officer_suffix, signing_officer_country, signing_officer_street_address, signing_officer_unit2, signing_officer_city, signing_officer_region, signing_officer_postal_code, signing_officer_date_of_birth, signing_officer_taxpayer_id].hash
361
383
  end
362
384
 
363
385
  # Builds the object from hash