Introduction
In the ever-evolving world of technology, Application Programming Interfaces (APIs) are the backbone of seamless communication between software applications. Developers heavily rely on API documentation to understand and utilize these interfaces effectively. However, searching for the correct API within vast documentation can be daunting. This blog demonstrates an alternative approach to using LLM to assist developers in effortlessly navigating through API documentation, extracting relevant information, and easily generating API URLs.
The Power of Prompt in LLM
In this blog, I am using Cohere, the advanced Language Model. Before we delve into Cohere’s capabilities, let’s discuss the concept of a “prompt” in a Language Model. In simple terms, a prompt is a set of instructions or initial text provided to the model to guide its generation process. For instance, when using Cohere, developers can input a prompt like “Generate a description for the Oracle HCM API to retrieve employee information.” This instruction directs the model’s focus and ensures the generated content aligns with the specific query.
The Struggle with API Documentation Search
Searching for an API can be a daunting challenge for developers in the ever-evolving world of technology. With Application Programming Interfaces (APIs) serving as the backbone of seamless communication between software applications, developers heavily rely on accurate and up-to-date API documentation. However, finding the correct API for a specific use case becomes a complex and time-consuming task within extensive API repositories. Developers may encounter obstacles like ambiguous or inconsistent naming conventions, incomplete or outdated documentation, a lack of relevant examples, difficulties in identifying the correct API parameters, and the need for manual searches through multiple documents. These struggles can impede productivity and innovation, making it essential to find efficient solutions to streamline the API documentation search process.
Oracle HCM (Human Capital Management) offers various APIs that cater to diverse use cases, from employee information retrieval to payroll management. Navigating the extensive API documentation to find the most appropriate API for a given use case is often complex and time-consuming. Such challenges can hinder productivity and innovation in software development.
Below is a systematic and efficient process that empowers developers to easily harness APIs. This process involves obtaining the swagger file from the API documentation URL, processing it with a Python module, and using a Language Model (LLM) to generate formatted API documentation with enriched descriptions. We then initialize embedding and store API doc vectors in a vector store, enabling efficient retrieval. Finally, we seamlessly generate API URLs using the formatted API documentation and generated descriptions.

Enrich API Description with and for LLM
Enter LLM, the game-changer that can revolutionize developers’ interaction with API documentation. Leveraging the power of advanced natural language processing, using LLM like Cohere can generate descriptive content for APIs based on contextual prompts.
For instance, if a developer seeks to retrieve employee information from Oracle HCM, they can simply provide the following prompt to Cohere:
“Generate a description for the API to retrieve employee information from Oracle HCM.”
Original Description:
Enriched Description:
Cohere will then process the prompt, analyze the underlying meaning, and generate a relevant description for the suitable API. This eliminates the need for developers to manually browse through lengthy documentation, streamlining the development process and boosting productivity.
Storing API in the Vector Database Using Embedding
Typical usage of the LLM use case goes beyond generating API descriptions; in some cases, we need to be able to store the data in a vector database using embedding for fast retrieval and performance. Embedding is a technique representing APIs document as numerical vectors in a multi-dimensional space. Each API’s document’s unique characteristics, functionalities, and relationships are mapped into these vectors in this use case.
By converting APIs documents into vectors and storing them in a database, developers can efficiently search, compare, and retrieve APIs based on their relevance to specific use cases. This enables quick and accurate identification of the most suitable APIs, reducing development time and minimizing the risk of errors.
The following code snippet aims to generate embeddings for API documentation using Cohere’s embedding service. The process involves initializing the CohereEmbeddings object with the Cohere API key, enabling access to Cohere’s embedding capabilities. A persistent client for the ChromaDB is also used to store the embeddings. The API documentation is read from the file “hcm_api_doc.txt” and then split into smaller chunks using the RecursiveCharacterTextSplitter. The resulting text chunks are passed through Cohere’s embeddings model, generating numerical representations (embeddings) for each chunk. These embeddings are then stored in the ChromaDB using the persistent client, allowing for efficient retrieval and manipulation of the API documentation. The final result is the persistence of the embeddings in the “./chroma_db” directory for future usage and analysis.
from langchain.llms import Cohere
from langchain.embeddings import CohereEmbeddings
from langchain.vectorstores import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
import chromadb
import cohere
from chromadb.config import Settings
embeddings = CohereEmbeddings(cohere_api_key=cohere_api_key)
chromadb_client = chromadb.PersistentClient(path="./chroma_db")
f = open("hcm_api_doc.txt", "r")
text = f.read()
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=1, separators = ["API documentation"], length_function = len)
docs = text_splitter.split_text(text)
db = Chroma.from_texts(docs, embeddings, client=chromadb_client, client_settings=Settings(allow_reset=True), persist_directory="./chroma_db")
db.persist()
With APIs document stored in the vector database, developers can effortlessly search for the most appropriate API to address their specific needs. Instead of grappling with the complexities of manual API search, they can utilize Cohere’s search capabilities to find the perfect match.
The following code snippet aims to retrieve relevant API documentation based on a specific query. The query “Which API can I use to get the enrollment data” is used to find the most suitable API for retrieving enrollment data. The code uses a retriever object, db_retriever, to access the stored API documentation previously embedded and stored in the ChromaDB. The get_relevant_documents method is then called on the db_retriever with the provided query, returning a list of relevant documents that match the query. Finally, the content of the first document in the list is printed, displaying the relevant API documentation that fulfills the requirement to retrieve enrollment data. This process streamlines the search for the appropriate API within the database and provides developers with the necessary information to proceed with their development tasks.
query = "Which API can I use to get the employee data without empsUniqID" db_retriever = db.as_retriever() docs = db_retriever.get_relevant_documents(query) print(docs[0].page_content)
Provide a simple prompt like “Which API can I use to get the employee data without empsUniqID.”. Using a large language model like Cohere, we can search the vector database and present the most relevant API to retrieve the employee information from Oracle HCM. This streamlined process saves valuable time and effort, promoting a seamless development experience.
The output of the above prompt:
Description | The Employees API provides a list of all employees in the system. The API can be used to retrieve information about employees such as their name, address, and employment status. The request parameters can be used to filter the results by expanding the response with additional data, setting the offset and limit for the result set, and ordering the results. The response data includes the total number of results, the offset and limit for the result set, and the links to the next and previous pages. The items in the collection are the employees, each with their own set of data such as their unique identifier, name, and employment information. The employee’s data also includes their citizenship status, marital status, and other information.
Endpoint | {url}
get /emps Query parameters table:
expand | string
fields | string
onlyData | boolean
links | string
limit | integer
offset | integer
totalResults | boolean
q | string
orderBy | string
finder | string
effectiveDate | string
REST-Framework-Version | string
Metadata-Context | string
Effective-Of | string
Response schema (JSON object):
totalResults | integer | The estimated row count when “?totalResults=true”, otherwise the count is not included.
offset | integer | The offset value used in the current page.
count | integer | The number of resource instances returned in the current range.
hasMore | boolean | Indicates whether more resources are available on the server than the subset returned in the response. If the value is true, then there are more resources to retrieve from the server. The default value is false.
limit | integer | The actual paging size used by the server.
links | array | The link relations associated with the resource instance.
items | array | The items in the collection.
Each object in the “items” key has the following schema:
CreationDate | string
CitizenshipToDate | string | End date of citizenship.
WorkFaxCountryCode | string | Country code of the phone number for the work fax machine.
WorkMobilePhoneLegislationCode | string | Legislation code of the work mobile phone number.
assignments | array
LicenseNumber | string | Person’s driving license number.
PassportIssuingCountry | string | Country that issued the passport.
PassportId | integer | Primary key generated by the application.
NationalIdPlaceOfIssue | string | Place where the national identifier was issued.
Gender | string | Person’s gender. Valid values are defined in the list GenderLOV.
PassportExpirationDate | string | Expiration date of the passport.
WorkerType | string
NationalIdType | string | Type of national identifier. Valid values are defined in the list NationalIdTypeLOV.
WorkFaxLegislationCode | string | Legislation code of the work fax number.
HireDate | string | Hire date of the employee.
links | array | The link relations associated with the resource instance.
NameSuffix | string | Part of the name appended to a person’s last name such as Jr., III, etc.
CitizenshipStatus | string | Status of the person’s citizenship. Valid values are defined in the list CitizenshipStatusLOV.
HomeFaxExtension | string | Extension of the phone number for the home fax machine.
DateOfBirth | string | Date of birth of the person.
WorkPhoneExtension | string | Extension of the work phone number.
HomePhoneLegislationCode | string | Legislation code of the home phone number.
HomePhoneAreaCode | string | Area code of the home phone number.
PreviousLastName | string | Previous last name of the person, if any.
WorkFaxExtension | string | Extension of the phone number for the work fax machine.
City | string | Town or city in which the address is located.
WorkFaxAreaCode | string | Area code of the phone number for the work fax machine.
AddressLine3 | string | Third line of the primary mailing address.
AddressLine2 | string | Second line of the primary mailing address.
MaritalStatus | string | Person’s marital status. Valid values are defined in the list MaritalStatusLOV.
AddressLine1 | string | First line of the primary mailing address.
PersonId | integer | Internal identifier for the person.
NationalIdCountry | string | Country of nationality.
DriversLicenseExpirationDate | string | Expiration date of the driver’s license.
personExtraInformation | array
Country | string | Country in which the address is located.
CitizenshipLegislationCode | string | Legislation code derived from the legal entity. Valid values are defined in the list CitizenshipLegislationCodeLOV.
Region | string | Primary region in which the address is located.
PassportNumber | string | Person’s passport number.
LastName | string | Person’s last name.
MilitaryVetStatus | string | Indicates whether the person is on military service. Valid values are defined in the list MilitaryVetStatusLOV.
WorkPhoneNumber | string | Work phone number.
directReports | array
Honors | string | Higher qualification appended to a person’s name. For example, PhD.
roles | array
HomePhoneExtension | string | Extension of the home phone number.
PostalCode | string | Postal code of the address.
NationalIdExpirationDate | string | Expiration date of the national identifier.
ProjectedTerminationDate | string | Projected termination date for the worker.
CorrespondenceLanguage | string | Preferred language for communication. Valid values are defined in the list CorrespondenceLanguageLOV.
Salutation | string | Person salutation such as Mr., Ms., and so on. Valid values are defined in the list SalutationLOV.
WorkPhoneAreaCode | string | Area code of the work phone number.
CitizenshipId | integer | Primary key generated by the application.
HomeFaxLegislationCode | string | Legislation code of the home fax number.
personDFF | array
WorkPhoneLegislationCode | string | Legislation code of the work phone number.
HomePhoneNumber | string | Home phone number.
LegalEntityId | integer | Unique identifier for the legal entity. Valid values are defined in the list LegalEmployerLOV.
DisplayName | string | Person’s display name.
WorkPhoneCountryCode | string | Country code of the work phone number, such as 39 for Italy.
PreferredName | string | Person’s preferred first name.
WorkFaxNumber | string | Phone number for the home fax machine.
WorkMobilePhoneNumber | string | Work mobile phone number.
DriversLicenseId | integer | System-generated primary key. Surrogate key.
HomePhoneCountryCode | string | Country code of the home phone number.
PersonNumber | string | Number assigned to a person to identify the person uniquely. Does not depend on the person type (employee, contingent worker, etc). Search on this attribute is not case sensitive.
visas | array
UserName | string | User name for the record. This value is optional and is automatically generated if not specified. Also works with UsernameMatching attribute. Search on this attribute is not case sensitive.
TerminationDate | string
FirstName | string | Person’s first name.
PassportIssueDate | string | Date of issue of passport.
NationalId | string | Primary key generated by the application.
Religion | string | Person’s religion. Valid values are defined in the list ReligionLOV.
photo | array
WorkMobilePhoneAreaCode | string | Area code of the work mobile phone number.
WorkMobilePhoneExtension | string | Extension of the work mobile phone number.
HomeFaxNumber | string | Phone number for the home fax machine.
WorkEmail | string | Person’s work email address. Search on this attribute is not case sensitive.
Region2 | string | Secondary region within the primary region.
MiddleName | string | Person’s middle name.
HomeFaxAreaCode | string | Area code of the phone number for the home fax machine.
DriversLicenseIssuingCountry | string | Country that issued the driver’s license.
HomeFaxCountryCode | string | Country code of the phone number for the home fax machine.
Ethnicity | string | Person’s ethnicity for the legislation code. Valid values are defined in the list EthnicityLOV.
WorkMobilePhoneCountryCode | string | Country code of the work mobile phone number.
EffectiveStartDate | string | Date at the beginning of the period within which the employee is effective.
ReligionId | integer | Primary key generated by the application.
LastUpdateDate | string
Generating API URLs using LLM
We can take LLM’s capabilities even further by assisting developers in generating API URLs through interactive question-based prompts. By posing the queries below, developers can quickly obtain the correct API URL without navigating through documentation manually. Incorporating LLM with few-shot learning is another exciting possibility for aiding developers in generating more accurate API URLs. This powerful combination of language model capabilities and contextual understanding promises to significantly enhance the efficiency and productivity of developers working with APIs.
API url: https://example.com/hcmRestApi/resources/11.13.18.05/emps?q=FirstName=Casey;LastName=Brown&fields=HireDate
API url: https://example.com/hcmRestApi/resources/11.13.18.05/emps?q=FirstName=Casey;LastName=Brown&fields=HireDate&onlyData=True
You are given the below API Documentation:
{api_docs}
Using this documentation, generate the full API url to call for answering the user question.
You should build the API url in order to get a response that is as short as possible, while still getting the necessary information to answer the question.
Pay attention to deliberately exclude any unnecessary pieces of data in the API call.
Do not include data not in the documentation.
Question:{question}
API url:
Cohere processes the question, using the API docs, and presents the URL in a structured and user-friendly format. This feature ensures accuracy and precision in API utilization while eliminating the need for trial and error.
co = cohere.Client(cohere_api_key)
for doc in docs:
prompt = template.format(api_docs = doc.page_content, question= question)
response = co.generate(
prompt=prompt,
model='command',
max_tokens=1000,
return_likelihoods="None",
temperature=0,
p = 1,
truncate= "END"
)
generated = response
print(generated[0].text)
With a question like: “I don’t have Casey Brown employee ID, but who is Casey Brown? When was he hired”
Output:
https://example.com/hcmRestApi/resources/11.13.18.05/emps?q=FirstName=Casey;LastName=Brown&fields=HireDate
Conclusion
Large language models have emerged as a powerful way to help developers significantly simplify the process of searching, understanding, and utilizing APIs from API documentation. By harnessing the capabilities of prompts, API description generation, vector database embedding, and interactive question-based prompts, LLM empowers developers to be more productive, efficient, and innovative.
With the availability of the large language models at their disposal, developers can bid farewell to the struggles of API documentation search and focus on what truly matters – crafting exceptional software solutions that drive progress and transform the technological landscape. As LLM, like Cohere, continues to evolve and improve, it promises to revolutionize how developers interact with API documentation, making the future of software development brighter and more accessible.
