| VARIABLE | INITIAL VALUE | CURRENT VALUE |
|---|---|---|
| baseUrl | https://api.getarbjournal.com/v1 | https://api.getarbjournal.com/v1 |
| bearerToken | {GENERATED_KEY} | {GENERATED_KEY} |
{{bearerToken}}.
You should now be all set up but, just to be sure, we'll do one simple request to the API to verify if all the previous steps were done properly. If anything went wrong, just contact our support team and they will help you with the steps.
{{baseUrl}}/locations and click the
Send button.
In order to be able to send requests to our API to fetch and modify data, you will need to authenticate every request you make on it.
Authenticate by adding the following HTTP header to your requests:
Authorization: bearer {{token}}
The token can be generated in your ArbJournal account. Go to "Settings >
Integrations > API
Keys" to generate a key for your user.
| Security Scheme Type | HTTP Authorization Scheme | Bearer Format |
|---|---|---|
| HTTP | Bearer | JWT |
When using a token that can be used on multiple organizations, you will need to pass a header to indicate the organization you are referring to in all your calls:
x-organization-id: {{organizationId}}
The header is required for multi-organization tokens. A 400 code will be returned if you're using a token for multiple organizations but didn't pass the required header.
Deal Id along with URL as suffix
As the name indicates, it returns complete detail about a single deal based on the provided ID.
bearerJWT|
id
required
|
integer
Example: 1 ID of the asset |
|
id
required
|
integer
Global ID of the category. |
|
id
required
|
integer
Global ID of the category. |
This endpoint returns a list of deals based on the provided search criteria. This endpoint has multiple configurable parameters. Out of which the summary parameter can be leveraged to pull complete details about multiple deals. By default, the summary parameter is set to yes. This would return only a summarized overview of the deal. But this parameter can be set to no, to return list of deals along with its full details of each deal, similar to the output of Deals By ID API. The search criteria will be supplied as http query parameters. It is not necessary to supply all the search criteria parameters.
bearerJWTPOST Status to set
| summary |
string Default Yes |
| offset |
int Default 0 |
| limit |
int Default 10 |
| timezone |
string Universal Time Coordinated |
| keywords |
string comma separated strings |
| aquirer_name |
string company name |
| aquirer_ticker |
string company ticker |
| target_name |
string target name |
| target_ticker |
string target ticker |
| status |
string Any Active Inactive“Any” which means return both active and inactive deals. “Active” which means return only active deals. “Inactive” which means return only inactive deals. |
| service |
string Any US EU Dual |
| type |
string Financial Strategic |
| value |
string < 200 Million | 200 Million - 1 Billion |> 1 Billion |
| failed_deals |
string failed_deals string Antitrust Other Regulatory Mutual Consent Financing SH Vote Failure MAC Breach Superior Bid |
| consideration_type |
string Cash & Stock Exchange Cash Merger Cash Tender Stock Exchange Stock Tender |
| consideration_terms |
string consideration terms |
| other_considerations |
string ADR/ADS No ADR/ADS, CVR No CVR |
| industry |
string industry |
| jurisdiction |
string jurisdiction |
| hsr_second_request |
string Yes No |
| enforcement_action |
string Yes No |
| financing_condition |
string Yes No |
| marketing_period |
string Yes No |
| go_shop_period |
string Yes No |
| announced_start_date |
DateTime yyyy-MM-ddFetches all deals that are announced on or after the provided date |
| announced_end_date |
DateTime yyyy-MM-ddFetches all deals that are announced on or before the provided date |
| announced_end_date |
DateTime yyyy-MM-ddFetches all deals that are announced on or before the provided date |
| completion_start_date |
DateTime yyyy-MM-ddFetches all deals that are completed on or after the provided date |
| completion_end_date |
DateTime yyyy-MM-ddFetches all deals that are completed on or before the provided date |
| journal_alert_start_date |
DateTime yyyy-MM-ddFetches all deals that are journal details created on or after the provided date |
| journal_alert_end_date |
DateTime yyyy-MM-ddFetches all deals that are journal details created on or before the provided date |
| deal_created_start_date |
DateTime DateTimeFetches all deals that are created on or after the provided date |
| deal_created_end_date |
DateTime yyyy-MM-ddFetches all deals that are created on or before the provided date |
| deal_updated_start_date |
DateTime yyyy-MM-ddFetches all deals that are updated on or after the provided date |
| deal_updated_end_date |
DateTime yyyy-MM-ddFetches all deals that are updated on or before the provided date |
|
id
required
|
integer
Global ID of the category. |
|
id
required
|
integer
Global ID of the category. |
Arbjournal API has some rate limits to protect its infrastructure and to allow everybody to use the API fairly in respect to other users. When it comes to rate limiting with ArbJournal you can check the data returned by the three rate limiting headers included in each response from our API. We highly recommend doing this because it keeps you compatible and ensures you will automatically benefit from any limit increase we can give you.
Currently our API gateway is rate limited with 10 requests every 5 minutes, so that would require a minimum delay of 30 seconds between requests.
Arbjournal API Services have an overall limit of 15 requests per day that needs to be considered, when consuming the APIs.
Arbjournal Trial API Services have a Total limit of 15 requests. (Not per day but overall limit of 15 requests).
This would mean the above mentioned daily limit has been reached (15 requests / day). Once the limit has been reached, users would require to wait till next day to start sending requests again.
Currently the only API that can return large number of deals is the Search API. We recommend using this endpoint with a limit of 500 records per request using the limit parameter.
Currently we have 15 requests per day, our recommended limit per request is 500, so 15 * 500 = 7500, that would mean users can pull in all records in a single day since we have only ~6850 records.
The "summary" parameter dictates whether deal details should be summarized, returning only an overview. When set to "yes," the API provides a brief summary of the deals.
Alternatively, setting it to "no" results in the retrieval of detailed information for each deal in the list. The information returned for each deal resembles calling the Deal By ID API to fetch comprehensive details.