# API reference viewer

View your API reference directly in the Tray Operations UI

Once you have successfully built an API, it is possible to view your **API reference** directly in the Tray Operations UI.
This can be done by going to the 'Operations' section of your project and clicking on 'API reference':
![API reference viewer](https://tray.ai/documentation/images/platform/api-management/openapi-spec/api-reference-viewer/3UEdNtJmzoLrLO8dFHLOSF_Screenshot%202024-11-08%20at%2014.31.35.png)
This organized display gives you a quick, structured reference to understand each endpoint’s purpose, usage, expected data formats, and responses, enhancing the overall usability of your API.
![Api reference viewer 2](https://tray.ai/documentation/images/platform/api-management/openapi-spec/api-reference-viewer/35USMYXSpmGTCx3nZY3VAN_Screenshot%202024-11-08%20at%2014.38.55.png)
Here’s an overview of the information that you can expect to see:

1. **General API Information**:

* **API Title**, such as “APIM Docs” for easy identification of the API.
* **Version**, such as “1.0.0”, helping users know which version they are interacting with.
* **Base URL**: The server URL (e.g. "<https://e99e999e-e9ee-999e-9999-9e99ff99eee9-api.trayapp.io>") is provided, showing the endpoint’s base for constructing requests.

2. **Endpoint Details**:

* **Endpoint Path**, such as /v1/leads indicate where to send requests.
* **Operation ID**, such as “Get SFDC leads” reference specific operations.

3. **Request Information**:

* **HTTP Methods**: Each endpoint’s supported HTTP methods, such as GET, are highlighted to guide how requests should be made.
* **Parameters**:
* **Query Parameters**: Details on optional query parameters (e.g. *domain*, *get\_by*, *lead\_owner\_email*) specify the data users can send in requests.
* **Headers**: Specific headers like source are outlined, along with descriptions and types (e.g., string), providing insight into required/requested information to accompany the request.
* **Data Types**: Each parameter has a specified type (e.g., string) and description, helping users form correctly structured queries.

4. **Response Information**:

* **Successful Responses** (200)
* **Error Responses**:
* **400 Bad Request**: Describes scenarios of invalid input with a structured message field.
* **403 Forbidden**: Indicates permission-related issues with standard messaging.
* **500 Internal Server Error**: Helps identify internal server issues with a predefined message format.

5. **Schema Definitions**: Each response (including errors) has a clearly defined schema. Users can view data structures (e.g., *leads array*) and property types, making it easier to parse responses programmatically.