Developer Documentation

Bridgewise Integration Guide

Complete guide to integrating Bridgewise APIs and Widgets into your applications. Learn authentication, identifier conversion, API consumption patterns, and widget embedding.

≡ Contents

Part 1: Foundation

→ Introduction & Overview
→ Authentication (M2M)
→ Identifier Conversion

Part 2: Implementation

→ API Consumption Model
→ Widget Integration
→ Error Handling & Best Practices

Foundation

Introduction & Overview Authentication (Machine-to-Machine)

Step 1: Obtain Your Credentials Step 2: Request an Access Token Common Error Codes & Messages Step 3: Using Your Access Token

Identifier Conversion

Identifier Conversion

Understanding the Identifier Hierarchy The identifier-search Endpoint Example 1: Converting Tesla (Ticker-Exchange) Example 2: Converting Apple (ISIN) Understanding Multiple Listings Example: Retrieving Company Data

API Consumption Model

API Consumption Model

What is On-Demand Consumption? Why On-Demand is Superior Implementation Checklist B2B API Integration Flow

Widget Integration (Optional)

Widget Integration

What are Bridgewise Widgets? How Widget Integration Works

→ Next Steps & Support

◎ Introduction

Welcome to the Bridgewise API and Widget Integration Guide. This comprehensive documentation is designed for developers who seek to seamlessly integrate Bridgewise financial services into their applications. Our aim is to equip you with all the necessary information to effectively interact with our APIs and embed our widgets, enabling you to harness a wealth of financial data and AI-driven insights with ease.

What You'll Learn

Authentication

How to obtain and manage Machine-to-Machine access tokens for secure API and widget access

Identifier Conversion

Converting global identifiers (ISIN, Ticker-Exchange) to Bridgewise internal IDs

⚡

API Consumption

Understanding on-demand compute patterns, caching strategies, and performance optimization

Widget Embedding

Integrating Bridgewise widgets into web and mobile applications via iframe

➜ Overview: The Bridgewise Platform

The Bridgewise API stands out as a leading interface to a vast expanse of global financial information, covering nearly all publicly traded companies and ETFs worldwide. Built on a RESTful architecture, the platform ensures smooth integration and compatibility with modern development practices.

Platform Capabilities

Raw Numerical Data

Access comprehensive financial data including fundamentals, market data, technical indicators, and historical price series across global markets.

AI-Driven Recommendations

Leverage proprietary AI models that analyze market conditions, company fundamentals, and sentiment to provide actionable investment recommendations.

Insightful Textual Analyses

Get AI-generated narratives, summaries, and insights available in multiple native languages (en-US, ja-JP, and more) for global deployment.

i Coverage & Scale

The Bridgewise platform provides data and insights for tens of thousands of publicly traded companies and ETFs across major global exchanges, including NYSE, NASDAQ, LSE, TSE, HKEX, and many more.

High-Level Integration Journey

Understanding the end-to-end integration flow will help you plan your implementation effectively. Here's the complete journey from initial setup to production deployment:

Obtain Credentials

Contact Bridgewise support to receive your Application Client ID and Secret Key. These credentials are unique to your organization and grant access to licensed services.

support@bridgewise.com

Implement Backend Authentication

Your backend service calls the Bridgewise authentication endpoint with your credentials to receive an Access Token. This token is valid for 24 hours and should be securely stored and reused across all API and widget requests.

Convert External Identifiers

Use the identifier-search endpoint to convert your existing identifiers (ISIN or Ticker-Exchange) into Bridgewise internal IDs (company_id, trading_item_id).

Consume APIs On-Demand

Make API calls using your access token and Bridgewise IDs. Follow the on-demand consumption model—request data exactly when needed (user interaction, page load) to leverage CloudFront caching for optimal performance.

Embed Widgets (Optional)

For UI components, embed Bridgewise widgets using iframes. Pass the access token and required parameters via URL. Widgets handle data fetching, theming, and send events back to your application via postMessage.

Monitor & Handle Errors

Implement error handling for authentication failures (401/403), network issues, and rate limits. Log events, refresh tokens when needed, and provide graceful fallbacks for end users.

! Prerequisites

Before proceeding with this guide, ensure you have received your Application Client ID and Secret Key from Bridgewise. If you haven't received these credentials, contact our support team at support@bridgewise.com.

↑ Back to Top

Part 1: Authentication (Machine-to-Machine)

Authentication is the foundation of secure access to Bridgewise services. This section walks you through the Machine-to-Machine (M2M) authentication process, which is essential for protecting the security and integrity of your organization's data and ensuring safe access to Bridgewise APIs and Widgets.

What is M2M Authentication?

Machine-to-Machine (M2M) tokens allow secure communication between services or applications without user involvement. Unlike user authentication, M2M authentication represents the identity of an application rather than an individual user.

Key Characteristics:

→ Issued to Applications

Represents application identity, not user identity

→ 24-Hour Validity

Tokens expire after 24 hours and must be refreshed

→ Scoped Permissions

Access rights based on your license and needs

→ No User Context

Used solely for service-to-service authentication

1 Step 1: Obtain Your Credentials

To begin the authentication process, you need valid credentials from Bridgewise. These credentials are unique to your organization and grant access only to the services you are licensed for.

Required Credentials

application_client_id

Your unique application identifier. This ID represents your organization and determines which Bridgewise services you can access.

secret

Your secret key for secure authentication. This should be stored securely and never exposed in client-side code or version control systems.

▲ Security Best Practices

Never expose credentials in frontend code — Always handle authentication server-side
Store credentials securely — Use environment variables or secure vault services
Rotate credentials periodically — Contact support if credentials are compromised
Don't commit to version control — Add credential files to .gitignore

i Need Credentials?

If you have not received your Application Client ID and Secret Key, please contact our support team at support@bridgewise.com. Our team will verify your organization's license and provide the necessary credentials.

2 Step 2: Request an Access Token

Once you have your credentials, the next step is to exchange them for an Access Token. This token grants your application secure access to Bridgewise services for 24 hours.

Authentication Endpoint

POST
https://rest.bridgewise.com/users/authenticate

This endpoint is available in any Bridgewise product Swagger documentation. For example: StockWise API Documentation.

Request Example cURL

curl -X 'POST' \
  'https://rest.bridgewise.com/users/authenticate' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "application_client_id": "{YOUR_APPLICATION_CLIENT_ID}",
  "secret": "{YOUR_SECRET_KEY}"
}'

Response 200 OK

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 86400
}

! Important Token Management Rules

Tokens work with APIs and Widgets — Use the same token for both API calls and widget embedding
Tokens expire after 24 hours — You must request a new token daily
Store tokens securely server-side — Reuse the same token across multiple requests
Implement refresh logic — Automatically request a new token when receiving 401/403 errors
License-based access — Tokens grant access only to services your organization is licensed for

Understanding Token Scoping

Access tokens are tied to your Application Client ID and grant access only to the services your organization is licensed for. This means:

✓ Authorized Services

You can access all APIs and widgets that are included in your license agreement with Bridgewise

✗ Unauthorized Services

Attempting to access unlicensed services will result in a 403 Forbidden error with a clear message

▲ Common Error Codes & Messages

Understanding error responses helps you implement robust error handling and provide better user experiences. Here are the common authentication errors you may encounter:

Case	Code	Message & Resolution
Token value is empty	401	Message: Bridgewise requires an authenticated token. Please see documentation for obtaining a token or contact support@bridgewise.com. Resolution: Ensure your Authorization header includes a valid Bearer token
Token is invalid	403	Message: Invalid token. Please see documentation for obtaining a token or contact support@bridgewise.com. Resolution: Token may be malformed, expired, or corrupted. Request a new token.
Token is unauthorized	403	Message: Your token does not allow access to this service. Contact your admin or support@bridgewise.com. Resolution: You're trying to access a service not included in your license. Contact support to upgrade.
Authorizer general error	403	Message: Internal error. Please contact support@bridgewise.com. Resolution: This is a server-side issue. Contact Bridgewise support with request details.
Bad request (invalid parameter)	400	Message: The request contains invalid parameters. Please verify your request and refer to the documentation for correct usage. Resolution: Review your request payload. Ensure all required fields are present and properly formatted.

3 Step 3: Using Your Access Token

Once you have obtained an access token, you can use it to authenticate both API requests and widget integrations. The token is passed differently depending on whether you're making API calls or embedding widgets.

API

Using Tokens with API Requests

For API requests, include the access token in the Authorization header using the Bearer authentication scheme:

API Request Example

curl --location 'https://rest.bridgewise.com/companies/27444752' \
  --header 'Content-Type: application/json' \
  --header 'authorization: Bearer {{ACCESS_TOKEN}}'

✓ Key Points for API Usage:

Use Bearer prefix before the token
Include the token in every API request
Store the token securely server-side and reuse it for 24 hours
Implement automatic token refresh when you receive 401/403 errors

Using Tokens with Widgets

For widget embedding, pass the access token as the accessToken URL parameter in the iframe source:

Widget Integration Example

<iframe 
  id="bridgewise-widget" 
  src="https://embeded.bridgewise.com/en-US/{{TENANT_NAME}}/{{WIDGET_NAME}}?accessToken={{ACCESS_TOKEN}}&identifier={{IDENTIFIER}}" 
  style="width: 100%; border: 0; height: 400px;">
</iframe>

▲ Security Reminder:

Keep your access token server-side whenever possible. If you must expose it in a client context (e.g., for widget embedding), ensure you refresh it daily and limit the scope of what the token can access. Never expose your Client ID and Secret on the client side.

Token Management Best Practices

↻

Automatic Refresh

Implement a scheduled job to refresh tokens every 24 hours, or immediately when authentication errors occur.

Secure Storage

Store tokens in secure backend storage (environment variables, key vaults) never in frontend code or version control.

Token Reuse

One token per 24 hours is sufficient. Reuse the same token across all requests rather than requesting new tokens for each call.

▦

Monitor & Log

Log authentication events, track token refresh cycles, and monitor for repeated authentication failures.

↻ Part 2: Identifier Conversion

All identifiers within the Bridgewise API are internal, but the platform seamlessly supports conversion from globally recognized identifiers such as ISIN and Ticker-Exchange. This section explains how to convert your existing identifiers into Bridgewise's internal system, which is essential for all subsequent API calls.

! Critical Prerequisite

Converting identifiers using the identifier-search endpoint is mandatory before you can use any other Bridgewise API endpoints. Nearly every API endpoint requires either a company_id or trading_item_id, which you obtain through identifier conversion.

Why Identifier Conversion Matters

? Foundation for All API Calls

The company_id returned by identifier-search is used in nearly all Bridgewise API endpoints for retrieving company data, recommendations, fundamentals, news, and more.

? Global Compatibility

Convert from industry-standard identifiers (ISIN, Ticker-Exchange) that your systems already use, making integration seamless without needing to rebuild your data infrastructure.

⊕ Unified Reference System

Bridgewise internal IDs provide a unified reference that works across all products (StockWise, FundWise, ETFWise, etc.) regardless of how a security trades on different exchanges.

? Understanding the Identifier Hierarchy

Bridgewise uses a three-tier identifier hierarchy. Understanding this structure is crucial for making effective API calls:

company_id

Company-Level Identifier

The internal Bridgewise identifier for the company entity. This is the primary identifier used for most API endpoints.

Example Use Cases:

Company metadata & profile information
Financial fundamentals (income statement, balance sheet, cash flow)
AI recommendations and insights
Corporate actions and news

security_id

Security-Level Identifier

Identifies a specific security type issued by the company (e.g., Common Stock, Preferred Stock, Class A shares).

▲ Important Note:

The security_id is NOT used in Bridgewise API calls. It's provided for informational purposes but is not required for any endpoints.

trading_item_id

Trading/Listing-Level Identifier

Identifies a specific tradable listing (Ticker + Exchange combination). A company/security may have multiple listings across different exchanges.

Example Use Cases:

Price series and historical market data
Technical indicators (RSI, MACD, etc.)
Exchange-specific information

i Quick Rule of Thumb

Use company_id for most company-level endpoints (fundamentals, recommendations, profile).

Use trading_item_id when you need exchange-specific data (price series, technical indicators).

⇄ The identifier-search Endpoint

The identifier-search endpoint is your entry point for converting external identifiers into Bridgewise internal IDs. This endpoint accepts both ISIN and Ticker-Exchange formats.

Endpoint Information

HTTP METHOD

GET

BASE URL

https://rest.bridgewise.com/identifier-search

DOCUMENTATION

View in Swagger Docs →

Request Parameters

identifier_type REQUIRED

Specifies the format of the identifier you are sending. This tells Bridgewise how to interpret your input.

Supported Values:

ticker_exchange For Ticker-Exchange combinations (e.g., AAPL-NASDAQ)

isin For International Securities Identification Numbers

identifier REQUIRED

The actual global identifier you want to convert into Bridgewise internal IDs.

Format Examples:

TSLA-NASDAQ Ticker-Exchange format

US0378331005 ISIN format

1 Example 1: Converting Tesla (Ticker-Exchange)

In this example, we submit the Tesla stock symbol to the identifier-search endpoint using the ticker_exchange format.

Request cURL

curl -X 'GET' \
  'https://rest.bridgewise.com/identifier-search?identifier=TSLA-NASDAQ&identifier_type=ticker_exchange' \
  -H 'accept: application/json'

Response 200 OK

{
  "company_name": "Tesla, Inc.",
  "company_id": 27444752,
  "identifiers": [
    {
      "security_id": 108803914,
      "security_name": "Common Stock",
      "security_primary_flag": true,
      "trading_item_ids": [
        {
          "trading_item_id": 108803915,
          "trading_item_id_primary_flag": true,
          "ticker_symbol": "TSLA",
          "exchange_symbol": "NasdaqGS",
          "exchange_name": "Nasdaq Global Select",
          "exchange_id": 458,
          "exchange_importance_level": 3
        }
      ]
    }
  ]
}

Response Field Breakdown

Field	Example Value	Description
`company_name`	Tesla, Inc.	Full legal name of the company
`company_id` CRITICAL	27444752	Bridgewise internal identifier for the company. Use this for most API endpoints.
`security_id`	108803914	Security type identifier (Common Stock). Not used in API calls.
`security_name`	Common Stock	Type of security (Common Stock, Preferred, etc.)
`security_primary_flag`	true	Whether this is the primary security type for the company
`trading_item_id` IMPORTANT	108803915	Trading listing identifier. Use for exchange-specific data like prices.
`trading_item_id_primary_flag`	true	Whether this is the primary trading listing (use this when multiple exchanges returned)
`ticker_symbol`	TSLA	Stock ticker symbol
`exchange_symbol`	NasdaqGS	Exchange code where the security is listed
`exchange_name`	Nasdaq Global Select	Full name of the exchange
`exchange_id`	458	Bridgewise internal exchange identifier
`exchange_importance_level`	3	Importance ranking of the exchange (higher = more trading volume)

2 Example 2: Converting Apple (ISIN)

If your system uses ISINs, you can convert them just as easily by setting identifier_type=isin.

Request cURL

curl -X 'GET' \
  'https://rest.bridgewise.com/identifier-search?identifier=US0378331005&identifier_type=isin' \
  -H 'accept: application/json'

i Response Structure is Identical

The response structure for ISIN queries is exactly the same as ticker_exchange queries. You will still receive company_id, and may get multiple listings under trading_item_ids if the security trades on multiple exchanges.

▦ Understanding Multiple Listings

Some companies have securities that trade on multiple exchanges or have multiple security types (Common Stock, Preferred Stock, etc.). Understanding how to handle these scenarios is important for proper implementation.

Real-World Example: Tesla's Multiple Listings

Tesla's stock, for example, trades on 7 different exchanges with 4 different ISINs. However, all these listings are unified under a single company_id.

Company Entity

Tesla Inc.

company_id: 27444752

Security Type

Common Stock

security_id: 108803914

Trading Items:

TSLA-NASDAQ ⭐

TSLA-XETRA

TL0-FSX

Security Type

ADR

security_id: 14711863

Trading Items:

TSLA-NEOE

Security Type

Receipt

security_id: 60979158

Trading Items:

TSLA-BATS

TSLA-BASF

⭐ = Primary Trading Item (trading_item_id_primary_flag: true)

✓ Key Takeaways:

All listings share the same company_id (27444752)
Multiple security types can exist (Common Stock, ADR, Receipt)
One security type is marked as primary (security_primary_flag: true)
One trading item per security is marked as primary (trading_item_id_primary_flag: true)
Use the primary flags to select the main listing when multiple exist

How to Handle Multiple Results

For Company-Level Data

Use the company_id directly. It doesn't matter which listing returned it—all listings for the same company share the same company_id.

For Exchange-Specific Data

When you need a trading_item_id and multiple are returned:

Preferred approach: Use the listing where trading_item_id_primary_flag: true
Alternative: Filter by exchange based on your requirements (e.g., prefer US exchanges over international)
Advanced: Use exchange_importance_level to rank exchanges (higher = more important)

↓ Example: Retrieving Company Data

Once you have obtained a company_id from identifier-search, you can use it to query any company-level endpoint in the Bridgewise API.

Example: Get Company Metadata

Using Tesla's company_id (27444752), we can retrieve comprehensive company information:

Request cURL

curl -X 'GET' \
  'https://rest.bridgewise.com/companies/27444752?language=en-US' \
  -H 'accept: application/json' \
  -H 'authorization: Bearer {{ACCESS_TOKEN}}'

Response (Sample) 200 OK

[
  {
    "updated_at": "2023-10-29T00:16:10.423475",
    "language": "en-US",
    "company_name": "Tesla Inc.",
    "company_name_short": "Tesla",
    "website": "www.tesla.com",
    "primary_ticker_symbol": "TSLA",
    "primary_exchange_symbol": "NasdaqGS",
    "region_name": "United States and Canada",
    "incorporation_country_name": "United States",
    "gics_sector_name": "Consumer Discretionary",
    "gics_industry_name": "Automobiles",
    "primary_currency_market_iso3": "USD",
    ...
  }
]

i Why the Language Parameter Matters

Many Bridgewise endpoints return textual insights and AI-generated content that are localized. Always include the language parameter (e.g., en-US, ja-JP, de-DE) to receive content in your desired language.

⚡ Part 3: API Consumption Model

Understanding how to properly consume the Bridgewise API is critical for achieving optimal performance, scalability, and cost-efficiency. Bridgewise APIs are designed to operate in an on-demand (compute-on-request) model, which delivers significant advantages over traditional offline processing approaches.

What is On-Demand Consumption?

On-demand consumption means requesting data exactly when it is needed—triggered by user interaction, page load, or workflow events—rather than precomputing and storing results in advance.

Examples of On-Demand Usage:

User opens a stock detail page → API fetches company data in real-time
User searches for a ticker → API converts identifier and returns results
Portfolio rebalancing tool runs → API fetches current recommendations
Widget loads in browser → Widget calls API with current access token

✗ NOT for Offline Processing

Bridgewise APIs should not be used for offline processing workflows where results are calculated in advance, stored, and then served from your own database. This pattern defeats the purpose of the on-demand model and prevents you from leveraging Bridgewise's caching infrastructure.

Why On-Demand is Superior

⚡

Better Performance & Lower Latency

You fetch only what is needed, when it is needed. By leveraging Bridgewise's caching mechanisms (CloudFront CDN), responses are significantly faster and more efficient.

How CloudFront Caching Works:

First Request: When the first user requests Apple's data, Bridgewise computes the response and caches it at the CloudFront CDN layer.

Subsequent Requests: Other users requesting the same data receive it directly from CloudFront—served from the edge location closest to them.

Result: Latency is dramatically reduced (often under 100ms), while backend load is minimized.

Higher Reliability

Avoids traffic spikes caused by heavy offline batch recalculations. Load is distributed naturally based on actual user demand.

↻

Fresher Data

Results reflect real-time calculations rather than potentially stale stored snapshots. Users always get the latest insights.

▦

Scalable Architecture

Aligns naturally with CDN caching and distributed compute models. No need to build complex offline processing infrastructure.

Cost Efficient

Reduces compute costs by eliminating the need for continuous background processing and large-scale data storage.

! What NOT to Do: Offline/Precomputed Processing

Offline processing refers to a model where:

Results are calculated ahead of time (batch jobs, scheduled tasks)
Computed data is stored in your own database
When users request data, it's served from your stored copies
Computation happens in advance rather than at request time

This model is the opposite of compute-on-request and does not align with the intended usage pattern of Bridgewise APIs. It bypasses caching benefits, increases latency, and requires you to maintain complex data pipelines.

✓ Quick Implementation Checklist

✓

Usage: On-Demand only (not offline processing)

✓

Trigger: User-driven or workflow-driven calls

✓

Caching: Leverage CDN caching behavior (don't build your own)

✓

Design Principle: Compute on request, not in advance

B2B API Integration Flow

For B2B partners who integrate Bridgewise API into their own platforms, the integration follows a secure, token-based model where the partner acts as the trusted intermediary between their end-customers and Bridgewise.

How It Works

The flow is straightforward:

The customer authenticates directly with the Partner platform.

The Partner receives credentials per customer from Bridgewise.

The Partner obtains a single Access Token based on customer credentials to communicate with Bridgewise.

Once authenticated, the Partner sends requests on demand to the Bridgewise API with the relevant customer token.

In each request user_id must be provided.

i Important Notes

Bridgewise interaction with customers is only in the credentials creation or permissions changes.
All customer authentication is handled entirely by the Partner.
Bridgewise only trusts and communicates with the Partner as an authorized intermediary.

In short: Customers log in to the Partner platform, and the Partner securely connects to Bridgewise using a customer-specific token.

B2B Integration Architecture

BridgeWise

BridgeWise API

Access
Token

←

→

Partner

Partner Web API

↑

↓

Partner API Gateway

Authentication
Token

←

→

⛻

Customer

Authentication Store

Access Token Details:

Requested per customer by the Partner (not specific to an end-user session)
Bridgewise does not know or interact with the Partner’s end-customers directly
Shared between instances of the Partner’s Web API for the same customer

In addition to direct API access, Bridgewise offers pre-built UI widgets that you can embed in your web or mobile applications. Widgets provide a complete user interface with data fetching, theming, and interactivity built-in, requiring minimal integration effort on your side.

i Dedicated Widget Documentation

Widget integration has its own comprehensive documentation. This guide provides a high-level overview. For detailed widget implementation, including specific widget types, parameters, events, and advanced features, please refer to the Widget Integration Guide in the support portal.

Bridgewise widgets are iframe-based embeddable UI components that provide rich financial interfaces without requiring you to build complex frontend experiences from scratch.

AI Chat Interfaces

Interactive chat widgets powered by Bridget AI that can answer financial questions, provide recommendations, and guide users.

▦

Data Visualization

Pre-built charts, tables, and visual components displaying company data, fundamentals, price history, and more.

Recommendation Cards

Compact widgets showing AI-driven buy/sell/hold recommendations with supporting insights and confidence levels.

Search & Discovery

Search interfaces and teasers that help users discover and explore financial instruments.

Widgets are embedded using HTML <iframe> elements. The widget URL contains all necessary parameters including your access token, language preferences, and widget-specific configuration.

Basic Widget Embedding Example

<iframe 
  id="bridgewise-widget"
  src="https://embeded.bridgewise.com/en-US/{{TENANT_NAME}}/{{WIDGET_NAME}}?accessToken={{ACCESS_TOKEN}}&identifier={{IDENTIFIER}}"
  style="width: 100%; border: 0; height: 400px;">
</iframe>

URL Parameter Breakdown:

en-US Language code (en-US, ja-JP, de-DE, etc.)

TENANT_NAME Your organization's tenant identifier

WIDGET_NAME Specific widget type (bridget-chat, bridget-teaser, etc.)

ACCESS_TOKEN Your M2M access token from authentication

IDENTIFIER Company identifier, ticker, or other context (widget-specific)

Widget Communication & Events

Widgets communicate with your application via the browser's postMessage API. This enables bidirectional communication for events like:

→ Widget Load Events

Notify your app when the widget has finished loading

→ Resize Events

Dynamically adjust iframe height based on content

→ Navigation Events

User clicks requiring navigation to other pages

→ Error Events

Authentication or network errors requiring attention

? Full Details in Widget Guide

For complete event schemas, JavaScript listener examples, and advanced widget configuration, refer to the dedicated Bridget Widget Integration Guide.

? Support & Contact

Email Support

For technical questions, credential requests, or integration assistance

support@bridgewise.com

Support Portal

Browse articles, submit tickets, and access additional documentation

support.bridgewise.com

✓

You're Ready to Integrate!

You now have a comprehensive understanding of the Bridgewise integration journey. Let's recap the key steps:

Authenticate

Request M2M access token using your Client ID and Secret

Convert Identifiers

Use identifier-search to get company_id and trading_item_id

Consume APIs

Make on-demand requests leveraging CloudFront caching

Embed Widgets (Optional)

Add pre-built UI components via iframe integration

? Next Steps:

Test authentication flow in your development environment
Convert a few sample identifiers using identifier-search
Explore the Swagger documentation and try live endpoints
Review the specific widget documentation if embedding UI components
Contact support if you need help validating your requests or mapping identifiers

Need Help Getting Started?

If you need help validating your requests, mapping identifiers, or troubleshooting integration issues, our support team is here to assist. Share a sample identifier and the endpoint you're calling, and we'll help you quickly.

Contact Support

Bridgewise Integration Guide • Last Updated: February 2025

For the latest version of this guide, visit the Bridgewise Support Portal

Bridgewise Integration Guide

≡ Contents

Table of Contents

◎ Introduction

What You'll Learn

➜ Overview: The Bridgewise Platform

Platform Capabilities

High-Level Integration Journey

Part 1: Authentication (Machine-to-Machine)

What is M2M Authentication?

1 Step 1: Obtain Your Credentials

Required Credentials

2 Step 2: Request an Access Token

Authentication Endpoint

Understanding Token Scoping

▲ Common Error Codes & Messages

3 Step 3: Using Your Access Token

Using Tokens with API Requests

Using Tokens with Widgets

Token Management Best Practices

↻ Part 2: Identifier Conversion

Why Identifier Conversion Matters

? Understanding the Identifier Hierarchy

⇄ The identifier-search Endpoint

Endpoint Information

Request Parameters

1 Example 1: Converting Tesla (Ticker-Exchange)

Response Field Breakdown

2 Example 2: Converting Apple (ISIN)

▦ Understanding Multiple Listings

Real-World Example: Tesla's Multiple Listings

How to Handle Multiple Results

↓ Example: Retrieving Company Data

Example: Get Company Metadata

⚡ Part 3: API Consumption Model

What is On-Demand Consumption?

Why On-Demand is Superior

Better Performance & Lower Latency

✓ Quick Implementation Checklist

B2B API Integration Flow

How It Works

B2B Integration Architecture

◆ Part 4: Widget Integration (Optional)

What are Bridgewise Widgets?

How Widget Integration Works

Widget Communication & Events

? Support & Contact

You're Ready to Integrate!

Need Help Getting Started?

Related Articles

Bridget API Integration Guide

Widget Integration Guide

Identifier Search & Getting Started

Bridget Widget Integration Guide

BridgeWise Support Escalation Guide