Integration
Supplier Integration Guide
Overview
This document outlines the integration process for suppliers who wish to expose their data securely while allowing our system to fetch necessary information. The integration follows a pull-based model, meaning suppliers do not need to send data proactively but must implement two API endpoints that we will query when needed.
Key Integration Principles
-
Data Stays on Your Servers
Suppliers maintain full control over their data. Our system will only retrieve what is needed, when it is needed. -
Flat Query Structure
The request format will always be a flat dictionary, ensuring consistency in how queries are made across different systems. -
Standardized Matching Process
The supplier’s system will be responsible for processing and returning the closest matches based on similarity. -
Read-Only Access
The integration is designed for data retrieval only—our system will never write or modify supplier data.
Required Endpoints
1. Matching Endpoint (/match
)
Purpose
This endpoint receives a structured query representing a company record and returns the closest matches from the supplier’s dataset based on similarity scores.
Expected Behavior
- Accepts a query containing structured attributes like company name, tax identifiers, and location details.
- Processes the query using a matching algorithm.
- Returns a ranked list of the top k closest matches, each with a similarity score between 0 and 1.
Considerations
- The similarity function must be designed to handle minor variations in company details (e.g., different spellings or abbreviations).
- Data normalization and standardization may improve accuracy.
Data Matching Strategy
Suppliers need to implement a matching function that processes queries and identifies the most relevant records. Below are the key elements:
1. Query Structure
The request will be a flat dictionary with attributes such as:
2. Matching Process
- Normalize input fields (e.g., case normalization, removal of special characters).
- Compare query attributes against internal records.
- Rank results by similarity score.
3. Response Format
The endpoint must return an array of the best-matching records, each structured as follows:
2. Agencies Endpoint (/agencies
)
Purpose
Returns a list of available agency names from the supplier’s system. This helps define the scope of available entities.
Expected Behavior
- Returns a predefined or dynamically retrieved list of agency names.
- Can be hardcoded or fetched from an internal database.
Considerations
- The list should be up to date to reflect operational agencies.
- If agencies frequently change, consider automating list updates.
Implementation Notes
- Suppliers are free to implement the service using any technology stack (e.g., Python, Node.js, Java, Go).
- Consider caching results if processing is expensive.
Next Steps
- Implement the two required endpoints.
- Test the endpoints with sample queries.
- Provide the API base URL and authentication details for integration.
- Validate integration using test queries provided by our team.
For further questions, refer to the API documentation:
Example Implementation
Here is an example implementation of the integration: