| Type: ulid Length: 26
The unique ID assigned to each Request Log which is generated
by our system using the ULID format. Each ID is
precisely 26 characters long, ensuring a unique and consistent
identifier for every Request Log. This ULID is
automatically created by our system and is used to uniquely identify
and track each Request Log in our database.
|
| Type: string
The API endpoint that was accessed. This information is vital for
understanding which parts of your API are most used or may need
optimization or additional security measures.
|
| Type: string
The domain or subdomain used to consume the API. This is essential
for distinguishing between different environments (e.g., production,
staging) and services when logging requests.
|
| Type: string
The HTTP method used. Knowing the method helps in analyzing the nature
of the requests (e.g., data retrieval vs. data submission) and optimizing
API endpoints accordingly.
|
| Type: string|null
The domain from which the request originated. It's important for
identifying the source of the traffic, understanding user behavior,
and detecting potentially malicious sources.
|
| Type: integer
The Milliseconds taken to process the request. Critical for
assessing the performance of your API and identifying slow or
problematic endpoints.
|
| Type: string|null
Information about the client's software (browser, OS). This helps
in understanding the environments in which your API is used and
ensuring compatibility across different systems.
|
| Type: string|null
The IP address of the client making the request. Useful for
geo-locating users, analyzing traffic patterns, and detecting
suspicious activities.
|
| Type: mixed|null
Query parameters often dictate how the data should be filtered
or customized when returned by the API. For instance, parameters
might specify which fields to return, limit the number of records,
or apply specific filters. It helps in understanding these user
preferences and requirements.
|
| Type: mixed|null
The data sent by the client in the request. Essential for debugging
issues, understanding user behavior, and optimizing the user experience.
|
| Type: mixed|null
Headers sent by the client. These can provide context about the request,
such as authentication tokens, preferred languages, and client capabilities.
|
| Type: integer
The HTTP status code returned (e.g., 200 OK, 422 Unprocessable
Entity). Important for monitoring the health of your API and identifying
errors or issues that need attention.
|
| Type: mixed|null
The data sent back to the client in response to their request. Crucial
for ensuring the correct operation of your API and understanding how
responses are handled by clients.
|
| Type: mixed|null
Headers sent back in the response. They can include metadata about the
response, such as content type and cache controls, which are important
for client-side processing and optimization.
|
| Type: datetime
Date of when the request was made. This is essential for monitoring API
usage over time, identifying peak usage periods, and planning for scaling.
This attribute can be formatted as an ISO 8601
string or a UNIX timestamp in milliseconds,
depending on the preferred datetime format specified in the request header (e.g., 2024-08-04T14:22:01Z or
1722572118554). By default, the format is UNIX
timestamp in milliseconds.
|
| Type: datetime The created datetime of the request log.
This attribute can be formatted as an ISO 8601
string or a UNIX timestamp in milliseconds,
depending on the preferred datetime format specified in the request header (e.g., 2024-08-04T14:22:01Z or
1722572118554). By default, the format is UNIX
timestamp in milliseconds.
|
| Type: datetime The updated datetime of the request log.
This attribute can be formatted as an ISO 8601
string or a UNIX timestamp in milliseconds,
depending on the preferred datetime format specified in the request header (e.g., 2024-08-04T14:22:01Z or
1722572118554). By default, the format is UNIX
timestamp in milliseconds.
|