DealMakerAPI 0.0.1 → 0.0.2
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/DealMakerAPI.gemspec +1 -1
- data/README.md +12 -5
- data/docs/DealApi.md +3 -1
- data/docs/InvestorProfileApi.md +74 -0
- data/docs/V1EntitiesDeal.md +25 -3
- data/docs/V1EntitiesDealEnterprise.md +20 -0
- data/docs/V1EntitiesDealFundingMetrics.md +28 -0
- data/docs/V1EntitiesDealInvestorMetrics.md +28 -0
- data/docs/V1EntitiesDealIssuer.md +20 -0
- data/docs/V1EntitiesInvestor.md +2 -0
- data/docs/V1EntitiesInvestorProfileIndividual.md +40 -0
- data/docs/V1EntitiesInvestorUser.md +20 -0
- data/lib/DealMakerAPI/api/deal_api.rb +4 -1
- data/lib/DealMakerAPI/api/investor_profile_api.rb +86 -0
- data/lib/DealMakerAPI/api_client.rb +1 -1
- data/lib/DealMakerAPI/api_error.rb +1 -1
- data/lib/DealMakerAPI/configuration.rb +1 -1
- data/lib/DealMakerAPI/models/v1_entities_attachment.rb +1 -1
- data/lib/DealMakerAPI/models/v1_entities_background_check_search.rb +1 -1
- data/lib/DealMakerAPI/models/v1_entities_deal.rb +159 -7
- data/lib/DealMakerAPI/models/v1_entities_deal_enterprise.rb +229 -0
- data/lib/DealMakerAPI/models/v1_entities_deal_funding_metrics.rb +269 -0
- data/lib/DealMakerAPI/models/v1_entities_deal_investor_metrics.rb +269 -0
- data/lib/DealMakerAPI/models/v1_entities_deal_issuer.rb +229 -0
- data/lib/DealMakerAPI/models/v1_entities_investor.rb +13 -4
- data/lib/DealMakerAPI/models/v1_entities_investor_profile_individual.rb +364 -0
- data/lib/DealMakerAPI/models/v1_entities_investor_user.rb +229 -0
- data/lib/DealMakerAPI/models/v1_entities_investors.rb +1 -1
- data/lib/DealMakerAPI/models/v1_entities_subscription_agreement.rb +1 -1
- data/lib/DealMakerAPI/version.rb +2 -2
- data/lib/DealMakerAPI.rb +8 -1
- data/spec/api/investor_profile_api_spec.rb +47 -0
- data/spec/api_client_spec.rb +1 -1
- data/spec/configuration_spec.rb +1 -1
- data/spec/models/v1_entities_deal_enterprise_spec.rb +40 -0
- data/spec/models/v1_entities_deal_funding_metrics_spec.rb +64 -0
- data/spec/models/v1_entities_deal_investor_metrics_spec.rb +64 -0
- data/spec/models/v1_entities_deal_issuer_spec.rb +40 -0
- data/spec/models/v1_entities_investor_profile_individual_spec.rb +104 -0
- data/spec/models/v1_entities_investor_user_spec.rb +40 -0
- data/spec/spec_helper.rb +1 -1
- metadata +37 -9
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 342c74778c4efc6e27c3740a70e850324df1a0b0d1332aa1d3061af039a14ee0
|
4
|
+
data.tar.gz: d0f9c0e6abdd91577bde1f9701c6d8d17a031261829762f7660403ef1acccdf8
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: e839d519c85e5790c7a34badaade29042c90021d1d84019d8345c49790287f85aaca100992c98100b1b3b525412902275d3b14030c8ff884ae6a275219b5098e
|
7
|
+
data.tar.gz: fbdfa1972b99e6e58716a5ba1bab404904e3e39c671f282acba8e24c6180d1eb38499b73ff9f83a5e7f05cf9d3d2fd95f35045f4833f7d128e5c8024c2bcacc5
|
data/DealMakerAPI.gemspec
CHANGED
@@ -3,7 +3,7 @@
|
|
3
3
|
=begin
|
4
4
|
#DealMaker API
|
5
5
|
|
6
|
-
## Introduction Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with, and offers support in 2 different languages. # Libraries * Javascript * Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. ## Create an Application DealMaker’s Web API v1 supports the use of OAuth applications. Applications can be generated in your [account](https://www.dealmaker.tech/developer/applications). Unde the developer 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 public and secret keys. **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. # 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` | Forbiden | | `404` | Not found | # Pagination Pagination is used to divide large resposes 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. 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 | ## Respose Headers To review additional information about pagination on a specific response, including how to determine the total number of pages of the avaialble data set, the API returns the following header fields with every paginated response: | 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 | # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ----------- | ----------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links * [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) * [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. The type of data that the webhooks include: * Investor Name * Date created * Email * Phone * Allocation * Attachments * Accredited investor status * Accredited investor category * Status (Draft, Invited, Accepted, Waiting) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: * Investor is created * Investor details are updated (any of the investor details above change or are updated) * Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: * The HTTPS URL where the request will be sent * Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. * An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` * Triggers every time a new investor is added to a deal 2. `investor.updated` * Triggers on updates to any of the following fields: 1. Status 2. Name 3. Email - (this is a user field so we trigger event for all investors with webhook subscription) 4. Allocated Amount 5. Investment Amount 6. Accredited investor fields 7. Adding or removing attachments 8. Tags * When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.deleted` * Triggers when the investor is removed from the deal * The investor key of the payload only includes investor ID * The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests * The request is a `POST` * The payload’s `content-type` is `application/json` * Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry * We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail * If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. |Key|Type|Description| |--- |--- |--- | |event|String|The event that triggered the call| |event_id|String|A unique identifier for the event| |deal<sup>*</sup>|Object|The deal in which the event occurred. It includes id, title, created_at and updated_at| <sup>*</sup>This field is not included when deleting a resource #### Common Properties (investor scope) Every event on this scope must contain an investor object, here are some properties that are common to this object on all events in the investor scope: |Key|Type|Description| |--- |--- |--- | |id|Integer|The unique ID of the Investor| |name|String|Investor’s Name| |status|String|Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted| |email|String|| |phone_number|String|| |investment_amount|Double|| |allocated_amount|Double|| |accredited_investor|Object|See format in respective ticket| |attachments|Array of Objects|List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption)| |funding_state|String|Investor’s current funding state (unfunded, underfunded, funded, overfunded)| |funds_pending|Boolean|True if there are pending transactions, False otherwise| |created_at|Date|| |updated_at|Date|| |tags|Array of Strings|a list of the investor's tags, separated by comma.| ### investor.status >= signed Specific Properties |Key|Type|Description| |--- |--- |--- | |subscription_agreement|object|id, url (expiring URL)| #### Investor Status Here is a brief description of each investor state: * **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal * **Invited:** the investor was added to the platform but hasn’t completed the questionnaire * **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) * **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal * **Accepted:** the investor's agreement was countersigned by the Signatory #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
|
6
|
+
## Introduction Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with, and offers support in 2 different languages. # Libraries * Javascript * Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. ## 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). Unde the developer 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 public and secret keys. **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. # 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` | Forbiden | | `404` | Not found | # Pagination Pagination is used to divide large resposes 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. 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 | ## Respose Headers To review additional information about pagination on a specific response, including how to determine the total number of pages of the avaialble data set, the API returns the following header fields with every paginated response: | 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 | # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ----------- | ----------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links * [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) * [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. The type of data that the webhooks include: * Investor Name * Date created * Email * Phone * Allocation * Attachments * Accredited investor status * Accredited investor category * Status (Draft, Invited, Accepted, Waiting) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: * Investor is created * Investor details are updated (any of the investor details above change or are updated) * Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: * The HTTPS URL where the request will be sent * Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. * An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` * Triggers every time a new investor is added to a deal 2. `investor.updated` * Triggers on updates to any of the following fields: 1. Status 2. Name 3. Email - (this is a user field so we trigger event for all investors with webhook subscription) 4. Allocated Amount 5. Investment Amount 6. Accredited investor fields 7. Adding or removing attachments 8. Tags * When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.deleted` * Triggers when the investor is removed from the deal * The investor key of the payload only includes investor ID * The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests * The request is a `POST` * The payload’s `content-type` is `application/json` * Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry * We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail * If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. |Key|Type|Description| |--- |--- |--- | |event|String|The event that triggered the call| |event_id|String|A unique identifier for the event| |deal<sup>*</sup>|Object|The deal in which the event occurred. It includes id, title, created_at and updated_at| <sup>*</sup>This field is not included when deleting a resource #### Common Properties (investor scope) Every event on this scope must contain an investor object, here are some properties that are common to this object on all events in the investor scope: |Key|Type|Description| |--- |--- |--- | |id|Integer|The unique ID of the Investor| |name|String|Investor’s Name| |status|String|Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted| |email|String|| |phone_number|String|| |investment_amount|Double|| |allocated_amount|Double|| |accredited_investor|Object|See format in respective ticket| |attachments|Array of Objects|List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption)| |funding_state|String|Investor’s current funding state (unfunded, underfunded, funded, overfunded)| |funds_pending|Boolean|True if there are pending transactions, False otherwise| |created_at|Date|| |updated_at|Date|| |tags|Array of Strings|a list of the investor's tags, separated by comma.| ### investor.status >= signed Specific Properties |Key|Type|Description| |--- |--- |--- | |subscription_agreement|object|id, url (expiring URL)| #### Investor Status Here is a brief description of each investor state: * **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal * **Invited:** the investor was added to the platform but hasn’t completed the questionnaire * **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) * **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal * **Accepted:** the investor's agreement was countersigned by the Signatory #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
|
7
7
|
|
8
8
|
The version of the OpenAPI document: 1.0.0
|
9
9
|
|
data/README.md
CHANGED
@@ -17,7 +17,7 @@ To authenticate, add an Authorization header to your API request that contains a
|
|
17
17
|
|
18
18
|
## Create an Application
|
19
19
|
|
20
|
-
DealMaker’s Web API v1 supports the use of OAuth applications. Applications can be generated in your [account](https://
|
20
|
+
DealMaker’s Web API v1 supports the use of OAuth applications. Applications can be generated in your [account](https://app.dealmaker.tech/developer/applications).
|
21
21
|
|
22
22
|
Unde the developer tab, click the `Create New Application` button
|
23
23
|
|
@@ -277,7 +277,7 @@ Given the high number of updates our platform performs on any investor, we’ve
|
|
277
277
|
This SDK is automatically generated by the [OpenAPI Generator](https://openapi-generator.tech) project:
|
278
278
|
|
279
279
|
- API version: 1.0.0
|
280
|
-
- Package version: 0.0.
|
280
|
+
- Package version: 0.0.2
|
281
281
|
- Build package: org.openapitools.codegen.languages.RubyClientCodegen
|
282
282
|
|
283
283
|
## Installation
|
@@ -293,16 +293,16 @@ gem build DealMakerAPI.gemspec
|
|
293
293
|
Then either install the gem locally:
|
294
294
|
|
295
295
|
```shell
|
296
|
-
gem install ./DealMakerAPI-0.0.
|
296
|
+
gem install ./DealMakerAPI-0.0.2.gem
|
297
297
|
```
|
298
298
|
|
299
|
-
(for development, run `gem install --dev ./DealMakerAPI-0.0.
|
299
|
+
(for development, run `gem install --dev ./DealMakerAPI-0.0.2.gem` to install the development dependencies)
|
300
300
|
|
301
301
|
or publish the gem to a gem hosting service, e.g. [RubyGems](https://rubygems.org/).
|
302
302
|
|
303
303
|
Finally add this to the Gemfile:
|
304
304
|
|
305
|
-
gem 'DealMakerAPI', '~> 0.0.
|
305
|
+
gem 'DealMakerAPI', '~> 0.0.2'
|
306
306
|
|
307
307
|
### Install from Git
|
308
308
|
|
@@ -353,6 +353,7 @@ Class | Method | HTTP request | Description
|
|
353
353
|
*DealMakerAPI::DealApi* | [**get_deal**](docs/DealApi.md#get_deal) | **GET** /deals/{id} | Get a deal by id
|
354
354
|
*DealMakerAPI::DealApi* | [**get_investor**](docs/DealApi.md#get_investor) | **GET** /deals/{id}/investors/{investor_id} | Get a deal investor by id
|
355
355
|
*DealMakerAPI::DealApi* | [**list_investors**](docs/DealApi.md#list_investors) | **GET** /deals/{id}/investors | List deal investors
|
356
|
+
*DealMakerAPI::InvestorProfileApi* | [**create_investor_profile**](docs/InvestorProfileApi.md#create_investor_profile) | **POST** /investor_profiles | Create new investor profile
|
356
357
|
|
357
358
|
|
358
359
|
## Documentation for Models
|
@@ -360,7 +361,13 @@ Class | Method | HTTP request | Description
|
|
360
361
|
- [DealMakerAPI::V1EntitiesAttachment](docs/V1EntitiesAttachment.md)
|
361
362
|
- [DealMakerAPI::V1EntitiesBackgroundCheckSearch](docs/V1EntitiesBackgroundCheckSearch.md)
|
362
363
|
- [DealMakerAPI::V1EntitiesDeal](docs/V1EntitiesDeal.md)
|
364
|
+
- [DealMakerAPI::V1EntitiesDealEnterprise](docs/V1EntitiesDealEnterprise.md)
|
365
|
+
- [DealMakerAPI::V1EntitiesDealFundingMetrics](docs/V1EntitiesDealFundingMetrics.md)
|
366
|
+
- [DealMakerAPI::V1EntitiesDealInvestorMetrics](docs/V1EntitiesDealInvestorMetrics.md)
|
367
|
+
- [DealMakerAPI::V1EntitiesDealIssuer](docs/V1EntitiesDealIssuer.md)
|
363
368
|
- [DealMakerAPI::V1EntitiesInvestor](docs/V1EntitiesInvestor.md)
|
369
|
+
- [DealMakerAPI::V1EntitiesInvestorProfileIndividual](docs/V1EntitiesInvestorProfileIndividual.md)
|
370
|
+
- [DealMakerAPI::V1EntitiesInvestorUser](docs/V1EntitiesInvestorUser.md)
|
364
371
|
- [DealMakerAPI::V1EntitiesInvestors](docs/V1EntitiesInvestors.md)
|
365
372
|
- [DealMakerAPI::V1EntitiesSubscriptionAgreement](docs/V1EntitiesSubscriptionAgreement.md)
|
366
373
|
|
data/docs/DealApi.md
CHANGED
@@ -234,7 +234,8 @@ opts = {
|
|
234
234
|
page: 56, # Integer | Page offset to fetch.
|
235
235
|
per_page: 56, # Integer | Number of results to return per page.
|
236
236
|
offset: 56, # Integer | Pad a number of results.
|
237
|
-
investor_ids: [37] # Array<Integer> | An array of investor ids.
|
237
|
+
investor_ids: [37], # Array<Integer> | An array of investor ids.
|
238
|
+
q: 'q_example' # String | The search query for investors.
|
238
239
|
}
|
239
240
|
|
240
241
|
begin
|
@@ -273,6 +274,7 @@ end
|
|
273
274
|
| **per_page** | **Integer** | Number of results to return per page. | [optional][default to 25] |
|
274
275
|
| **offset** | **Integer** | Pad a number of results. | [optional][default to 0] |
|
275
276
|
| **investor_ids** | [**Array<Integer>**](Integer.md) | An array of investor ids. | [optional] |
|
277
|
+
| **q** | **String** | The search query for investors. | [optional] |
|
276
278
|
|
277
279
|
### Return type
|
278
280
|
|
@@ -0,0 +1,74 @@
|
|
1
|
+
# DealMakerAPI::InvestorProfileApi
|
2
|
+
|
3
|
+
All URIs are relative to *http://api.dealmaker.tech*
|
4
|
+
|
5
|
+
| Method | HTTP request | Description |
|
6
|
+
| ------ | ------------ | ----------- |
|
7
|
+
| [**create_investor_profile**](InvestorProfileApi.md#create_investor_profile) | **POST** /investor_profiles | Create new investor profile |
|
8
|
+
|
9
|
+
|
10
|
+
## create_investor_profile
|
11
|
+
|
12
|
+
> <V1EntitiesInvestorProfileIndividual> create_investor_profile(unknown_base_type)
|
13
|
+
|
14
|
+
Create new investor profile
|
15
|
+
|
16
|
+
Create new investor profile associated to the user by email.
|
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::InvestorProfileApi.new
|
27
|
+
unknown_base_type = TODO # UNKNOWN_BASE_TYPE |
|
28
|
+
|
29
|
+
begin
|
30
|
+
# Create new investor profile
|
31
|
+
result = api_instance.create_investor_profile(unknown_base_type)
|
32
|
+
p result
|
33
|
+
rescue DealMakerAPI::ApiError => e
|
34
|
+
puts "Error when calling InvestorProfileApi->create_investor_profile: #{e}"
|
35
|
+
end
|
36
|
+
```
|
37
|
+
|
38
|
+
#### Using the create_investor_profile_with_http_info variant
|
39
|
+
|
40
|
+
This returns an Array which contains the response data, status code and headers.
|
41
|
+
|
42
|
+
> <Array(<V1EntitiesInvestorProfileIndividual>, Integer, Hash)> create_investor_profile_with_http_info(unknown_base_type)
|
43
|
+
|
44
|
+
```ruby
|
45
|
+
begin
|
46
|
+
# Create new investor profile
|
47
|
+
data, status_code, headers = api_instance.create_investor_profile_with_http_info(unknown_base_type)
|
48
|
+
p status_code # => 2xx
|
49
|
+
p headers # => { ... }
|
50
|
+
p data # => <V1EntitiesInvestorProfileIndividual>
|
51
|
+
rescue DealMakerAPI::ApiError => e
|
52
|
+
puts "Error when calling InvestorProfileApi->create_investor_profile_with_http_info: #{e}"
|
53
|
+
end
|
54
|
+
```
|
55
|
+
|
56
|
+
### Parameters
|
57
|
+
|
58
|
+
| Name | Type | Description | Notes |
|
59
|
+
| ---- | ---- | ----------- | ----- |
|
60
|
+
| **unknown_base_type** | [**UNKNOWN_BASE_TYPE**](UNKNOWN_BASE_TYPE.md) | | |
|
61
|
+
|
62
|
+
### Return type
|
63
|
+
|
64
|
+
[**V1EntitiesInvestorProfileIndividual**](V1EntitiesInvestorProfileIndividual.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
|
+
|
data/docs/V1EntitiesDeal.md
CHANGED
@@ -4,8 +4,19 @@
|
|
4
4
|
|
5
5
|
| Name | Type | Description | Notes |
|
6
6
|
| ---- | ---- | ----------- | ----- |
|
7
|
-
| **id** | **Integer** |
|
8
|
-
| **title** | **String** |
|
7
|
+
| **id** | **Integer** | The deal's unique id. | [optional] |
|
8
|
+
| **title** | **String** | The deal title. | [optional] |
|
9
|
+
| **state** | **String** | The deal state. | [optional] |
|
10
|
+
| **currency** | **String** | The primary currency associated with the deal. | [optional] |
|
11
|
+
| **security_type** | **String** | The deal security type. | [optional] |
|
12
|
+
| **price_per_security** | **Float** | The deal price per security. | [optional] |
|
13
|
+
| **minimum_investment** | **Integer** | The minimum investment amount, in cents. | [optional] |
|
14
|
+
| **maximum_investment** | **Integer** | The maximum investment amount, in cents. | [optional] |
|
15
|
+
| **issuer** | [**V1EntitiesDealIssuer**](V1EntitiesDealIssuer.md) | | [optional] |
|
16
|
+
| **enterprise** | [**V1EntitiesDealEnterprise**](V1EntitiesDealEnterprise.md) | | [optional] |
|
17
|
+
| **deal_type** | **String** | The deal type. | [optional] |
|
18
|
+
| **investors** | [**V1EntitiesDealInvestorMetrics**](V1EntitiesDealInvestorMetrics.md) | | [optional] |
|
19
|
+
| **funding** | [**V1EntitiesDealFundingMetrics**](V1EntitiesDealFundingMetrics.md) | | [optional] |
|
9
20
|
|
10
21
|
## Example
|
11
22
|
|
@@ -14,7 +25,18 @@ require 'DealMakerAPI'
|
|
14
25
|
|
15
26
|
instance = DealMakerAPI::V1EntitiesDeal.new(
|
16
27
|
id: null,
|
17
|
-
title: null
|
28
|
+
title: null,
|
29
|
+
state: null,
|
30
|
+
currency: null,
|
31
|
+
security_type: null,
|
32
|
+
price_per_security: null,
|
33
|
+
minimum_investment: null,
|
34
|
+
maximum_investment: null,
|
35
|
+
issuer: null,
|
36
|
+
enterprise: null,
|
37
|
+
deal_type: null,
|
38
|
+
investors: null,
|
39
|
+
funding: null
|
18
40
|
)
|
19
41
|
```
|
20
42
|
|
@@ -0,0 +1,20 @@
|
|
1
|
+
# DealMakerAPI::V1EntitiesDealEnterprise
|
2
|
+
|
3
|
+
## Properties
|
4
|
+
|
5
|
+
| Name | Type | Description | Notes |
|
6
|
+
| ---- | ---- | ----------- | ----- |
|
7
|
+
| **id** | **Integer** | The enterprise id. | [optional] |
|
8
|
+
| **name** | **String** | The enterprise name. | [optional] |
|
9
|
+
|
10
|
+
## Example
|
11
|
+
|
12
|
+
```ruby
|
13
|
+
require 'DealMakerAPI'
|
14
|
+
|
15
|
+
instance = DealMakerAPI::V1EntitiesDealEnterprise.new(
|
16
|
+
id: null,
|
17
|
+
name: null
|
18
|
+
)
|
19
|
+
```
|
20
|
+
|
@@ -0,0 +1,28 @@
|
|
1
|
+
# DealMakerAPI::V1EntitiesDealFundingMetrics
|
2
|
+
|
3
|
+
## Properties
|
4
|
+
|
5
|
+
| Name | Type | Description | Notes |
|
6
|
+
| ---- | ---- | ----------- | ----- |
|
7
|
+
| **amount_subscribed** | **Float** | The amount subscribed. <br><br>This value is obtained by taking the sum of the investment amount from committed investors. Committed investors are investors with a status of `signed``, `waiting`, or `accepted`. | [optional] |
|
8
|
+
| **securities_subscribed** | **Integer** | The number of securities that have been subscribed. <br><br>This value is obtained by taking the sum of the total number of securities from committed investors. Committed investors are investors with a status of `signed`, `waiting`, or `accepted`. | [optional] |
|
9
|
+
| **amount_allocated** | **Float** | The amount allocated. <br><br>This value is obtained by taking the sum of the total allocated investment amount for investors with a status of `invited`. Allocated investment amounts are locked in and cannot be changed by the investor. | [optional] |
|
10
|
+
| **securities_allocated** | **Integer** | The number of securities that have been allocated. <br><br>This value is obtained by taking the sum of the total allocated number of securities for investors with a status of `invited`. Allocated securities are locked in and cannot be changed by the investor. | [optional] |
|
11
|
+
| **amount_accepted** | **Float** | The amount accepted. <br><br>This value is obtained by taking the sum of the investment amount from investors with the status `accepted`. | [optional] |
|
12
|
+
| **securities_accepted** | **Integer** | The number of securities that have been accepted. <br><br>This value is obtained by dividing the amount_accepted value by the price per security. | [optional] |
|
13
|
+
|
14
|
+
## Example
|
15
|
+
|
16
|
+
```ruby
|
17
|
+
require 'DealMakerAPI'
|
18
|
+
|
19
|
+
instance = DealMakerAPI::V1EntitiesDealFundingMetrics.new(
|
20
|
+
amount_subscribed: null,
|
21
|
+
securities_subscribed: null,
|
22
|
+
amount_allocated: null,
|
23
|
+
securities_allocated: null,
|
24
|
+
amount_accepted: null,
|
25
|
+
securities_accepted: null
|
26
|
+
)
|
27
|
+
```
|
28
|
+
|
@@ -0,0 +1,28 @@
|
|
1
|
+
# DealMakerAPI::V1EntitiesDealInvestorMetrics
|
2
|
+
|
3
|
+
## Properties
|
4
|
+
|
5
|
+
| Name | Type | Description | Notes |
|
6
|
+
| ---- | ---- | ----------- | ----- |
|
7
|
+
| **total** | **Integer** | The total number of investors. | [optional] |
|
8
|
+
| **draft** | **Integer** | The total number of investors in the draft state. | [optional] |
|
9
|
+
| **invited** | **Integer** | The total number of investors in the invited state. | [optional] |
|
10
|
+
| **signed** | **Integer** | The total number of investors in the signed state. | [optional] |
|
11
|
+
| **waiting** | **Integer** | The total number of investors in the waiting state. | [optional] |
|
12
|
+
| **accepted** | **Integer** | The total number of investors in the accepted state. | [optional] |
|
13
|
+
|
14
|
+
## Example
|
15
|
+
|
16
|
+
```ruby
|
17
|
+
require 'DealMakerAPI'
|
18
|
+
|
19
|
+
instance = DealMakerAPI::V1EntitiesDealInvestorMetrics.new(
|
20
|
+
total: null,
|
21
|
+
draft: null,
|
22
|
+
invited: null,
|
23
|
+
signed: null,
|
24
|
+
waiting: null,
|
25
|
+
accepted: null
|
26
|
+
)
|
27
|
+
```
|
28
|
+
|
@@ -0,0 +1,20 @@
|
|
1
|
+
# DealMakerAPI::V1EntitiesDealIssuer
|
2
|
+
|
3
|
+
## Properties
|
4
|
+
|
5
|
+
| Name | Type | Description | Notes |
|
6
|
+
| ---- | ---- | ----------- | ----- |
|
7
|
+
| **id** | **Integer** | The issuer's unique id. | [optional] |
|
8
|
+
| **name** | **String** | The issuer name. | [optional] |
|
9
|
+
|
10
|
+
## Example
|
11
|
+
|
12
|
+
```ruby
|
13
|
+
require 'DealMakerAPI'
|
14
|
+
|
15
|
+
instance = DealMakerAPI::V1EntitiesDealIssuer.new(
|
16
|
+
id: null,
|
17
|
+
name: null
|
18
|
+
)
|
19
|
+
```
|
20
|
+
|
data/docs/V1EntitiesInvestor.md
CHANGED
@@ -5,6 +5,7 @@
|
|
5
5
|
| Name | Type | Description | Notes |
|
6
6
|
| ---- | ---- | ----------- | ----- |
|
7
7
|
| **id** | **Integer** | Investor id. | [optional] |
|
8
|
+
| **user** | [**V1EntitiesInvestorUser**](V1EntitiesInvestorUser.md) | | [optional] |
|
8
9
|
| **created_at** | **Time** | The creation time. | [optional] |
|
9
10
|
| **updated_at** | **Time** | The last update time. | [optional] |
|
10
11
|
| **name** | **String** | The full name of the investor. | [optional] |
|
@@ -33,6 +34,7 @@ require 'DealMakerAPI'
|
|
33
34
|
|
34
35
|
instance = DealMakerAPI::V1EntitiesInvestor.new(
|
35
36
|
id: null,
|
37
|
+
user: null,
|
36
38
|
created_at: null,
|
37
39
|
updated_at: null,
|
38
40
|
name: null,
|
@@ -0,0 +1,40 @@
|
|
1
|
+
# DealMakerAPI::V1EntitiesInvestorProfileIndividual
|
2
|
+
|
3
|
+
## Properties
|
4
|
+
|
5
|
+
| Name | Type | Description | Notes |
|
6
|
+
| ---- | ---- | ----------- | ----- |
|
7
|
+
| **id** | **Integer** | Investor Profile id | [optional] |
|
8
|
+
| **user_id** | **Integer** | User id | [optional] |
|
9
|
+
| **email** | **String** | User email | [optional] |
|
10
|
+
| **type** | **String** | Investor Profile type | [optional] |
|
11
|
+
| **first_name** | **String** | Investor Profile First Name | [optional] |
|
12
|
+
| **last_name** | **String** | Investor Profile Last Name | [optional] |
|
13
|
+
| **country** | **String** | Investor Profile Counrty | [optional] |
|
14
|
+
| **street_address** | **String** | Investor Profile Street Address | [optional] |
|
15
|
+
| **unit2** | **String** | Investor Profile Street Address Line 2 | [optional] |
|
16
|
+
| **city** | **String** | Investor Profile City | [optional] |
|
17
|
+
| **region** | **String** | Investor Profile Region or State | [optional] |
|
18
|
+
| **postal_code** | **String** | Investor Profile Postal Code or ZipCode | [optional] |
|
19
|
+
|
20
|
+
## Example
|
21
|
+
|
22
|
+
```ruby
|
23
|
+
require 'DealMakerAPI'
|
24
|
+
|
25
|
+
instance = DealMakerAPI::V1EntitiesInvestorProfileIndividual.new(
|
26
|
+
id: null,
|
27
|
+
user_id: null,
|
28
|
+
email: null,
|
29
|
+
type: null,
|
30
|
+
first_name: null,
|
31
|
+
last_name: null,
|
32
|
+
country: null,
|
33
|
+
street_address: null,
|
34
|
+
unit2: null,
|
35
|
+
city: null,
|
36
|
+
region: null,
|
37
|
+
postal_code: null
|
38
|
+
)
|
39
|
+
```
|
40
|
+
|
@@ -0,0 +1,20 @@
|
|
1
|
+
# DealMakerAPI::V1EntitiesInvestorUser
|
2
|
+
|
3
|
+
## Properties
|
4
|
+
|
5
|
+
| Name | Type | Description | Notes |
|
6
|
+
| ---- | ---- | ----------- | ----- |
|
7
|
+
| **id** | **Integer** | Investor user id. | [optional] |
|
8
|
+
| **email** | **String** | Investor user email address. | [optional] |
|
9
|
+
|
10
|
+
## Example
|
11
|
+
|
12
|
+
```ruby
|
13
|
+
require 'DealMakerAPI'
|
14
|
+
|
15
|
+
instance = DealMakerAPI::V1EntitiesInvestorUser.new(
|
16
|
+
id: null,
|
17
|
+
email: null
|
18
|
+
)
|
19
|
+
```
|
20
|
+
|
@@ -1,7 +1,7 @@
|
|
1
1
|
=begin
|
2
2
|
#DealMaker API
|
3
3
|
|
4
|
-
## Introduction Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with, and offers support in 2 different languages. # Libraries * Javascript * Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. ## Create an Application DealMaker’s Web API v1 supports the use of OAuth applications. Applications can be generated in your [account](https://www.dealmaker.tech/developer/applications). Unde the developer 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 public and secret keys. **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. # 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` | Forbiden | | `404` | Not found | # Pagination Pagination is used to divide large resposes 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. 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 | ## Respose Headers To review additional information about pagination on a specific response, including how to determine the total number of pages of the avaialble data set, the API returns the following header fields with every paginated response: | 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 | # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ----------- | ----------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links * [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) * [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. The type of data that the webhooks include: * Investor Name * Date created * Email * Phone * Allocation * Attachments * Accredited investor status * Accredited investor category * Status (Draft, Invited, Accepted, Waiting) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: * Investor is created * Investor details are updated (any of the investor details above change or are updated) * Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: * The HTTPS URL where the request will be sent * Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. * An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` * Triggers every time a new investor is added to a deal 2. `investor.updated` * Triggers on updates to any of the following fields: 1. Status 2. Name 3. Email - (this is a user field so we trigger event for all investors with webhook subscription) 4. Allocated Amount 5. Investment Amount 6. Accredited investor fields 7. Adding or removing attachments 8. Tags * When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.deleted` * Triggers when the investor is removed from the deal * The investor key of the payload only includes investor ID * The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests * The request is a `POST` * The payload’s `content-type` is `application/json` * Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry * We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail * If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. |Key|Type|Description| |--- |--- |--- | |event|String|The event that triggered the call| |event_id|String|A unique identifier for the event| |deal<sup>*</sup>|Object|The deal in which the event occurred. It includes id, title, created_at and updated_at| <sup>*</sup>This field is not included when deleting a resource #### Common Properties (investor scope) Every event on this scope must contain an investor object, here are some properties that are common to this object on all events in the investor scope: |Key|Type|Description| |--- |--- |--- | |id|Integer|The unique ID of the Investor| |name|String|Investor’s Name| |status|String|Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted| |email|String|| |phone_number|String|| |investment_amount|Double|| |allocated_amount|Double|| |accredited_investor|Object|See format in respective ticket| |attachments|Array of Objects|List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption)| |funding_state|String|Investor’s current funding state (unfunded, underfunded, funded, overfunded)| |funds_pending|Boolean|True if there are pending transactions, False otherwise| |created_at|Date|| |updated_at|Date|| |tags|Array of Strings|a list of the investor's tags, separated by comma.| ### investor.status >= signed Specific Properties |Key|Type|Description| |--- |--- |--- | |subscription_agreement|object|id, url (expiring URL)| #### Investor Status Here is a brief description of each investor state: * **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal * **Invited:** the investor was added to the platform but hasn’t completed the questionnaire * **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) * **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal * **Accepted:** the investor's agreement was countersigned by the Signatory #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
|
4
|
+
## Introduction Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with, and offers support in 2 different languages. # Libraries * Javascript * Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. ## 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). Unde the developer 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 public and secret keys. **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. # 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` | Forbiden | | `404` | Not found | # Pagination Pagination is used to divide large resposes 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. 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 | ## Respose Headers To review additional information about pagination on a specific response, including how to determine the total number of pages of the avaialble data set, the API returns the following header fields with every paginated response: | 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 | # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ----------- | ----------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links * [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) * [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. The type of data that the webhooks include: * Investor Name * Date created * Email * Phone * Allocation * Attachments * Accredited investor status * Accredited investor category * Status (Draft, Invited, Accepted, Waiting) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: * Investor is created * Investor details are updated (any of the investor details above change or are updated) * Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: * The HTTPS URL where the request will be sent * Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. * An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` * Triggers every time a new investor is added to a deal 2. `investor.updated` * Triggers on updates to any of the following fields: 1. Status 2. Name 3. Email - (this is a user field so we trigger event for all investors with webhook subscription) 4. Allocated Amount 5. Investment Amount 6. Accredited investor fields 7. Adding or removing attachments 8. Tags * When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.deleted` * Triggers when the investor is removed from the deal * The investor key of the payload only includes investor ID * The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests * The request is a `POST` * The payload’s `content-type` is `application/json` * Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry * We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail * If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. |Key|Type|Description| |--- |--- |--- | |event|String|The event that triggered the call| |event_id|String|A unique identifier for the event| |deal<sup>*</sup>|Object|The deal in which the event occurred. It includes id, title, created_at and updated_at| <sup>*</sup>This field is not included when deleting a resource #### Common Properties (investor scope) Every event on this scope must contain an investor object, here are some properties that are common to this object on all events in the investor scope: |Key|Type|Description| |--- |--- |--- | |id|Integer|The unique ID of the Investor| |name|String|Investor’s Name| |status|String|Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted| |email|String|| |phone_number|String|| |investment_amount|Double|| |allocated_amount|Double|| |accredited_investor|Object|See format in respective ticket| |attachments|Array of Objects|List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption)| |funding_state|String|Investor’s current funding state (unfunded, underfunded, funded, overfunded)| |funds_pending|Boolean|True if there are pending transactions, False otherwise| |created_at|Date|| |updated_at|Date|| |tags|Array of Strings|a list of the investor's tags, separated by comma.| ### investor.status >= signed Specific Properties |Key|Type|Description| |--- |--- |--- | |subscription_agreement|object|id, url (expiring URL)| #### Investor Status Here is a brief description of each investor state: * **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal * **Invited:** the investor was added to the platform but hasn’t completed the questionnaire * **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) * **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal * **Accepted:** the investor's agreement was countersigned by the Signatory #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
|
5
5
|
|
6
6
|
The version of the OpenAPI document: 1.0.0
|
7
7
|
|
@@ -229,6 +229,7 @@ module DealMakerAPI
|
|
229
229
|
# @option opts [Integer] :per_page Number of results to return per page. (default to 25)
|
230
230
|
# @option opts [Integer] :offset Pad a number of results. (default to 0)
|
231
231
|
# @option opts [Array<Integer>] :investor_ids An array of investor ids.
|
232
|
+
# @option opts [String] :q The search query for investors.
|
232
233
|
# @return [V1EntitiesInvestors]
|
233
234
|
def list_investors(id, opts = {})
|
234
235
|
data, _status_code, _headers = list_investors_with_http_info(id, opts)
|
@@ -243,6 +244,7 @@ module DealMakerAPI
|
|
243
244
|
# @option opts [Integer] :per_page Number of results to return per page.
|
244
245
|
# @option opts [Integer] :offset Pad a number of results.
|
245
246
|
# @option opts [Array<Integer>] :investor_ids An array of investor ids.
|
247
|
+
# @option opts [String] :q The search query for investors.
|
246
248
|
# @return [Array<(V1EntitiesInvestors, Integer, Hash)>] V1EntitiesInvestors data, response status code and response headers
|
247
249
|
def list_investors_with_http_info(id, opts = {})
|
248
250
|
if @api_client.config.debugging
|
@@ -261,6 +263,7 @@ module DealMakerAPI
|
|
261
263
|
query_params[:'per_page'] = opts[:'per_page'] if !opts[:'per_page'].nil?
|
262
264
|
query_params[:'offset'] = opts[:'offset'] if !opts[:'offset'].nil?
|
263
265
|
query_params[:'investor_ids'] = @api_client.build_collection_param(opts[:'investor_ids'], :csv) if !opts[:'investor_ids'].nil?
|
266
|
+
query_params[:'q'] = opts[:'q'] if !opts[:'q'].nil?
|
264
267
|
|
265
268
|
# header parameters
|
266
269
|
header_params = opts[:header_params] || {}
|
@@ -0,0 +1,86 @@
|
|
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. # Libraries * Javascript * Ruby # Authentication To authenticate, add an Authorization header to your API request that contains an access token. ## 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). Unde the developer 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 public and secret keys. **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. # 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` | Forbiden | | `404` | Not found | # Pagination Pagination is used to divide large resposes 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. 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 | ## Respose Headers To review additional information about pagination on a specific response, including how to determine the total number of pages of the avaialble data set, the API returns the following header fields with every paginated response: | 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 | # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ----------- | ----------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links * [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) * [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. The type of data that the webhooks include: * Investor Name * Date created * Email * Phone * Allocation * Attachments * Accredited investor status * Accredited investor category * Status (Draft, Invited, Accepted, Waiting) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: * Investor is created * Investor details are updated (any of the investor details above change or are updated) * Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: * The HTTPS URL where the request will be sent * Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. * An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` * Triggers every time a new investor is added to a deal 2. `investor.updated` * Triggers on updates to any of the following fields: 1. Status 2. Name 3. Email - (this is a user field so we trigger event for all investors with webhook subscription) 4. Allocated Amount 5. Investment Amount 6. Accredited investor fields 7. Adding or removing attachments 8. Tags * When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.deleted` * Triggers when the investor is removed from the deal * The investor key of the payload only includes investor ID * The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests * The request is a `POST` * The payload’s `content-type` is `application/json` * Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry * We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail * If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. |Key|Type|Description| |--- |--- |--- | |event|String|The event that triggered the call| |event_id|String|A unique identifier for the event| |deal<sup>*</sup>|Object|The deal in which the event occurred. It includes id, title, created_at and updated_at| <sup>*</sup>This field is not included when deleting a resource #### Common Properties (investor scope) Every event on this scope must contain an investor object, here are some properties that are common to this object on all events in the investor scope: |Key|Type|Description| |--- |--- |--- | |id|Integer|The unique ID of the Investor| |name|String|Investor’s Name| |status|String|Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted| |email|String|| |phone_number|String|| |investment_amount|Double|| |allocated_amount|Double|| |accredited_investor|Object|See format in respective ticket| |attachments|Array of Objects|List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption)| |funding_state|String|Investor’s current funding state (unfunded, underfunded, funded, overfunded)| |funds_pending|Boolean|True if there are pending transactions, False otherwise| |created_at|Date|| |updated_at|Date|| |tags|Array of Strings|a list of the investor's tags, separated by comma.| ### investor.status >= signed Specific Properties |Key|Type|Description| |--- |--- |--- | |subscription_agreement|object|id, url (expiring URL)| #### Investor Status Here is a brief description of each investor state: * **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal * **Invited:** the investor was added to the platform but hasn’t completed the questionnaire * **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) * **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal * **Accepted:** the investor's agreement was countersigned by the Signatory #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
|
5
|
+
|
6
|
+
The version of the OpenAPI document: 1.0.0
|
7
|
+
|
8
|
+
Generated by: https://openapi-generator.tech
|
9
|
+
OpenAPI Generator version: 5.4.0-SNAPSHOT
|
10
|
+
|
11
|
+
=end
|
12
|
+
|
13
|
+
require 'cgi'
|
14
|
+
|
15
|
+
module DealMakerAPI
|
16
|
+
class InvestorProfileApi
|
17
|
+
attr_accessor :api_client
|
18
|
+
|
19
|
+
def initialize(api_client = ApiClient.default)
|
20
|
+
@api_client = api_client
|
21
|
+
end
|
22
|
+
# Create new investor profile
|
23
|
+
# Create new investor profile associated to the user by email.
|
24
|
+
# @param unknown_base_type [UNKNOWN_BASE_TYPE]
|
25
|
+
# @param [Hash] opts the optional parameters
|
26
|
+
# @return [V1EntitiesInvestorProfileIndividual]
|
27
|
+
def create_investor_profile(unknown_base_type, opts = {})
|
28
|
+
data, _status_code, _headers = create_investor_profile_with_http_info(unknown_base_type, opts)
|
29
|
+
data
|
30
|
+
end
|
31
|
+
|
32
|
+
# Create new investor profile
|
33
|
+
# Create new investor profile associated to the user by email.
|
34
|
+
# @param unknown_base_type [UNKNOWN_BASE_TYPE]
|
35
|
+
# @param [Hash] opts the optional parameters
|
36
|
+
# @return [Array<(V1EntitiesInvestorProfileIndividual, Integer, Hash)>] V1EntitiesInvestorProfileIndividual data, response status code and response headers
|
37
|
+
def create_investor_profile_with_http_info(unknown_base_type, opts = {})
|
38
|
+
if @api_client.config.debugging
|
39
|
+
@api_client.config.logger.debug 'Calling API: InvestorProfileApi.create_investor_profile ...'
|
40
|
+
end
|
41
|
+
# resource path
|
42
|
+
local_var_path = '/investor_profiles'
|
43
|
+
|
44
|
+
# query parameters
|
45
|
+
query_params = opts[:query_params] || {}
|
46
|
+
|
47
|
+
# header parameters
|
48
|
+
header_params = opts[:header_params] || {}
|
49
|
+
# HTTP header 'Accept' (if needed)
|
50
|
+
header_params['Accept'] = @api_client.select_header_accept(['application/json'])
|
51
|
+
# HTTP header 'Content-Type'
|
52
|
+
content_type = @api_client.select_header_content_type(['application/json'])
|
53
|
+
if !content_type.nil?
|
54
|
+
header_params['Content-Type'] = content_type
|
55
|
+
end
|
56
|
+
|
57
|
+
# form parameters
|
58
|
+
form_params = opts[:form_params] || {}
|
59
|
+
|
60
|
+
# http body (model)
|
61
|
+
post_body = opts[:debug_body] || @api_client.object_to_http_body(unknown_base_type)
|
62
|
+
|
63
|
+
# return_type
|
64
|
+
return_type = opts[:debug_return_type] || 'V1EntitiesInvestorProfileIndividual'
|
65
|
+
|
66
|
+
# auth_names
|
67
|
+
auth_names = opts[:debug_auth_names] || []
|
68
|
+
|
69
|
+
new_options = opts.merge(
|
70
|
+
:operation => :"InvestorProfileApi.create_investor_profile",
|
71
|
+
:header_params => header_params,
|
72
|
+
:query_params => query_params,
|
73
|
+
:form_params => form_params,
|
74
|
+
:body => post_body,
|
75
|
+
:auth_names => auth_names,
|
76
|
+
:return_type => return_type
|
77
|
+
)
|
78
|
+
|
79
|
+
data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
|
80
|
+
if @api_client.config.debugging
|
81
|
+
@api_client.config.logger.debug "API called: InvestorProfileApi#create_investor_profile\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
|
82
|
+
end
|
83
|
+
return data, status_code, headers
|
84
|
+
end
|
85
|
+
end
|
86
|
+
end
|