DealMakerAPI 0.95.3 → 0.95.4

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: de52da5b2bfe97f4c0dbf9d74125c02f75143804a270184f5e84c19fe0cee21e
4
- data.tar.gz: 5e56ecd5ff2d5c026ea231244ad77e79744d38468541de51f2377a7ac42b35d6
3
+ metadata.gz: 03cec8f80bb0fc1d250d110fbe08c46331f1b9cd2e21bbd34f22ddb3497477c6
4
+ data.tar.gz: e08c76e894beff7d124257aadd8a8d4eb6d396179af85899d29d3095a62757ca
5
5
  SHA512:
6
- metadata.gz: 3b0adca6d3b51a3e074d68b618d7a2b39bde8128717b16b5d9220b7a302b0d6240c63a90805731c2298f2c8f2fc8d876b52f647e13b61771aba9728f1c118db1
7
- data.tar.gz: f9b508d283f857f01a639687588ca840d8d45291e358cb642e1f4f3999794453034aecee55738aff4fa1a02e91d4efd28fcd5f3ddea24b344e052b06f74922e2
6
+ metadata.gz: a1f583013255e16bc6eb3e8867e6bee811e7602286e0018056be6bf0cb25f7164dcdd70af1f435d33541b171ee3ee178f633af3a2e9842244ccb6c33ad6695be
7
+ data.tar.gz: 4c89424bf00913fd0341ec252db73643bef7153f085fc8e2216f7b2eab37669af7e20481636d3486f38e6b2a18383a08344ef2ccd762cfa5d58af37b613a2569
data/README.md CHANGED
@@ -338,7 +338,7 @@ Given the high number of updates our platform performs on any investor, we’ve
338
338
  This SDK is automatically generated by the [OpenAPI Generator](https://openapi-generator.tech) project:
339
339
 
340
340
  - API version: 1.75.0
341
- - Package version: 0.95.3
341
+ - Package version: 0.95.4
342
342
  - Build package: org.openapitools.codegen.languages.RubyClientCodegen
343
343
 
344
344
  ## Installation
@@ -354,16 +354,16 @@ gem build DealMakerAPI.gemspec
354
354
  Then either install the gem locally:
355
355
 
356
356
  ```shell
357
- gem install ./DealMakerAPI-0.95.3.gem
357
+ gem install ./DealMakerAPI-0.95.4.gem
358
358
  ```
359
359
 
360
- (for development, run `gem install --dev ./DealMakerAPI-0.95.3.gem` to install the development dependencies)
360
+ (for development, run `gem install --dev ./DealMakerAPI-0.95.4.gem` to install the development dependencies)
361
361
 
362
362
  or publish the gem to a gem hosting service, e.g. [RubyGems](https://rubygems.org/).
363
363
 
364
364
  Finally add this to the Gemfile:
365
365
 
366
- gem 'DealMakerAPI', '~> 0.95.3'
366
+ gem 'DealMakerAPI', '~> 0.95.4'
367
367
 
368
368
  ### Install from Git
369
369
 
@@ -424,6 +424,7 @@ Class | Method | HTTP request | Description
424
424
  *DealMakerAPI::CompanyApi* | [**get_user_accessible_companies**](docs/CompanyApi.md#get_user_accessible_companies) | **GET** /users/accessible_companies | Get list of all Companies accessible by the user
425
425
  *DealMakerAPI::CompanyApi* | [**send_portal_invite**](docs/CompanyApi.md#send_portal_invite) | **POST** /companies/{id}/shareholders/{shareholder_id}/send_portal_invite | Send portal invite to shareholder
426
426
  *DealMakerAPI::CountryApi* | [**get_country_states**](docs/CountryApi.md#get_country_states) | **GET** /country/states | Returns a list of all valid countries and it states
427
+ *DealMakerAPI::CustomEmailsApi* | [**get_access_token**](docs/CustomEmailsApi.md#get_access_token) | **POST** /custom_emails/get_access_token | Generate authorization token information for initializing Beefree editor
427
428
  *DealMakerAPI::DealApi* | [**create_deal_setup**](docs/DealApi.md#create_deal_setup) | **POST** /deal_setups | Create deal setup
428
429
  *DealMakerAPI::DealApi* | [**get_deal**](docs/DealApi.md#get_deal) | **GET** /deals/{id} | Get deal by Deal ID
429
430
  *DealMakerAPI::DealApi* | [**get_deal_incentive_plan**](docs/DealApi.md#get_deal_incentive_plan) | **GET** /deals/{id}/incentive_plan | Get incentive plan by deal id
@@ -493,6 +494,7 @@ Class | Method | HTTP request | Description
493
494
  - [DealMakerAPI::CreateShareholderActionRequest](docs/CreateShareholderActionRequest.md)
494
495
  - [DealMakerAPI::EditInvestorTagsRequest](docs/EditInvestorTagsRequest.md)
495
496
  - [DealMakerAPI::GenerateUrlRequest](docs/GenerateUrlRequest.md)
497
+ - [DealMakerAPI::GetAccessTokenRequest](docs/GetAccessTokenRequest.md)
496
498
  - [DealMakerAPI::PatchDealIncentivePlanRequest](docs/PatchDealIncentivePlanRequest.md)
497
499
  - [DealMakerAPI::PatchInvestorProfilesCorporations](docs/PatchInvestorProfilesCorporations.md)
498
500
  - [DealMakerAPI::PatchInvestorProfilesCorporationsBeneficialOwnersInner](docs/PatchInvestorProfilesCorporationsBeneficialOwnersInner.md)
@@ -521,6 +523,7 @@ Class | Method | HTTP request | Description
521
523
  - [DealMakerAPI::V1EntitiesAddresses](docs/V1EntitiesAddresses.md)
522
524
  - [DealMakerAPI::V1EntitiesAttachment](docs/V1EntitiesAttachment.md)
523
525
  - [DealMakerAPI::V1EntitiesBackgroundCheckSearch](docs/V1EntitiesBackgroundCheckSearch.md)
526
+ - [DealMakerAPI::V1EntitiesBeefreeAccessToken](docs/V1EntitiesBeefreeAccessToken.md)
524
527
  - [DealMakerAPI::V1EntitiesBulkUpload](docs/V1EntitiesBulkUpload.md)
525
528
  - [DealMakerAPI::V1EntitiesBulkUploadDetail](docs/V1EntitiesBulkUploadDetail.md)
526
529
  - [DealMakerAPI::V1EntitiesBulkUploadDetails](docs/V1EntitiesBulkUploadDetails.md)
@@ -0,0 +1,74 @@
1
+ # DealMakerAPI::CustomEmailsApi
2
+
3
+ All URIs are relative to *http://api.dealmaker.tech*
4
+
5
+ | Method | HTTP request | Description |
6
+ | ------ | ------------ | ----------- |
7
+ | [**get_access_token**](CustomEmailsApi.md#get_access_token) | **POST** /custom_emails/get_access_token | Generate authorization token information for initializing Beefree editor |
8
+
9
+
10
+ ## get_access_token
11
+
12
+ > <V1EntitiesBeefreeAccessToken> get_access_token(get_access_token_request)
13
+
14
+ Generate authorization token information for initializing Beefree editor
15
+
16
+ Generate authorization token information
17
+
18
+ ### Examples
19
+
20
+ ```ruby
21
+ require 'time'
22
+ require 'DealMakerAPI'
23
+ # setup authorization
24
+ DealMakerAPI.configure do |config|end
25
+
26
+ api_instance = DealMakerAPI::CustomEmailsApi.new
27
+ get_access_token_request = DealMakerAPI::GetAccessTokenRequest.new({user_id: 37}) # GetAccessTokenRequest |
28
+
29
+ begin
30
+ # Generate authorization token information for initializing Beefree editor
31
+ result = api_instance.get_access_token(get_access_token_request)
32
+ p result
33
+ rescue DealMakerAPI::ApiError => e
34
+ puts "Error when calling CustomEmailsApi->get_access_token: #{e}"
35
+ end
36
+ ```
37
+
38
+ #### Using the get_access_token_with_http_info variant
39
+
40
+ This returns an Array which contains the response data, status code and headers.
41
+
42
+ > <Array(<V1EntitiesBeefreeAccessToken>, Integer, Hash)> get_access_token_with_http_info(get_access_token_request)
43
+
44
+ ```ruby
45
+ begin
46
+ # Generate authorization token information for initializing Beefree editor
47
+ data, status_code, headers = api_instance.get_access_token_with_http_info(get_access_token_request)
48
+ p status_code # => 2xx
49
+ p headers # => { ... }
50
+ p data # => <V1EntitiesBeefreeAccessToken>
51
+ rescue DealMakerAPI::ApiError => e
52
+ puts "Error when calling CustomEmailsApi->get_access_token_with_http_info: #{e}"
53
+ end
54
+ ```
55
+
56
+ ### Parameters
57
+
58
+ | Name | Type | Description | Notes |
59
+ | ---- | ---- | ----------- | ----- |
60
+ | **get_access_token_request** | [**GetAccessTokenRequest**](GetAccessTokenRequest.md) | | |
61
+
62
+ ### Return type
63
+
64
+ [**V1EntitiesBeefreeAccessToken**](V1EntitiesBeefreeAccessToken.md)
65
+
66
+ ### Authorization
67
+
68
+ No authorization required
69
+
70
+ ### HTTP request headers
71
+
72
+ - **Content-Type**: application/json
73
+ - **Accept**: application/json
74
+
@@ -0,0 +1,18 @@
1
+ # DealMakerAPI::GetAccessTokenRequest
2
+
3
+ ## Properties
4
+
5
+ | Name | Type | Description | Notes |
6
+ | ---- | ---- | ----------- | ----- |
7
+ | **user_id** | **Integer** | The user ID | |
8
+
9
+ ## Example
10
+
11
+ ```ruby
12
+ require 'DealMakerAPI'
13
+
14
+ instance = DealMakerAPI::GetAccessTokenRequest.new(
15
+ user_id: null
16
+ )
17
+ ```
18
+
@@ -0,0 +1,20 @@
1
+ # DealMakerAPI::V1EntitiesBeefreeAccessToken
2
+
3
+ ## Properties
4
+
5
+ | Name | Type | Description | Notes |
6
+ | ---- | ---- | ----------- | ----- |
7
+ | **access_token** | **String** | The access token for initializing beefree builders intances. | [optional] |
8
+ | **expires_in** | **Integer** | The expires in field. | [optional] |
9
+
10
+ ## Example
11
+
12
+ ```ruby
13
+ require 'DealMakerAPI'
14
+
15
+ instance = DealMakerAPI::V1EntitiesBeefreeAccessToken.new(
16
+ access_token: null,
17
+ expires_in: null
18
+ )
19
+ ```
20
+
@@ -0,0 +1,90 @@
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.3.0-SNAPSHOT
10
+
11
+ =end
12
+
13
+ require 'cgi'
14
+
15
+ module DealMakerAPI
16
+ class CustomEmailsApi
17
+ attr_accessor :api_client
18
+
19
+ def initialize(api_client = ApiClient.default)
20
+ @api_client = api_client
21
+ end
22
+ # Generate authorization token information for initializing Beefree editor
23
+ # Generate authorization token information
24
+ # @param get_access_token_request [GetAccessTokenRequest]
25
+ # @param [Hash] opts the optional parameters
26
+ # @return [V1EntitiesBeefreeAccessToken]
27
+ def get_access_token(get_access_token_request, opts = {})
28
+ data, _status_code, _headers = get_access_token_with_http_info(get_access_token_request, opts)
29
+ data
30
+ end
31
+
32
+ # Generate authorization token information for initializing Beefree editor
33
+ # Generate authorization token information
34
+ # @param get_access_token_request [GetAccessTokenRequest]
35
+ # @param [Hash] opts the optional parameters
36
+ # @return [Array<(V1EntitiesBeefreeAccessToken, Integer, Hash)>] V1EntitiesBeefreeAccessToken data, response status code and response headers
37
+ def get_access_token_with_http_info(get_access_token_request, opts = {})
38
+ if @api_client.config.debugging
39
+ @api_client.config.logger.debug 'Calling API: CustomEmailsApi.get_access_token ...'
40
+ end
41
+ # verify the required parameter 'get_access_token_request' is set
42
+ if @api_client.config.client_side_validation && get_access_token_request.nil?
43
+ fail ArgumentError, "Missing the required parameter 'get_access_token_request' when calling CustomEmailsApi.get_access_token"
44
+ end
45
+ # resource path
46
+ local_var_path = '/custom_emails/get_access_token'
47
+
48
+ # query parameters
49
+ query_params = opts[:query_params] || {}
50
+
51
+ # header parameters
52
+ header_params = opts[:header_params] || {}
53
+ # HTTP header 'Accept' (if needed)
54
+ header_params['Accept'] = @api_client.select_header_accept(['application/json'])
55
+ # HTTP header 'Content-Type'
56
+ content_type = @api_client.select_header_content_type(['application/json'])
57
+ if !content_type.nil?
58
+ header_params['Content-Type'] = content_type
59
+ end
60
+
61
+ # form parameters
62
+ form_params = opts[:form_params] || {}
63
+
64
+ # http body (model)
65
+ post_body = opts[:debug_body] || @api_client.object_to_http_body(get_access_token_request)
66
+
67
+ # return_type
68
+ return_type = opts[:debug_return_type] || 'V1EntitiesBeefreeAccessToken'
69
+
70
+ # auth_names
71
+ auth_names = opts[:debug_auth_names] || []
72
+
73
+ new_options = opts.merge(
74
+ :operation => :"CustomEmailsApi.get_access_token",
75
+ :header_params => header_params,
76
+ :query_params => query_params,
77
+ :form_params => form_params,
78
+ :body => post_body,
79
+ :auth_names => auth_names,
80
+ :return_type => return_type
81
+ )
82
+
83
+ data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
84
+ if @api_client.config.debugging
85
+ @api_client.config.logger.debug "API called: CustomEmailsApi#get_access_token\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
86
+ end
87
+ return data, status_code, headers
88
+ end
89
+ end
90
+ end
@@ -0,0 +1,222 @@
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.3.0-SNAPSHOT
10
+
11
+ =end
12
+
13
+ require 'date'
14
+ require 'time'
15
+
16
+ module DealMakerAPI
17
+ class GetAccessTokenRequest
18
+ # The user ID
19
+ attr_accessor :user_id
20
+
21
+ # Attribute mapping from ruby-style variable name to JSON key.
22
+ def self.attribute_map
23
+ {
24
+ :'user_id' => :'user_id'
25
+ }
26
+ end
27
+
28
+ # Returns all the JSON keys this model knows about
29
+ def self.acceptable_attributes
30
+ attribute_map.values
31
+ end
32
+
33
+ # Attribute type mapping.
34
+ def self.openapi_types
35
+ {
36
+ :'user_id' => :'Integer'
37
+ }
38
+ end
39
+
40
+ # List of attributes with nullable: true
41
+ def self.openapi_nullable
42
+ Set.new([
43
+ ])
44
+ end
45
+
46
+ # Initializes the object
47
+ # @param [Hash] attributes Model attributes in the form of hash
48
+ def initialize(attributes = {})
49
+ if (!attributes.is_a?(Hash))
50
+ fail ArgumentError, "The input argument (attributes) must be a hash in `DealMakerAPI::GetAccessTokenRequest` initialize method"
51
+ end
52
+
53
+ # check to see if the attribute exists and convert string to symbol for hash key
54
+ attributes = attributes.each_with_object({}) { |(k, v), h|
55
+ if (!self.class.attribute_map.key?(k.to_sym))
56
+ fail ArgumentError, "`#{k}` is not a valid attribute in `DealMakerAPI::GetAccessTokenRequest`. Please check the name to make sure it's valid. List of attributes: " + self.class.attribute_map.keys.inspect
57
+ end
58
+ h[k.to_sym] = v
59
+ }
60
+
61
+ if attributes.key?(:'user_id')
62
+ self.user_id = attributes[:'user_id']
63
+ else
64
+ self.user_id = nil
65
+ end
66
+ end
67
+
68
+ # Show invalid properties with the reasons. Usually used together with valid?
69
+ # @return Array for valid properties with the reasons
70
+ def list_invalid_properties
71
+ warn '[DEPRECATED] the `list_invalid_properties` method is obsolete'
72
+ invalid_properties = Array.new
73
+ if @user_id.nil?
74
+ invalid_properties.push('invalid value for "user_id", user_id cannot be nil.')
75
+ end
76
+
77
+ invalid_properties
78
+ end
79
+
80
+ # Check to see if the all the properties in the model are valid
81
+ # @return true if the model is valid
82
+ def valid?
83
+ warn '[DEPRECATED] the `valid?` method is obsolete'
84
+ return false if @user_id.nil?
85
+ true
86
+ end
87
+
88
+ # Checks equality by comparing each attribute.
89
+ # @param [Object] Object to be compared
90
+ def ==(o)
91
+ return true if self.equal?(o)
92
+ self.class == o.class &&
93
+ user_id == o.user_id
94
+ end
95
+
96
+ # @see the `==` method
97
+ # @param [Object] Object to be compared
98
+ def eql?(o)
99
+ self == o
100
+ end
101
+
102
+ # Calculates hash code according to all attributes.
103
+ # @return [Integer] Hash code
104
+ def hash
105
+ [user_id].hash
106
+ end
107
+
108
+ # Builds the object from hash
109
+ # @param [Hash] attributes Model attributes in the form of hash
110
+ # @return [Object] Returns the model itself
111
+ def self.build_from_hash(attributes)
112
+ return nil unless attributes.is_a?(Hash)
113
+ attributes = attributes.transform_keys(&:to_sym)
114
+ transformed_hash = {}
115
+ openapi_types.each_pair do |key, type|
116
+ if attributes.key?(attribute_map[key]) && attributes[attribute_map[key]].nil?
117
+ transformed_hash["#{key}"] = nil
118
+ elsif type =~ /\AArray<(.*)>/i
119
+ # check to ensure the input is an array given that the attribute
120
+ # is documented as an array but the input is not
121
+ if attributes[attribute_map[key]].is_a?(Array)
122
+ transformed_hash["#{key}"] = attributes[attribute_map[key]].map { |v| _deserialize($1, v) }
123
+ end
124
+ elsif !attributes[attribute_map[key]].nil?
125
+ transformed_hash["#{key}"] = _deserialize(type, attributes[attribute_map[key]])
126
+ end
127
+ end
128
+ new(transformed_hash)
129
+ end
130
+
131
+ # Deserializes the data based on type
132
+ # @param string type Data type
133
+ # @param string value Value to be deserialized
134
+ # @return [Object] Deserialized data
135
+ def self._deserialize(type, value)
136
+ case type.to_sym
137
+ when :Time
138
+ Time.parse(value)
139
+ when :Date
140
+ Date.parse(value)
141
+ when :String
142
+ value.to_s
143
+ when :Integer
144
+ value.to_i
145
+ when :Float
146
+ value.to_f
147
+ when :Boolean
148
+ if value.to_s =~ /\A(true|t|yes|y|1)\z/i
149
+ true
150
+ else
151
+ false
152
+ end
153
+ when :Object
154
+ # generic object (usually a Hash), return directly
155
+ value
156
+ when /\AArray<(?<inner_type>.+)>\z/
157
+ inner_type = Regexp.last_match[:inner_type]
158
+ value.map { |v| _deserialize(inner_type, v) }
159
+ when /\AHash<(?<k_type>.+?), (?<v_type>.+)>\z/
160
+ k_type = Regexp.last_match[:k_type]
161
+ v_type = Regexp.last_match[:v_type]
162
+ {}.tap do |hash|
163
+ value.each do |k, v|
164
+ hash[_deserialize(k_type, k)] = _deserialize(v_type, v)
165
+ end
166
+ end
167
+ else # model
168
+ # models (e.g. Pet) or oneOf
169
+ klass = DealMakerAPI.const_get(type)
170
+ klass.respond_to?(:openapi_any_of) || klass.respond_to?(:openapi_one_of) ? klass.build(value) : klass.build_from_hash(value)
171
+ end
172
+ end
173
+
174
+ # Returns the string representation of the object
175
+ # @return [String] String presentation of the object
176
+ def to_s
177
+ to_hash.to_s
178
+ end
179
+
180
+ # to_body is an alias to to_hash (backward compatibility)
181
+ # @return [Hash] Returns the object in the form of hash
182
+ def to_body
183
+ to_hash
184
+ end
185
+
186
+ # Returns the object in the form of hash
187
+ # @return [Hash] Returns the object in the form of hash
188
+ def to_hash
189
+ hash = {}
190
+ self.class.attribute_map.each_pair do |attr, param|
191
+ value = self.send(attr)
192
+ if value.nil?
193
+ is_nullable = self.class.openapi_nullable.include?(attr)
194
+ next if !is_nullable || (is_nullable && !instance_variable_defined?(:"@#{attr}"))
195
+ end
196
+
197
+ hash[param] = _to_hash(value)
198
+ end
199
+ hash
200
+ end
201
+
202
+ # Outputs non-array value in the form of hash
203
+ # For object, use to_hash. Otherwise, just return the value
204
+ # @param [Object] value Any valid value
205
+ # @return [Hash] Returns the value in the form of hash
206
+ def _to_hash(value)
207
+ if value.is_a?(Array)
208
+ value.compact.map { |v| _to_hash(v) }
209
+ elsif value.is_a?(Hash)
210
+ {}.tap do |hash|
211
+ value.each { |k, v| hash[k] = _to_hash(v) }
212
+ end
213
+ elsif value.respond_to? :to_hash
214
+ value.to_hash
215
+ else
216
+ value
217
+ end
218
+ end
219
+
220
+ end
221
+
222
+ end
@@ -0,0 +1,226 @@
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.3.0-SNAPSHOT
10
+
11
+ =end
12
+
13
+ require 'date'
14
+ require 'time'
15
+
16
+ module DealMakerAPI
17
+ # V1_Entities_BeefreeAccessToken model
18
+ class V1EntitiesBeefreeAccessToken
19
+ # The access token for initializing beefree builders intances.
20
+ attr_accessor :access_token
21
+
22
+ # The expires in field.
23
+ attr_accessor :expires_in
24
+
25
+ # Attribute mapping from ruby-style variable name to JSON key.
26
+ def self.attribute_map
27
+ {
28
+ :'access_token' => :'access_token',
29
+ :'expires_in' => :'expires_in'
30
+ }
31
+ end
32
+
33
+ # Returns all the JSON keys this model knows about
34
+ def self.acceptable_attributes
35
+ attribute_map.values
36
+ end
37
+
38
+ # Attribute type mapping.
39
+ def self.openapi_types
40
+ {
41
+ :'access_token' => :'String',
42
+ :'expires_in' => :'Integer'
43
+ }
44
+ end
45
+
46
+ # List of attributes with nullable: true
47
+ def self.openapi_nullable
48
+ Set.new([
49
+ ])
50
+ end
51
+
52
+ # Initializes the object
53
+ # @param [Hash] attributes Model attributes in the form of hash
54
+ def initialize(attributes = {})
55
+ if (!attributes.is_a?(Hash))
56
+ fail ArgumentError, "The input argument (attributes) must be a hash in `DealMakerAPI::V1EntitiesBeefreeAccessToken` initialize method"
57
+ end
58
+
59
+ # check to see if the attribute exists and convert string to symbol for hash key
60
+ attributes = attributes.each_with_object({}) { |(k, v), h|
61
+ if (!self.class.attribute_map.key?(k.to_sym))
62
+ fail ArgumentError, "`#{k}` is not a valid attribute in `DealMakerAPI::V1EntitiesBeefreeAccessToken`. Please check the name to make sure it's valid. List of attributes: " + self.class.attribute_map.keys.inspect
63
+ end
64
+ h[k.to_sym] = v
65
+ }
66
+
67
+ if attributes.key?(:'access_token')
68
+ self.access_token = attributes[:'access_token']
69
+ end
70
+
71
+ if attributes.key?(:'expires_in')
72
+ self.expires_in = attributes[:'expires_in']
73
+ end
74
+ end
75
+
76
+ # Show invalid properties with the reasons. Usually used together with valid?
77
+ # @return Array for valid properties with the reasons
78
+ def list_invalid_properties
79
+ warn '[DEPRECATED] the `list_invalid_properties` method is obsolete'
80
+ invalid_properties = Array.new
81
+ invalid_properties
82
+ end
83
+
84
+ # Check to see if the all the properties in the model are valid
85
+ # @return true if the model is valid
86
+ def valid?
87
+ warn '[DEPRECATED] the `valid?` method is obsolete'
88
+ true
89
+ end
90
+
91
+ # Checks equality by comparing each attribute.
92
+ # @param [Object] Object to be compared
93
+ def ==(o)
94
+ return true if self.equal?(o)
95
+ self.class == o.class &&
96
+ access_token == o.access_token &&
97
+ expires_in == o.expires_in
98
+ end
99
+
100
+ # @see the `==` method
101
+ # @param [Object] Object to be compared
102
+ def eql?(o)
103
+ self == o
104
+ end
105
+
106
+ # Calculates hash code according to all attributes.
107
+ # @return [Integer] Hash code
108
+ def hash
109
+ [access_token, expires_in].hash
110
+ end
111
+
112
+ # Builds the object from hash
113
+ # @param [Hash] attributes Model attributes in the form of hash
114
+ # @return [Object] Returns the model itself
115
+ def self.build_from_hash(attributes)
116
+ return nil unless attributes.is_a?(Hash)
117
+ attributes = attributes.transform_keys(&:to_sym)
118
+ transformed_hash = {}
119
+ openapi_types.each_pair do |key, type|
120
+ if attributes.key?(attribute_map[key]) && attributes[attribute_map[key]].nil?
121
+ transformed_hash["#{key}"] = nil
122
+ elsif type =~ /\AArray<(.*)>/i
123
+ # check to ensure the input is an array given that the attribute
124
+ # is documented as an array but the input is not
125
+ if attributes[attribute_map[key]].is_a?(Array)
126
+ transformed_hash["#{key}"] = attributes[attribute_map[key]].map { |v| _deserialize($1, v) }
127
+ end
128
+ elsif !attributes[attribute_map[key]].nil?
129
+ transformed_hash["#{key}"] = _deserialize(type, attributes[attribute_map[key]])
130
+ end
131
+ end
132
+ new(transformed_hash)
133
+ end
134
+
135
+ # Deserializes the data based on type
136
+ # @param string type Data type
137
+ # @param string value Value to be deserialized
138
+ # @return [Object] Deserialized data
139
+ def self._deserialize(type, value)
140
+ case type.to_sym
141
+ when :Time
142
+ Time.parse(value)
143
+ when :Date
144
+ Date.parse(value)
145
+ when :String
146
+ value.to_s
147
+ when :Integer
148
+ value.to_i
149
+ when :Float
150
+ value.to_f
151
+ when :Boolean
152
+ if value.to_s =~ /\A(true|t|yes|y|1)\z/i
153
+ true
154
+ else
155
+ false
156
+ end
157
+ when :Object
158
+ # generic object (usually a Hash), return directly
159
+ value
160
+ when /\AArray<(?<inner_type>.+)>\z/
161
+ inner_type = Regexp.last_match[:inner_type]
162
+ value.map { |v| _deserialize(inner_type, v) }
163
+ when /\AHash<(?<k_type>.+?), (?<v_type>.+)>\z/
164
+ k_type = Regexp.last_match[:k_type]
165
+ v_type = Regexp.last_match[:v_type]
166
+ {}.tap do |hash|
167
+ value.each do |k, v|
168
+ hash[_deserialize(k_type, k)] = _deserialize(v_type, v)
169
+ end
170
+ end
171
+ else # model
172
+ # models (e.g. Pet) or oneOf
173
+ klass = DealMakerAPI.const_get(type)
174
+ klass.respond_to?(:openapi_any_of) || klass.respond_to?(:openapi_one_of) ? klass.build(value) : klass.build_from_hash(value)
175
+ end
176
+ end
177
+
178
+ # Returns the string representation of the object
179
+ # @return [String] String presentation of the object
180
+ def to_s
181
+ to_hash.to_s
182
+ end
183
+
184
+ # to_body is an alias to to_hash (backward compatibility)
185
+ # @return [Hash] Returns the object in the form of hash
186
+ def to_body
187
+ to_hash
188
+ end
189
+
190
+ # Returns the object in the form of hash
191
+ # @return [Hash] Returns the object in the form of hash
192
+ def to_hash
193
+ hash = {}
194
+ self.class.attribute_map.each_pair do |attr, param|
195
+ value = self.send(attr)
196
+ if value.nil?
197
+ is_nullable = self.class.openapi_nullable.include?(attr)
198
+ next if !is_nullable || (is_nullable && !instance_variable_defined?(:"@#{attr}"))
199
+ end
200
+
201
+ hash[param] = _to_hash(value)
202
+ end
203
+ hash
204
+ end
205
+
206
+ # Outputs non-array value in the form of hash
207
+ # For object, use to_hash. Otherwise, just return the value
208
+ # @param [Object] value Any valid value
209
+ # @return [Hash] Returns the value in the form of hash
210
+ def _to_hash(value)
211
+ if value.is_a?(Array)
212
+ value.compact.map { |v| _to_hash(v) }
213
+ elsif value.is_a?(Hash)
214
+ {}.tap do |hash|
215
+ value.each { |k, v| hash[k] = _to_hash(v) }
216
+ end
217
+ elsif value.respond_to? :to_hash
218
+ value.to_hash
219
+ else
220
+ value
221
+ end
222
+ end
223
+
224
+ end
225
+
226
+ end
@@ -11,5 +11,5 @@ OpenAPI Generator version: 7.3.0-SNAPSHOT
11
11
  =end
12
12
 
13
13
  module DealMakerAPI
14
- VERSION = '0.95.3'
14
+ VERSION = '0.95.4'
15
15
  end
data/lib/DealMakerAPI.rb CHANGED
@@ -27,6 +27,7 @@ require 'DealMakerAPI/models/create_deal_setup_request'
27
27
  require 'DealMakerAPI/models/create_shareholder_action_request'
28
28
  require 'DealMakerAPI/models/edit_investor_tags_request'
29
29
  require 'DealMakerAPI/models/generate_url_request'
30
+ require 'DealMakerAPI/models/get_access_token_request'
30
31
  require 'DealMakerAPI/models/patch_deal_incentive_plan_request'
31
32
  require 'DealMakerAPI/models/patch_investor_profiles_corporations'
32
33
  require 'DealMakerAPI/models/patch_investor_profiles_corporations_beneficial_owners_inner'
@@ -55,6 +56,7 @@ require 'DealMakerAPI/models/v1_entities_address'
55
56
  require 'DealMakerAPI/models/v1_entities_addresses'
56
57
  require 'DealMakerAPI/models/v1_entities_attachment'
57
58
  require 'DealMakerAPI/models/v1_entities_background_check_search'
59
+ require 'DealMakerAPI/models/v1_entities_beefree_access_token'
58
60
  require 'DealMakerAPI/models/v1_entities_bulk_upload'
59
61
  require 'DealMakerAPI/models/v1_entities_bulk_upload_detail'
60
62
  require 'DealMakerAPI/models/v1_entities_bulk_upload_details'
@@ -124,6 +126,7 @@ require 'DealMakerAPI/models/v1_entities_webhooks_subscription_deals'
124
126
  # APIs
125
127
  require 'DealMakerAPI/api/company_api'
126
128
  require 'DealMakerAPI/api/country_api'
129
+ require 'DealMakerAPI/api/custom_emails_api'
127
130
  require 'DealMakerAPI/api/deal_api'
128
131
  require 'DealMakerAPI/api/deals_api'
129
132
  require 'DealMakerAPI/api/default_api'
@@ -0,0 +1,47 @@
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.3.0-SNAPSHOT
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for DealMakerAPI::CustomEmailsApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'CustomEmailsApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = DealMakerAPI::CustomEmailsApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of CustomEmailsApi' do
30
+ it 'should create an instance of CustomEmailsApi' do
31
+ expect(@api_instance).to be_instance_of(DealMakerAPI::CustomEmailsApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for get_access_token
36
+ # Generate authorization token information for initializing Beefree editor
37
+ # Generate authorization token information
38
+ # @param get_access_token_request
39
+ # @param [Hash] opts the optional parameters
40
+ # @return [V1EntitiesBeefreeAccessToken]
41
+ describe 'get_access_token test' do
42
+ it 'should work' do
43
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
44
+ end
45
+ end
46
+
47
+ end
@@ -0,0 +1,36 @@
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.3.0-SNAPSHOT
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+ require 'date'
16
+
17
+ # Unit tests for DealMakerAPI::GetAccessTokenRequest
18
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
19
+ # Please update as you see appropriate
20
+ describe DealMakerAPI::GetAccessTokenRequest do
21
+ let(:instance) { DealMakerAPI::GetAccessTokenRequest.new }
22
+
23
+ describe 'test an instance of GetAccessTokenRequest' do
24
+ it 'should create an instance of GetAccessTokenRequest' do
25
+ # uncomment below to test the instance creation
26
+ #expect(instance).to be_instance_of(DealMakerAPI::GetAccessTokenRequest)
27
+ end
28
+ end
29
+
30
+ describe 'test attribute "user_id"' do
31
+ it 'should work' do
32
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
33
+ end
34
+ end
35
+
36
+ end
@@ -0,0 +1,42 @@
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.3.0-SNAPSHOT
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+ require 'date'
16
+
17
+ # Unit tests for DealMakerAPI::V1EntitiesBeefreeAccessToken
18
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
19
+ # Please update as you see appropriate
20
+ describe DealMakerAPI::V1EntitiesBeefreeAccessToken do
21
+ let(:instance) { DealMakerAPI::V1EntitiesBeefreeAccessToken.new }
22
+
23
+ describe 'test an instance of V1EntitiesBeefreeAccessToken' do
24
+ it 'should create an instance of V1EntitiesBeefreeAccessToken' do
25
+ # uncomment below to test the instance creation
26
+ #expect(instance).to be_instance_of(DealMakerAPI::V1EntitiesBeefreeAccessToken)
27
+ end
28
+ end
29
+
30
+ describe 'test attribute "access_token"' do
31
+ it 'should work' do
32
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
33
+ end
34
+ end
35
+
36
+ describe 'test attribute "expires_in"' do
37
+ it 'should work' do
38
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
39
+ end
40
+ end
41
+
42
+ end
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: DealMakerAPI
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.95.3
4
+ version: 0.95.4
5
5
  platform: ruby
6
6
  authors:
7
7
  - DealMaker
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2024-01-25 00:00:00.000000000 Z
11
+ date: 2024-01-29 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: typhoeus
@@ -71,11 +71,13 @@ files:
71
71
  - docs/CreateCompanyRequest.md
72
72
  - docs/CreateDealSetupRequest.md
73
73
  - docs/CreateShareholderActionRequest.md
74
+ - docs/CustomEmailsApi.md
74
75
  - docs/DealApi.md
75
76
  - docs/DealsApi.md
76
77
  - docs/DefaultApi.md
77
78
  - docs/EditInvestorTagsRequest.md
78
79
  - docs/GenerateUrlRequest.md
80
+ - docs/GetAccessTokenRequest.md
79
81
  - docs/IncentivePlanApi.md
80
82
  - docs/InvestorApi.md
81
83
  - docs/InvestorProfileApi.md
@@ -111,6 +113,7 @@ files:
111
113
  - docs/V1EntitiesAddresses.md
112
114
  - docs/V1EntitiesAttachment.md
113
115
  - docs/V1EntitiesBackgroundCheckSearch.md
116
+ - docs/V1EntitiesBeefreeAccessToken.md
114
117
  - docs/V1EntitiesBulkUpload.md
115
118
  - docs/V1EntitiesBulkUploadDetail.md
116
119
  - docs/V1EntitiesBulkUploadDetails.md
@@ -180,6 +183,7 @@ files:
180
183
  - lib/DealMakerAPI.rb
181
184
  - lib/DealMakerAPI/api/company_api.rb
182
185
  - lib/DealMakerAPI/api/country_api.rb
186
+ - lib/DealMakerAPI/api/custom_emails_api.rb
183
187
  - lib/DealMakerAPI/api/deal_api.rb
184
188
  - lib/DealMakerAPI/api/deals_api.rb
185
189
  - lib/DealMakerAPI/api/default_api.rb
@@ -203,6 +207,7 @@ files:
203
207
  - lib/DealMakerAPI/models/create_shareholder_action_request.rb
204
208
  - lib/DealMakerAPI/models/edit_investor_tags_request.rb
205
209
  - lib/DealMakerAPI/models/generate_url_request.rb
210
+ - lib/DealMakerAPI/models/get_access_token_request.rb
206
211
  - lib/DealMakerAPI/models/patch_deal_incentive_plan_request.rb
207
212
  - lib/DealMakerAPI/models/patch_investor_profiles_corporations.rb
208
213
  - lib/DealMakerAPI/models/patch_investor_profiles_corporations_beneficial_owners_inner.rb
@@ -231,6 +236,7 @@ files:
231
236
  - lib/DealMakerAPI/models/v1_entities_addresses.rb
232
237
  - lib/DealMakerAPI/models/v1_entities_attachment.rb
233
238
  - lib/DealMakerAPI/models/v1_entities_background_check_search.rb
239
+ - lib/DealMakerAPI/models/v1_entities_beefree_access_token.rb
234
240
  - lib/DealMakerAPI/models/v1_entities_bulk_upload.rb
235
241
  - lib/DealMakerAPI/models/v1_entities_bulk_upload_detail.rb
236
242
  - lib/DealMakerAPI/models/v1_entities_bulk_upload_details.rb
@@ -299,6 +305,7 @@ files:
299
305
  - lib/DealMakerAPI/version.rb
300
306
  - spec/api/company_api_spec.rb
301
307
  - spec/api/country_api_spec.rb
308
+ - spec/api/custom_emails_api_spec.rb
302
309
  - spec/api/deal_api_spec.rb
303
310
  - spec/api/deals_api_spec.rb
304
311
  - spec/api/default_api_spec.rb
@@ -319,6 +326,7 @@ files:
319
326
  - spec/models/create_shareholder_action_request_spec.rb
320
327
  - spec/models/edit_investor_tags_request_spec.rb
321
328
  - spec/models/generate_url_request_spec.rb
329
+ - spec/models/get_access_token_request_spec.rb
322
330
  - spec/models/patch_deal_incentive_plan_request_spec.rb
323
331
  - spec/models/patch_investor_profiles_corporations_beneficial_owners_inner_spec.rb
324
332
  - spec/models/patch_investor_profiles_corporations_spec.rb
@@ -347,6 +355,7 @@ files:
347
355
  - spec/models/v1_entities_addresses_spec.rb
348
356
  - spec/models/v1_entities_attachment_spec.rb
349
357
  - spec/models/v1_entities_background_check_search_spec.rb
358
+ - spec/models/v1_entities_beefree_access_token_spec.rb
350
359
  - spec/models/v1_entities_bulk_upload_detail_spec.rb
351
360
  - spec/models/v1_entities_bulk_upload_details_spec.rb
352
361
  - spec/models/v1_entities_bulk_upload_spec.rb
@@ -438,6 +447,7 @@ specification_version: 4
438
447
  summary: A ruby wrapper for the DealMaker API
439
448
  test_files:
440
449
  - spec/api/deal_api_spec.rb
450
+ - spec/api/custom_emails_api_spec.rb
441
451
  - spec/api/users_api_spec.rb
442
452
  - spec/api/shareholder_api_spec.rb
443
453
  - spec/api/company_api_spec.rb
@@ -469,6 +479,7 @@ test_files:
469
479
  - spec/models/v1_entities_payments_self_serve_onboarding_qualification_questionnaire_result_spec.rb
470
480
  - spec/models/v1_entities_attachment_spec.rb
471
481
  - spec/models/v1_entities_country_spec.rb
482
+ - spec/models/get_access_token_request_spec.rb
472
483
  - spec/models/put_webhooks_id_request_spec.rb
473
484
  - spec/models/post_deal_incentive_plan_request_spec.rb
474
485
  - spec/models/post_webhooks_request_spec.rb
@@ -499,6 +510,7 @@ test_files:
499
510
  - spec/models/v1_entities_shareholders_spec.rb
500
511
  - spec/models/v1_entities_payments_self_serve_onboarding_digital_payments_connection_data_spec.rb
501
512
  - spec/models/v1_entities_company_deals_spec.rb
513
+ - spec/models/v1_entities_beefree_access_token_spec.rb
502
514
  - spec/models/v1_entities_deals_spec.rb
503
515
  - spec/models/v1_entities_state_spec.rb
504
516
  - spec/models/v1_entities_webhooks_subscription_spec.rb