Getting Started

Using Postman to test your requests

  1. Download the Postman application from the web.
  2. Open the Postman application and click the Environment tab on the left side of the application.
  3. Select the Globals option in the newly shown panel located to the right of the Environment tab.
  4. Now, we will add two variables, these two variables will be globals throughout Postman and help you do the operations that you need to do with the API. You can refer to the table at the end of this section or just follow the steps below.
    1. Add a new variable and name it baseUrl, which will be used to link your Postman to the Arbjournal API. Copy-paste the URL, https://api.getarbjournal.com/v1, into the Initial Value column.
    2. Add another variable named bearerToken, you will need this one in a following step. This variable is used to authenticate you to be allowed to send requests to our API via what we call a Bearer Token. To retrieve a key, go to Settings > API Keys, generate a key and paste it into the Initial Value column.
    3. Be sure that you click on the Save button at the top right corner of the Globals panel.
    VARIABLE INITIAL VALUE CURRENT VALUE
    baseUrl https://api.getarbjournal.com/v1 https://api.getarbjournal.com/v1
    bearerToken {GENERATED_KEY} {GENERATED_KEY}
  5. Now press the Import button which is located above the panel where you just added the global variables.
    1. In the newly shown window, click the Link tab and copy the URL (or all of its content), https://api.getarbjournal.com/v1/openapi.json, into the Enter a URL field and then click Continue and follow the steps to proceed to the importation.
    2. Now, a new collection named ArbJournal API should be imported giving you access to all our API endpoints.
  6. Before testing any endpoint, please make sure the API key is defined in the Bearer Token area. Bearer Token allows requests to authenticate using an access key.
    1. Select the root of the ArbJournal API collection and then click the Authorization tab and select Bearer Token in the dropdown list named Type.
    2. In the Token field, write the name of the second global variable (bearerToken) you have created in a previous step and surround it with two curly braces like this: {{bearerToken}}.

Here's how to test your Postman configuration

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.

  1. Expand the ArbJournal API collection.
  2. Expand the locations node.
  3. Click on the one named List locations and in the GET section, just remove all the parameters to have the following: {{baseUrl}}/locations and click the Send button.
  4. In the Response part of the screen, normally at the bottom, you should have a JSON response containing your organization's locations.

Authentication

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.

Bearer

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

Multi-Organization Token

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.

ArbJournal API

Deals by ID
Deal Id along with URL as suffix

As the name indicates, it returns complete detail about a single deal based on the provided ID.

HTTP Authorization Scheme: bearer
Bearer format: JWT
Path Parameters
id
required
integer

Example: 1

ID of the asset

Responses

Response Schema: application/json
id
required
integer

Global ID of the category.

Response Schema: application/json
id
required
integer

Global ID of the category.

https://arbjournal.azure-api.net/basic/api/trail/Deals

Deals by Search Criteria

HTTP: Bearer

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.

HTTP Authorization Scheme: bearer
Bearer format: JWT

Request Body schema: POST

POST 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-dd

Fetches all deals that are announced on or after the provided date

announced_end_date

DateTime

yyyy-MM-dd

Fetches all deals that are announced on or before the provided date

announced_end_date

DateTime

yyyy-MM-dd

Fetches all deals that are announced on or before the provided date

completion_start_date

DateTime

yyyy-MM-dd

Fetches all deals that are completed on or after the provided date

completion_end_date

DateTime

yyyy-MM-dd

Fetches all deals that are completed on or before the provided date

journal_alert_start_date

DateTime

yyyy-MM-dd

Fetches all deals that are journal details created on or after the provided date

journal_alert_end_date

DateTime

yyyy-MM-dd

Fetches all deals that are journal details created on or before the provided date

deal_created_start_date

DateTime

DateTime

Fetches all deals that are created on or after the provided date

deal_created_end_date

DateTime

yyyy-MM-dd

Fetches all deals that are created on or before the provided date

deal_updated_start_date

DateTime

yyyy-MM-dd

Fetches all deals that are updated on or after the provided date

deal_updated_end_date

DateTime

yyyy-MM-dd

Fetches all deals that are updated on or before the provided date

Responses

Response Schema: application/json
id
required
integer

Global ID of the category.

Response Schema: application/json
id
required
integer

Global ID of the category.

https://arbjournal.azure-api.net/api/Search/Deals

Rate Limiting

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.