Usage Notes
Including Additional Attributes (e.g., Lead ID, Row ID, Metadata)
When sending a prediction request to the API (both v1 and v2), you must include all features used during model training. These are the input attributes the model expects in order to make an accurate prediction — if any are missing, the API will return an error.
However, in many real-world use cases, you may want to include additional fields in your request — such as Lead ID, Customer ID, or any other identifier — even if they were not used as training features.
This is fully supported. These extra fields are passed through the prediction process unchanged, and they will appear in the API response alongside the predicted values. This makes it easier to:
Match predictions back to the original data rows
Maintain row-level traceability
Integrate results into external systems or dashboards
⚠️ Important
You must include all training features. Omitting any feature used during model training will result in an error.
Extra attributes are optional. They will not affect the prediction but can help with tracking or integration.
API Rate Limiting
Graphite Note enforces rate limits for API requests to ensure fair usage and prevent abuse. The system utilizes two levels of rate limiting: global and tenant-specific.
Global Rate Limit
The system monitors overall API traffic to count the number of requests made within the last minute. If this count exceeds the configured global rate limit, further API requests are denied.
Tenant-Specific Rate Limit
Additionally, the system tracks API usage on a per-tenant basis. If the count of API requests made by the current tenant within the last minute surpasses the specified rate limit, further API requests are denied.
Configuration
The rate limits are configured as followed:
Note: Rate Limit Exceeded
When the API rate limit is reached, the system will deny further requests, and the API response should include the HTTP status code
429 (Too Many Requests)
. This status code indicates that the client has made too many requests within a specified time frame. It is essential for clients to handle this response code gracefully by adjusting their request frequency or implementing backoff strategies
Last updated
Was this helpful?