DealMakerAPI 0.0.2 → 0.0.3

Sign up to get free protection for your applications and to get access to all the features.
Files changed (44) hide show
  1. checksums.yaml +4 -4
  2. data/DealMakerAPI.gemspec +2 -2
  3. data/README.md +154 -115
  4. data/docs/DealApi.md +75 -2
  5. data/docs/V1EntitiesDeals.md +18 -0
  6. data/lib/DealMakerAPI/api/deal_api.rb +69 -3
  7. data/lib/DealMakerAPI/api/investor_profile_api.rb +1 -1
  8. data/lib/DealMakerAPI/api_client.rb +1 -1
  9. data/lib/DealMakerAPI/api_error.rb +1 -1
  10. data/lib/DealMakerAPI/configuration.rb +1 -1
  11. data/lib/DealMakerAPI/models/v1_entities_attachment.rb +1 -1
  12. data/lib/DealMakerAPI/models/v1_entities_background_check_search.rb +1 -1
  13. data/lib/DealMakerAPI/models/v1_entities_deal.rb +1 -1
  14. data/lib/DealMakerAPI/models/v1_entities_deal_enterprise.rb +1 -1
  15. data/lib/DealMakerAPI/models/v1_entities_deal_funding_metrics.rb +1 -1
  16. data/lib/DealMakerAPI/models/v1_entities_deal_investor_metrics.rb +1 -1
  17. data/lib/DealMakerAPI/models/v1_entities_deal_issuer.rb +1 -1
  18. data/lib/DealMakerAPI/models/v1_entities_deals.rb +219 -0
  19. data/lib/DealMakerAPI/models/v1_entities_investor.rb +1 -1
  20. data/lib/DealMakerAPI/models/v1_entities_investor_profile_individual.rb +1 -1
  21. data/lib/DealMakerAPI/models/v1_entities_investor_user.rb +1 -1
  22. data/lib/DealMakerAPI/models/v1_entities_investors.rb +1 -1
  23. data/lib/DealMakerAPI/models/v1_entities_subscription_agreement.rb +1 -1
  24. data/lib/DealMakerAPI/version.rb +2 -2
  25. data/lib/DealMakerAPI.rb +2 -1
  26. data/spec/api/deal_api_spec.rb +16 -1
  27. data/spec/api/investor_profile_api_spec.rb +1 -1
  28. data/spec/api_client_spec.rb +1 -1
  29. data/spec/configuration_spec.rb +1 -1
  30. data/spec/models/v1_entities_attachment_spec.rb +1 -1
  31. data/spec/models/v1_entities_background_check_search_spec.rb +1 -1
  32. data/spec/models/v1_entities_deal_enterprise_spec.rb +1 -1
  33. data/spec/models/v1_entities_deal_funding_metrics_spec.rb +1 -1
  34. data/spec/models/v1_entities_deal_investor_metrics_spec.rb +1 -1
  35. data/spec/models/v1_entities_deal_issuer_spec.rb +1 -1
  36. data/spec/models/v1_entities_deal_spec.rb +75 -1
  37. data/spec/models/v1_entities_deals_spec.rb +34 -0
  38. data/spec/models/v1_entities_investor_profile_individual_spec.rb +1 -1
  39. data/spec/models/v1_entities_investor_spec.rb +8 -2
  40. data/spec/models/v1_entities_investor_user_spec.rb +1 -1
  41. data/spec/models/v1_entities_investors_spec.rb +1 -1
  42. data/spec/models/v1_entities_subscription_agreement_spec.rb +1 -1
  43. data/spec/spec_helper.rb +1 -1
  44. metadata +16 -12
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 342c74778c4efc6e27c3740a70e850324df1a0b0d1332aa1d3061af039a14ee0
4
- data.tar.gz: d0f9c0e6abdd91577bde1f9701c6d8d17a031261829762f7660403ef1acccdf8
3
+ metadata.gz: 518766c3e3b202ef795dd84197f28e5334a418c71ec0648bde221cfc7754f71a
4
+ data.tar.gz: d86f3bd8576caabae3e33d743968096acafdeab6e38abf4e243245ded2ab3131
5
5
  SHA512:
6
- metadata.gz: e839d519c85e5790c7a34badaade29042c90021d1d84019d8345c49790287f85aaca100992c98100b1b3b525412902275d3b14030c8ff884ae6a275219b5098e
7
- data.tar.gz: fbdfa1972b99e6e58716a5ba1bab404904e3e39c671f282acba8e24c6180d1eb38499b73ff9f83a5e7f05cf9d3d2fd95f35045f4833f7d128e5c8024c2bcacc5
6
+ metadata.gz: c809257ceca8ec119ffbcb0b5fb8cc2e9cb295e3e1d7b6a3229ffbf52cb64cce8daf9f890cefc2ee1b556466a40a79d1d1932317f74355ee33d1d7ae0d0d0605
7
+ data.tar.gz: cdee8e4e05eeff8d0c66d4c386780b8758c3367eb3ea386a971c747f78f43bb61538627ca48ca78597758dc65bf99d517f47d60cf3270afb4ede13215daee16a
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://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.
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. 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). 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. 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. There are two main ways to filter with it. ## Keyword filtering Some keywords allow you to filter investors based on a specific “scope” of the investors, for example using the string “Invited” will filter all investors with the status invited, and the keyword “Has attachments” will filter investors with attachments. Here’s a list of possible keywords and the “scope” each one of the keywords filters by: | Keywords | Scope | Decoded Example | Encoded Example | | ---------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Signed on \\(date range\\) | Investors who signed in the provided date range | Signed on (date range) [2020-07-01:2020-07-31] | `Signed%20on%20%28date%20range%29%20%5B2020-07-01%3A2020-07-31%5D` | | Enabled for countersignature on \\(date range\\) | Investors who were enabled for counter signature in the provided date range | Enabled for countersignature on (date range) [2022-05-24:2022-05-25] | `Enabled%20for%20countersignature%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Accepted on \\(date range\\) | Investors accepted in the provided date rage | Accepted on (date range) [2022-05-24:2022-05-25] | `Accepted%20on%20(date%20range)%20%5B2022-05-24%3A2022-05-25%5D` | | Offline | Investors added to the deal offline | Offline | `Offline` | | Online | Investors added to the deal online | Online | `Online` | | Signed | Investors who signed their agreement | Signed | `Signed` | | Waiting for countersignature | Investors who have signed and are waiting for counter signature | Waiting for countersignature | `Waiting%20for%20countersignature` | | Invited | Investors on the Invited Status | Invited | `Invited` | | Accepted | Investors in the Accepted Status | Accepted | `Accepted` | | Questionnaire in progress | All Investors who have not finished completing the questionnaire | Questionnaire in progress | `Questionnaire%20in%20progress` | | Has attachments | All Investors with attachments | Has attachments | `Has%20attachments` | | Has notes | All Investors with notes | Has notes | `Has%20notes` | | Waiting for co-signature | Investors who have signed and are waiting for co-signature | Waiting for co-signature | `Waiting%20for%20co-signature` | | Background Check Approved | Investors with approved background check | Background Check Approved | `Background%20Check%20Approved` | | Document Review Pending | Investors with pending review | Document Review Pending | `Document%20Review%20Pending` | | Document Upload Pending | Investors with pending documents to upload | Document Upload Pending | `Document%20Upload%20Pending` | | Required adjudicator review | Investors who are required to be review by the adjudicator | Required adjudicator review | `Required%20adjudicator%20review` | --- **NOTE** Filtering keywords are case sensitive and need to be encoded --- ## Search String Any value for the parameter which does not match one of the keywords listed above, will use fields like `first name`, `last name`, `email`, `tags` to search for the investor. For example, if you search “Robert”, because this does not match one of the keywords listed above, it will then return any investors who have the string “Robert” in their name, email, or tags fields. # Versioning The latest version is v1. The version can be updated on the `Accept` header, just set the version as stated on the following example: ``` Accept:application/vnd.dealmaker-v1+json ``` | Version | Accept Header | | ------- | ----------------------------------- | | `v1` | application/vnd.dealmaker-`v1`+json | # SDK’s For instruction on installing SDKs, please view the following links - [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript) - [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby) # Webhooks Our webhooks functionality allows clients to automatically receive updates on a deal's investor data. The type of data that the webhooks include: - Investor Name - Date created - Email - Phone - Allocation - Attachments - Accredited investor status - Accredited investor category - Status (Draft, Invited, Accepted, Waiting) Via webhooks clients can subscribe to the following events as they happen on Dealmaker: - Investor is created - Investor details are updated (any of the investor details above change or are updated) - Investor is deleted A URL supplied by the client will receive all the events with the information as part of the payload. Clients are able to add and update the URL within DealMaker. ## Configuration For a comprehensive guide on how to configure Webhooks please visit our support article: [Configuring Webhooks on DealMaker – DealMaker Support](https://help.dealmaker.tech/configuring-webhooks-on-dealmaker). As a developer user on DealMaker, you are able to configure webhooks by following the steps below: 1. Sign into Dealmaker 2. Go to **“Your profile”** in the top right corner 3. Access an **“Integrations”** configuration via the left menu 4. The developer configures webhooks by including: - The HTTPS URL where the request will be sent - Optionally, a security token that we would use to build a SHA1 hash that would be included in the request headers. The name of the header is `X-DealMaker-Signature`. If the secret is not specified, the hash won’t be included in the headers. - An email address that will be used to notify about errors. 5. The developers can disable webhooks temporarily if needed ## Specification ### Events The initial set of events will be related to the investor. The events are: 1. `investor.created` - Triggers every time a new investor is added to a deal 2. `investor.updated` - Triggers on updates to any of the following fields: 1. Status 2. Name 3. Email - (this is a user field so we trigger event for all investors with webhook subscription) 4. Allocated Amount 5. Investment Amount 6. Accredited investor fields 7. Adding or removing attachments 8. Tags - When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes 3. `investor.deleted` - Triggers when the investor is removed from the deal - The investor key of the payload only includes investor ID - The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of ### Requests - The request is a `POST` - The payload’s `content-type` is `application/json` - Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry - We retry the request five times, after the initial attempt. Doubling the waiting time between intervals with each try. The first retry happens after 30 seconds, then 60 seconds, 2 mins, 4 minutes, and 8 minutes. This timing scheme gives the receiver about 1 hour if all the requests fail - If an event fails all the attempts to be delivered, we send an email to the address that the user configured ### Payload #### Common Properties There will be some properties that are common to all the events on the system. | Key | Type | Description | | ----------------- | ------ | -------------------------------------------------------------------------------------- | | event | String | The event that triggered the call | | event_id | String | A unique identifier for the event | | deal<sup>\\*</sup> | Object | The deal in which the event occurred. It includes id, title, created_at and updated_at | <sup>\\*</sup>This field is not included when deleting a resource #### Common Properties (investor scope) Every event on this scope must contain an investor object, here are some properties that are common to this object on all events in the investor scope: | Key | Type | Description | | ------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------ | | id | Integer | The unique ID of the Investor | | name | String | Investor’s Name | | status | String | Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted | | email | String | | | phone_number | String | | | investment_amount | Double | | | allocated_amount | Double | | | accredited_investor | Object | See format in respective ticket | | attachments | Array of Objects | List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption) | | funding_state | String | Investor’s current funding state (unfunded, underfunded, funded, overfunded) | | funds_pending | Boolean | True if there are pending transactions, False otherwise | | created_at | Date | | | updated_at | Date | | | tags | Array of Strings | a list of the investor's tags, separated by comma. | ### investor.status >= signed Specific Properties | Key | Type | Description | | ---------------------- | ------ | ---------------------- | | subscription_agreement | object | id, url (expiring URL) | #### Investor Status Here is a brief description of each investor state: - **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal - **Invited:** the investor was added to the platform but hasn’t completed the questionnaire - **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature) - **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal - **Accepted:** the investor's agreement was countersigned by the Signatory #### Update Delay Given the high number of updates our platform performs on any investor, we’ve added a cool down period on update events that allows us to “group” updates and trigger only one every minute. In consequence, update events will be delivered 1 minute after the initial request was made and will include the latest version of the investor data at delivery time.
7
7
 
8
8
  The version of the OpenAPI document: 1.0.0
9
9
 
@@ -24,7 +24,7 @@ Gem::Specification.new do |s|
24
24
  s.homepage = "https://dealmaker.tech"
25
25
  s.summary = "A ruby wrapper for the DealMaker API"
26
26
  s.description = "A ruby wrapper for the DealMaker API"
27
- s.license = "TODO"
27
+ s.license = "MIT"
28
28
  s.required_ruby_version = ">= 2.4"
29
29
 
30
30
  s.add_runtime_dependency 'typhoeus', '~> 1.0', '>= 1.0.1'
data/README.md CHANGED
@@ -8,18 +8,18 @@ Welcome to DealMaker’s Web API v1! This API is RESTful, easy to integrate with
8
8
 
9
9
  # Libraries
10
10
 
11
- * Javascript
12
- * Ruby
11
+ - Javascript
12
+ - Ruby
13
13
 
14
14
  # Authentication
15
15
 
16
- To authenticate, add an Authorization header to your API request that contains an access token.
16
+ 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
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://app.dealmaker.tech/developer/applications).
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
- Unde the developer tab, click the `Create New Application` button
22
+ Under the API settings tab, click the `Create New Application` button
23
23
 
24
24
  ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-1.png)
25
25
 
@@ -27,7 +27,7 @@ Name your application and assign the level of permissions for this application
27
27
 
28
28
  ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-2.png)
29
29
 
30
- Once your application is created, save in a secure space your public and secret keys.
30
+ Once your application is created, save in a secure space your client ID and secret.
31
31
 
32
32
  **WARNING**: The secret key will not be visible after you click the close button
33
33
 
@@ -37,13 +37,10 @@ From the developer tab, you will be able to view and manage all the available ap
37
37
 
38
38
  ![Screenshot](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/api-application-4.png)
39
39
 
40
-
41
40
  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.
42
41
 
43
-
44
42
  ## How to generate an access token
45
43
 
46
-
47
44
  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:
48
45
 
49
46
  `token endpoint` - https://app.dealmaker.tech/oauth/token
@@ -54,37 +51,42 @@ After creating an application, you must make a call to obtain a bearer token usi
54
51
 
55
52
  `client_secret` - the Client Secret displayed when you created the OAuth application in the previous step
56
53
 
57
-
58
54
  `scope` - the scope is established when you created the OAuth application in the previous step
59
55
 
60
56
  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.
61
57
 
62
58
  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.
63
59
 
60
+ ### Example
61
+
62
+ #### Postman
63
+
64
+ 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)
65
+
66
+ ![Get access token postman example](https://s3.ca-central-1.amazonaws.com/docs.dealmaker.tech/images/token-postman.png)
67
+
64
68
  # Status Codes
65
69
 
66
70
  ## Content-Type Header
67
71
 
68
-
69
72
  All responses are returned in JSON format. We specify this by sending the Content-Type header.
70
73
 
71
-
72
74
  ## Status Codes
73
75
 
74
76
  Below is a table containing descriptions of the various status codes we currently support against various resources.
75
77
 
76
78
  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.
77
79
 
78
- | Status Code | Description |
80
+ | Status Code | Description |
79
81
  | ----------- | ----------- |
80
- | `200` | Success |
81
- | `403` | Forbiden |
82
- | `404` | Not found |
83
-
82
+ | `200` | Success |
83
+ | `403` | Forbidden |
84
+ | `404` | Not found |
84
85
 
85
86
  # Pagination
86
87
 
87
- 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.
88
+ 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.
89
+
88
90
 
89
91
  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.
90
92
 
@@ -92,49 +94,90 @@ Please review the table below for the input parameters
92
94
 
93
95
  ## Inputs
94
96
 
95
- | Parameter | Description |
96
- | ----------- | ----------- |
97
- | `per_page` | Amount of records included on each page (Default is 25) |
98
- | `page` | Page number |
99
- | `offset` | Amount of records offset on the API request where 0 represents the first record |
97
+ | Parameter | Description |
98
+ | ---------- | ------------------------------------------------------------------------------- |
99
+ | `per_page` | Amount of records included on each page (Default is 25) |
100
+ | `page` | Page number |
101
+ | `offset` | Amount of records offset on the API request where 0 represents the first record |
102
+
103
+ ## Response Headers
104
+
105
+ | Response Header | Description |
106
+ | --------------- | -------------------------------------------- |
107
+ | `X-Total` | Total number of records of response |
108
+ | `X-Total-Pages` | Total number of pages of response |
109
+ | `X-Per-Page` | Total number of records per page of response |
110
+ | `X-Page` | Number of current page |
111
+ | `X-Next-Page` | Number of next page |
112
+ | `X-Prev-Page` | Number of previous page |
113
+ | `X-Offset` | Total number of records offset |
100
114
 
115
+ # Search and Filtering (The q parameter)
101
116
 
102
- ## Respose Headers
117
+ The q optional parameter accepts a string as input and allows you to filter the request based on that string. There are two main ways to filter with it.
103
118
 
104
- 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:
119
+ ## Keyword filtering
105
120
 
121
+ 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.
106
122
 
107
- | Response Header | Description |
108
- | ----------- | ----------- |
109
- | `X-Total` | Total number of records of response |
110
- | `X-Total-Pages` | Total number of pages of response |
111
- | `X-Per-Page` | Total number of records per page of response |
112
- | `X-Page` | Number of current page |
113
- | `X-Next-Page` | Number of next page |
114
- | `X-Prev-Page` | Number of previous page|
115
- | `X-Offset` | Total number of records offset |
123
+ Here’s a list of possible keywords and the “scope” each one of the keywords filters by:
124
+
125
+ | Keywords | Scope | Decoded Example | Encoded Example |
126
+ | ---------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
127
+ | 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` |
128
+ | 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` |
129
+ | 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` |
130
+ | Offline | Investors added to the deal offline | Offline | `Offline` |
131
+ | Online | Investors added to the deal online | Online | `Online` |
132
+ | Signed | Investors who signed their agreement | Signed | `Signed` |
133
+ | Waiting for countersignature | Investors who have signed and are waiting for counter signature | Waiting for countersignature | `Waiting%20for%20countersignature` |
134
+ | Invited | Investors on the Invited Status | Invited | `Invited` |
135
+ | Accepted | Investors in the Accepted Status | Accepted | `Accepted` |
136
+ | Questionnaire in progress | All Investors who have not finished completing the questionnaire | Questionnaire in progress | `Questionnaire%20in%20progress` |
137
+ | Has attachments | All Investors with attachments | Has attachments | `Has%20attachments` |
138
+ | Has notes | All Investors with notes | Has notes | `Has%20notes` |
139
+ | Waiting for co-signature | Investors who have signed and are waiting for co-signature | Waiting for co-signature | `Waiting%20for%20co-signature` |
140
+ | Background Check Approved | Investors with approved background check | Background Check Approved | `Background%20Check%20Approved` |
141
+ | Document Review Pending | Investors with pending review | Document Review Pending | `Document%20Review%20Pending` |
142
+ | Document Upload Pending | Investors with pending documents to upload | Document Upload Pending | `Document%20Upload%20Pending` |
143
+ | Required adjudicator review | Investors who are required to be review by the adjudicator | Required adjudicator review | `Required%20adjudicator%20review` |
144
+
145
+ ---
146
+
147
+ **NOTE**
148
+
149
+ Filtering keywords are case sensitive and need to be encoded
150
+
151
+ ---
152
+
153
+ ## Search String
154
+
155
+ 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.
156
+
157
+ 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.
116
158
 
117
159
  # Versioning
118
160
 
119
161
  The latest version is v1.
120
162
 
121
- The version can be updated on the `Accept` header, just set the version as stated on the following example:
163
+ The version can be updated on the `Accept` header, just set the version as stated on the following example:
122
164
 
123
165
  ```
124
166
 
125
167
  Accept:application/vnd.dealmaker-v1+json
126
168
 
127
169
  ```
128
- | Version | Accept Header |
129
- | ----------- | ----------- |
170
+
171
+ | Version | Accept Header |
172
+ | ------- | ----------------------------------- |
130
173
  | `v1` | application/vnd.dealmaker-`v1`+json |
131
174
 
132
175
  # SDK’s
133
176
 
134
177
  For instruction on installing SDKs, please view the following links
135
178
 
136
- * [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript)
137
- * [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby)
179
+ - [Javascript](https://github.com/DealMakerTech/api/tree/main/v1/clients/javascript)
180
+ - [Ruby](https://github.com/DealMakerTech/api/tree/main/v1/clients/ruby)
138
181
 
139
182
  # Webhooks
140
183
 
@@ -142,28 +185,27 @@ Our webhooks functionality allows clients to automatically receive updates on a
142
185
 
143
186
  The type of data that the webhooks include:
144
187
 
145
- * Investor Name
146
- * Date created
147
- * Email
148
- * Phone
149
- * Allocation
150
- * Attachments
151
- * Accredited investor status
152
- * Accredited investor category
153
- * Status (Draft, Invited, Accepted, Waiting)
188
+ - Investor Name
189
+ - Date created
190
+ - Email
191
+ - Phone
192
+ - Allocation
193
+ - Attachments
194
+ - Accredited investor status
195
+ - Accredited investor category
196
+ - Status (Draft, Invited, Accepted, Waiting)
154
197
 
155
198
  Via webhooks clients can subscribe to the following events as they happen on Dealmaker:
156
199
 
157
- * Investor is created
158
- * Investor details are updated (any of the investor details above change or are updated)
159
- * Investor is deleted
200
+ - Investor is created
201
+ - Investor details are updated (any of the investor details above change or are updated)
202
+ - Investor is deleted
160
203
 
161
204
  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.
162
205
 
163
206
  ## Configuration
164
207
 
165
- 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).
166
-
208
+ 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).
167
209
 
168
210
  As a developer user on DealMaker, you are able to configure webhooks by following the steps below:
169
211
 
@@ -171,9 +213,9 @@ As a developer user on DealMaker, you are able to configure webhooks by followin
171
213
  2. Go to **“Your profile”** in the top right corner
172
214
  3. Access an **“Integrations”** configuration via the left menu
173
215
  4. The developer configures webhooks by including:
174
- * The HTTPS URL where the request will be sent
175
- * 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.
176
- * An email address that will be used to notify about errors.
216
+ - The HTTPS URL where the request will be sent
217
+ - 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.
218
+ - An email address that will be used to notify about errors.
177
219
  5. The developers can disable webhooks temporarily if needed
178
220
 
179
221
  ## Specification
@@ -184,100 +226,95 @@ The initial set of events will be related to the investor. The events are:
184
226
 
185
227
  1. `investor.created`
186
228
 
187
- * Triggers every time a new investor is added to a deal
229
+ - Triggers every time a new investor is added to a deal
188
230
 
189
231
  2. `investor.updated`
190
232
 
191
- * Triggers on updates to any of the following fields:
192
- 1. Status
193
- 2. Name
194
- 3. Email - (this is a user field so we trigger event for all investors with webhook subscription)
195
- 4. Allocated Amount
196
- 5. Investment Amount
197
- 6. Accredited investor fields
198
- 7. Adding or removing attachments
199
- 8. Tags
200
- * When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes
233
+ - Triggers on updates to any of the following fields:
234
+ 1. Status
235
+ 2. Name
236
+ 3. Email - (this is a user field so we trigger event for all investors with webhook subscription)
237
+ 4. Allocated Amount
238
+ 5. Investment Amount
239
+ 6. Accredited investor fields
240
+ 7. Adding or removing attachments
241
+ 8. Tags
242
+ - When the investor status is signed, the payload also includes a link to the signed document; the link expires after 30 minutes
201
243
 
202
244
  3. `investor.deleted`
203
245
 
204
- * Triggers when the investor is removed from the deal
205
- * The investor key of the payload only includes investor ID
206
- * The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of
246
+ - Triggers when the investor is removed from the deal
247
+ - The investor key of the payload only includes investor ID
248
+ - The deal is not included in the payload. Due to our implementation it’s impossible to retrieve the deal the investor was part of
207
249
 
208
250
  ### Requests
209
251
 
210
- * The request is a `POST`
211
- * The payload’s `content-type` is `application/json`
212
- * Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry
213
- * 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
214
- * If an event fails all the attempts to be delivered, we send an email to the address that the user configured
252
+ - The request is a `POST`
253
+ - The payload’s `content-type` is `application/json`
254
+ - Only `2XX` responses are considered successful. In the event of a different response, we consider it failed and queue the event for retry
255
+ - 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
256
+ - If an event fails all the attempts to be delivered, we send an email to the address that the user configured
215
257
 
216
258
  ### Payload
217
259
 
218
260
  #### Common Properties
219
261
 
220
- There will be some properties that are common to all the events on the system.
262
+ There will be some properties that are common to all the events on the system.
221
263
 
222
- |Key|Type|Description|
223
- |--- |--- |--- |
224
- |event|String|The event that triggered the call|
225
- |event_id|String|A unique identifier for the event|
226
- |deal<sup>*</sup>|Object|The deal in which the event occurred. It includes id, title, created_at and updated_at|
264
+ | Key | Type | Description |
265
+ | ----------------- | ------ | -------------------------------------------------------------------------------------- |
266
+ | event | String | The event that triggered the call |
267
+ | event_id | String | A unique identifier for the event |
268
+ | deal<sup>\\*</sup> | Object | The deal in which the event occurred. It includes id, title, created_at and updated_at |
227
269
 
228
-
229
- <sup>*</sup>This field is not included when deleting a resource
270
+ <sup>\\*</sup>This field is not included when deleting a resource
230
271
 
231
272
  #### Common Properties (investor scope)
232
273
 
233
274
  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:
234
275
 
235
- |Key|Type|Description|
236
- |--- |--- |--- |
237
- |id|Integer|The unique ID of the Investor|
238
- |name|String|Investor’s Name|
239
- |status|String|Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted|
240
- |email|String||
241
- |phone_number|String||
242
- |investment_amount|Double||
243
- |allocated_amount|Double||
244
- |accredited_investor|Object|See format in respective ticket|
245
- |attachments|Array of Objects|List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption)|
246
- |funding_state|String|Investor’s current funding state (unfunded, underfunded, funded, overfunded)|
247
- |funds_pending|Boolean|True if there are pending transactions, False otherwise|
248
- |created_at|Date||
249
- |updated_at|Date||
250
- |tags|Array of Strings|a list of the investor's tags, separated by comma.|
251
-
276
+ | Key | Type | Description |
277
+ | ------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------ |
278
+ | id | Integer | The unique ID of the Investor |
279
+ | name | String | Investor’s Name |
280
+ | status | String | Current status of the investor<br />Possible states are: <br />draft<br />invited<br />signed<br />waiting<br />accepted |
281
+ | email | String | |
282
+ | phone_number | String | |
283
+ | investment_amount | Double | |
284
+ | allocated_amount | Double | |
285
+ | accredited_investor | Object | See format in respective ticket |
286
+ | attachments | Array of Objects | List of supporting documents uploaded to the investor, including URL (expire after 30 minutes) and title (caption) |
287
+ | funding_state | String | Investor’s current funding state (unfunded, underfunded, funded, overfunded) |
288
+ | funds_pending | Boolean | True if there are pending transactions, False otherwise |
289
+ | created_at | Date | |
290
+ | updated_at | Date | |
291
+ | tags | Array of Strings | a list of the investor's tags, separated by comma. |
252
292
 
253
293
  ### investor.status >= signed Specific Properties
254
294
 
255
-
256
- |Key|Type|Description|
257
- |--- |--- |--- |
258
- |subscription_agreement|object|id, url (expiring URL)|
295
+ | Key | Type | Description |
296
+ | ---------------------- | ------ | ---------------------- |
297
+ | subscription_agreement | object | id, url (expiring URL) |
259
298
 
260
299
  #### Investor Status
261
300
 
262
301
  Here is a brief description of each investor state:
263
302
 
264
- * **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal
265
- * **Invited:** the investor was added to the platform but hasn’t completed the questionnaire
266
- * **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature)
267
- * **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal
268
- * **Accepted:** the investor's agreement was countersigned by the Signatory
303
+ - **Draft:** the investor is added to the platform but hasn't been invited yet and cannot access the portal
304
+ - **Invited:** the investor was added to the platform but hasn’t completed the questionnaire
305
+ - **Signed:** the investor signed the document (needs approval from Lawyer or Reviewer before countersignature)
306
+ - **Waiting:** the investor was approved for countersignature by any of the Lawyers or Reviewers in the deal
307
+ - **Accepted:** the investor's agreement was countersigned by the Signatory
269
308
 
270
309
  #### Update Delay
271
310
 
272
311
  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.
273
312
 
274
313
 
275
-
276
-
277
314
  This SDK is automatically generated by the [OpenAPI Generator](https://openapi-generator.tech) project:
278
315
 
279
316
  - API version: 1.0.0
280
- - Package version: 0.0.2
317
+ - Package version: 0.0.3
281
318
  - Build package: org.openapitools.codegen.languages.RubyClientCodegen
282
319
 
283
320
  ## Installation
@@ -293,16 +330,16 @@ gem build DealMakerAPI.gemspec
293
330
  Then either install the gem locally:
294
331
 
295
332
  ```shell
296
- gem install ./DealMakerAPI-0.0.2.gem
333
+ gem install ./DealMakerAPI-0.0.3.gem
297
334
  ```
298
335
 
299
- (for development, run `gem install --dev ./DealMakerAPI-0.0.2.gem` to install the development dependencies)
336
+ (for development, run `gem install --dev ./DealMakerAPI-0.0.3.gem` to install the development dependencies)
300
337
 
301
338
  or publish the gem to a gem hosting service, e.g. [RubyGems](https://rubygems.org/).
302
339
 
303
340
  Finally add this to the Gemfile:
304
341
 
305
- gem 'DealMakerAPI', '~> 0.0.2'
342
+ gem 'DealMakerAPI', '~> 0.0.3'
306
343
 
307
344
  ### Install from Git
308
345
 
@@ -352,6 +389,7 @@ Class | Method | HTTP request | Description
352
389
  *DealMakerAPI::DealApi* | [**create_investor**](docs/DealApi.md#create_investor) | **POST** /deals/{id}/investors | Create a deal investor
353
390
  *DealMakerAPI::DealApi* | [**get_deal**](docs/DealApi.md#get_deal) | **GET** /deals/{id} | Get a deal by id
354
391
  *DealMakerAPI::DealApi* | [**get_investor**](docs/DealApi.md#get_investor) | **GET** /deals/{id}/investors/{investor_id} | Get a deal investor by id
392
+ *DealMakerAPI::DealApi* | [**list_deals**](docs/DealApi.md#list_deals) | **GET** /deals | List available deals
355
393
  *DealMakerAPI::DealApi* | [**list_investors**](docs/DealApi.md#list_investors) | **GET** /deals/{id}/investors | List deal investors
356
394
  *DealMakerAPI::InvestorProfileApi* | [**create_investor_profile**](docs/InvestorProfileApi.md#create_investor_profile) | **POST** /investor_profiles | Create new investor profile
357
395
 
@@ -365,6 +403,7 @@ Class | Method | HTTP request | Description
365
403
  - [DealMakerAPI::V1EntitiesDealFundingMetrics](docs/V1EntitiesDealFundingMetrics.md)
366
404
  - [DealMakerAPI::V1EntitiesDealInvestorMetrics](docs/V1EntitiesDealInvestorMetrics.md)
367
405
  - [DealMakerAPI::V1EntitiesDealIssuer](docs/V1EntitiesDealIssuer.md)
406
+ - [DealMakerAPI::V1EntitiesDeals](docs/V1EntitiesDeals.md)
368
407
  - [DealMakerAPI::V1EntitiesInvestor](docs/V1EntitiesInvestor.md)
369
408
  - [DealMakerAPI::V1EntitiesInvestorProfileIndividual](docs/V1EntitiesInvestorProfileIndividual.md)
370
409
  - [DealMakerAPI::V1EntitiesInvestorUser](docs/V1EntitiesInvestorUser.md)