dev -> main (Mar 29) #1294
Merged
dev -> main (Mar 29) #1294
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… endpoint Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
feat(agents-api): add logic to create_response endpoint
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
❌ Changes requested. Reviewed everything up to 85f71d8 in 3 minutes and 48 seconds
More details
- Looked at
7480lines of code in50files - Skipped
1files when reviewing. - Skipped posting
26drafted comments based on config settings.
1. agents-api/agents_api/env.py:148
- Draft comment:
Usingdefault=Nonefor keys like SAPLING_API_KEY and BRAVE_API_KEY is fine if downstream code handlesNonesafely. Consider adding explicit error handling or validation to provide clear error messages if required API keys are missing. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
The comment is speculative - it says "if downstream code handles None safely" but doesn't know if it does or not. It's suggesting potential error handling without knowing if it's needed. The comment is also not clearly actionable - it's more of a general suggestion without specific guidance. We can't see the downstream code that uses these API keys.
I might be wrong because proper error handling for missing API keys is generally important. The suggestion could prevent runtime errors.
While API key error handling is important, this comment is too speculative without seeing the downstream code. It's asking the author to "consider" something without clear evidence it's needed.
Delete the comment because it's speculative and not clearly actionable without more context about how these API keys are used.
2. agents-api/agents_api/queries/utils.py:338
- Draft comment:
The newly addedbuild_metadata_filter_conditionsutility function correctly parameterizes metadata filters to prevent SQL injection. Consider adding a brief inline comment explaining the parameter indexing logic for future maintainers. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
The code is quite readable as is. The variable names param_idx_key and param_idx_value are descriptive. The logic is simple - just incrementing based on params length. The function already has comprehensive docstring explaining its purpose and parameters. An additional inline comment would be redundant and could make the code more cluttered.
The parameter indexing logic, while simple, could be confusing to developers not familiar with SQL parameter indexing. The increment by 2 pattern might not be immediately obvious.
The variable names and context make it clear we're dealing with SQL parameter indices. The pattern is a common one for handling key-value pairs in SQL parameters.
The comment should be deleted. The code is self-documenting with clear variable names and already has a comprehensive docstring. An additional inline comment would add noise without significant value.
3. agents-api/tests/test_agent_metadata_filtering.py:1
- Draft comment:
The tests for SQL injection attempts in metadata filtering are comprehensive. Ensure similar tests are maintained or added for all queries (e.g. docs queries) to cover edge cases across the application. - Reason this comment was not posted:
Comment was on unchanged code.
4. schemas/create_agent_request.json:196
- Draft comment:
Changing the schema for 'attributes_to_retrieve' from an object to an array of strings improves clarity. Verify that this change is communicated to client developers to ensure backward compatibility or enable necessary migration steps. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
The comment is asking the PR author to ensure communication with client developers about a schema change. This falls under the category of asking the author to ensure something is done, which is against the rules.
5. agents-api/env.py:148
- Draft comment:
Changing the default value for SAPLING_API_KEY, ZEROGPT_API_KEY, and BRAVE_API_KEY from an empty string to None may break downstream consumers if they do not handle null values. Please verify that all usages correctly check for None. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
6. agents-api/integrations/utils/integrations/algolia.py:27
- Draft comment:
The refactoring for the Algolia search request now conditionally adds 'attributesToRetrieve' as an array if provided. Confirm that this aligns with Algolia's API expectations and that any previous object usage is no longer needed. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
7. documentation/docs/integrations/search/algolia.mdx:42
- Draft comment:
The example now shows 'attributes_to_retrieve' as an array with a '$' prefix. Please ensure that the '$' notation is intentional and documented, as it differs from the prior object format. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =40%<= threshold50%
The comment is asking the PR author to ensure that the$notation is intentional and documented. This falls under asking the author to confirm their intention, which is against the rules. However, it does point out a specific change in the code that might be an issue, which could be useful. I need to evaluate if the comment is more about confirming intention or if it provides a specific suggestion or observation that could be useful.
8. agents-api/routers/responses/create_response.py:150
- Draft comment:
There are several FIXME comments (e.g., 'Adaptive context is not yet implemented', 'Generate summary is not supported yet'). These indicate incomplete functionality that must be addressed or clearly documented as postponed work before production release. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
9. agents-api/web.py:265
- Draft comment:
The responses router is conditionally included based on the enable_responses flag. Verify that this feature flag and the router dependencies are consistent with the intended deployment model, and that the ordering of router inclusions does not cause conflicts. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
10. agents-api/docker-compose.yml:46
- Draft comment:
There is an inconsistency in the boolean representation for ENABLE_RESPONSES across docker-compose files (one file uses "True" as a string, another uses a default of false). Ensure that the environment variable is handled consistently as a boolean. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
11. memory-store/Dockerfile.migrations:1
- Draft comment:
The migration Dockerfile hardcodes the password 'obviously_not_a_safe_password' in the connection string. Although likely a development placeholder, ensure this is not used in production and consider clearly documenting the security risk. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
The password is clearly a placeholder and the filename suggests this is for migrations. The comment is speculative ("ensure this is not used in production") and asks for documentation rather than suggesting a specific code change. The password being obviously fake suggests this is intentionally for development.
The hardcoded password could be a legitimate security concern if this Dockerfile is used as a base for other environments. Maybe there should be an environment variable instead?
While using an environment variable would be better practice, the comment itself doesn't suggest this solution - it just asks for documentation and verification. Per our rules, we shouldn't make speculative comments or ask for verification.
Delete this comment as it violates our rules by being speculative and asking for verification/documentation rather than suggesting a specific code change.
12. typespec/responses/endpoints.tsp:1
- Draft comment:
New endpoints for the responses API have been added. Please double-check that the model definitions and enum values align with the existing API design and that all necessary properties (e.g., in Response, CreateResponse models) are consistent with the OpenAPI spec. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
The comment is asking the PR author to double-check the model definitions and enum values, which violates the rule against asking the author to confirm or double-check things. It does not provide a specific suggestion or point out a specific issue.
13. agents-api/agents_api/autogen/Chat.py:54
- Draft comment:
Typographical error: the field 'usage' was originally typed as 'CompetionUsage'. It has been corrected to 'CompletionUsage'. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
This comment is purely informative, pointing out a typographical correction. It doesn't provide a suggestion or ask for confirmation on an intentional change. According to the rules, purely informative comments should be removed.
14. agents-api/agents_api/autogen/Chat.py:127
- Draft comment:
Typographical error: the class name was misspelled as 'CompetionUsage'. It has been fixed to 'CompletionUsage'. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
This comment is purely informative, pointing out a typographical error that has already been fixed. It does not provide any actionable feedback or suggestions for improvement.
15. agents-api/agents_api/queries/entries/__init__.py:2
- Draft comment:
Typo: The docstring refers to the module asentrybut all other references (including the file structure and all list) useentries. Consider updating the docstring to 'entries' for consistency. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
16. agents-api/agents_api/queries/utils.py:84
- Draft comment:
It appears there is a typographical error in the generic function definition. The syntax 'def pg_query[**P](' does not seem valid. It is likely intended to be 'def pg_query[P](' or similar. Please review the intended generic syntax to ensure correctness. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
17. agents-api/agents_api/queries/utils.py:338
- Draft comment:
In the serialize_model_data function, the isinstance check uses 'list | tuple'. This syntax for isinstance is non-standard; it is recommended to use a tuple of types instead (i.e., isinstance(data, (list, tuple))). This change will prevent potential compatibility issues. - Reason this comment was not posted:
Comment was on unchanged code.
18. agents-api/docker-compose-api.yml:31
- Draft comment:
Typographical inconsistency: On line 31, the docker image is referenced as 'julepai/agents-api'. Please confirm if this is intentional or if it should be updated to 'julep/agents-api' to maintain consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
Since this is a new file, the image name is part of the changes. However, we don't have enough context to know if 'julepai' is the correct organization name or if it should be 'julep'. The comment is asking for verification rather than pointing out a definite issue. According to the rules, we should not ask authors to verify or confirm their intentions.
The image name could be intentionally different for valid reasons, such as being a different organization or repository. We don't have access to verify the correct naming convention.
The rules clearly state not to make speculative comments or ask authors to confirm their intentions. This comment does both.
The comment should be removed as it asks for confirmation and is speculative without strong evidence of an actual issue.
19. deploy/standalone-docker-compose.yaml:24
- Draft comment:
Typo: The comment on line 24 is missing a closing parenthesis. It currently reads '# Brave Search API Key (For web search tool'. Consider adding a closing parenthesis to complete it, e.g., '# Brave Search API Key (For web search tool)'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
While technically correct, this is an extremely minor issue in a comment that doesn't affect functionality. Comments are documentation, and while clean documentation is good, this level of nitpicking about punctuation doesn't meet the bar for "clearly a code change required". The meaning is perfectly clear without the parenthesis.
The missing parenthesis could be seen as a small documentation inconsistency since other similar comments in the file do have proper parentheses.
Even with the inconsistency, this is far too minor to warrant a PR comment. It doesn't affect code functionality or readability in any meaningful way.
Delete this comment as it's too minor and doesn't meet the bar for "clearly a code change required".
20. documentation/responses/quickstart.mdx:190
- Draft comment:
There's a typographical error in the Info block. The sentence 'To learn more about the CLI one can use the checkout the CLI Documentation.' could be reworded to 'To learn more about the CLI, check out the CLI Documentation.' to improve clarity. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
While the comment identifies a real grammatical issue and the suggestion improves readability, our rules state we should not make purely informative comments or focus on obvious/unimportant issues. Documentation typos and minor grammar fixes, unless they significantly impact understanding, fall into this category.
The grammar error could potentially cause confusion for non-native English speakers. The current wording is clearly incorrect.
While the error is real, it's a minor grammatical issue in documentation that doesn't significantly impact comprehension. The meaning is still clear despite the awkward phrasing.
This comment should be deleted as it addresses a minor documentation wording issue that doesn't require immediate attention or impact functionality.
21. documentation/responses/roadmap.mdx:9
- Draft comment:
Typographical suggestion: The phrase "The Julep's Open Responses API" in line 9 reads awkwardly. Consider revising it for clarity (e.g., remove the leading "The" if the intended name is "Julep's Open Responses API"). - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
The comment is about a minor grammatical suggestion. While technically correct that "The Julep's" is slightly awkward, this kind of minor wording suggestion in documentation doesn't meet our bar for "clearly requiring a code change". Documentation style/wording preferences are subjective and don't impact functionality.
The wording could potentially confuse readers, and clear documentation is important for API adoption.
While clear documentation is important, this minor wording issue isn't confusing enough to warrant a required change - both versions are perfectly understandable.
Delete this comment as it's a minor stylistic suggestion that doesn't meet our bar for requiring a change.
22. integrations-service/docker-compose.yml:4
- Draft comment:
Typographical error: The anchor name 'x--shared-environment' appears to have an extra dash. Typically, YAML extension fields are named with a single dash (i.e., 'x-shared-environment'). Consider updating it to avoid potential confusion. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
23. schemas/create_agent_request.json:3125
- Draft comment:
Typo: The definition 'CompetionUsage' appears to be misspelled. Consider renaming it to 'CompletionUsage' for clarity. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
24. typespec/responses/main.tsp:8
- Draft comment:
The file is missing a newline at the end. Please add a newline at the end of the file for consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
Since this is a new file, all code is technically "changed". Missing newlines at end of file can cause issues with some tools and is generally considered good practice. However, this is something that should be enforced by linting rules or editor settings rather than code review comments. It's a very minor issue that doesn't affect functionality.
The comment is technically correct and follows a common best practice. Missing newlines can cause issues with some version control systems and tools.
While technically valid, this is exactly the kind of minor, obvious issue that should be handled by automated tools rather than manual review comments. It adds noise to the review without providing significant value.
Delete this comment as it's too minor and should be handled by automated tooling rather than manual review comments.
25. typespec/responses/models.tsp:138
- Draft comment:
Typo in the doc comment for ToolChoiceTypes: change "should to use" to "should use". - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
While this is a real grammatical error in the documentation, it's a very minor typo fix. The meaning is still clear even with the error. Documentation typo fixes are generally low value unless they significantly impact understanding.
The error does make the documentation slightly less professional. Some could argue that maintaining high quality documentation is important for API users.
However, this particular error is so minor that it barely impacts readability or professionalism. The meaning is still completely clear.
Delete the comment. While it points out a real error, it's too minor to be worth a PR comment. Documentation typos should be batched into larger documentation cleanup efforts.
26. typespec/tsp-output/@typespec/openapi3/openapi-1.0.0.yaml:10082
- Draft comment:
Typographical error: In the Tools.FunctionDef description, 'overriden' should be corrected to 'overridden' for proper spelling. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
Workflow ID: wflow_BkmoQUyqSSf7rYR2
Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.
| # Track if there are more tool calls to process | ||
| has_tool_calls = True | ||
|
|
||
| # Set a reasonable limit for tool call iterations to prevent infinite loops |
There was a problem hiding this comment.
The iterative loop processing tool calls (using while has_tool_calls and iterations < max_iterations:) is complex. Consider refactoring this block into separate helper functions to improve readability, maintainability, and testability.
…veloper id to litellm requests);
Signed-off-by: Diwank Singh Tomer <diwank.singh@gmail.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Signed-off-by: Diwank Singh Tomer <diwank.singh@gmail.com>
…s docs and models
…_jWOC [Ellipsis] feat: add user context to API and embedding requests
fix(agents-api): add developer id to litellm requests
feat(agents-api): Add static task validations to catch errors beforehand
hotfix(agents-api): Fix subquery cardinality issue
…ybrid search configurations
chore(docker): update litellm-database image to version v1.65.0-stable
feat(agents-api): Made trigram/fuzzy text search parameters configurable + relevant typespec/test changes
docs: upgraded Mintlify to docs.json + fixed broken links + changed d…
fix(agents-api): disable task validation temporarily
CI Feedback 🧐(Feedback updated until commit 7a91610)A test triggered by this PR failed. Here is an AI-generated analysis of the failure:
|
fix(agents-api): improve expression validation for comprehensions and unsupported features
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Type
Enhancement, Tests, Documentation, Bug fix, Configuration changes
Description
Introduced the Open Responses API with endpoints for creating and retrieving responses, including support for tools, multi-modal inputs, and structured outputs.
Added extensive enhancements to metadata filtering, tool execution, and API integration for improved functionality and security.
Implemented new Pydantic models, TypeSpec definitions, and OpenAPI specifications to support the Open Responses API.
Added comprehensive tests for metadata filtering, agent queries, and utility functions to ensure robustness and security.
Updated documentation with concepts, quickstart guides, CLI usage, examples, and a roadmap for the Open Responses API.
Enhanced Docker Compose configurations and environment settings for better deployment and configuration management.
Fixed multiple bugs, including typos in model names and assertion messages, ensuring consistency and correctness.
Changes walkthrough 📝
25 files
Responses.py
Introduced Pydantic models for Open Responses API.agents-api/agents_api/autogen/Responses.py
responses.
CreateResponse,Response, andToolChoice.outputs.
model_converters.py
Added model conversion utilities for Open Responses API.agents-api/agents_api/routers/utils/model_converters.py
CreateResponseinto internal modelslike
ChatInput.multi-modal data.
responses.
create_response.py
Added create response endpoint for Open Responses API.agents-api/agents_api/routers/responses/create_response.py
interactions.
convert_create_responseutility for inputtransformation.
tool_executor.py
Implemented tool execution logic for Open Responses API.agents-api/agents_api/activities/tool_executor.py
execution.
get_response.py
Added get response endpoint for Open Responses API.agents-api/agents_api/routers/responses/get_response.py
web.py
Integrated responses router into the application.agents-api/agents_api/web.py
environment configuration.
bulk_delete_docs.py
Refactored bulk delete logic for secure metadata filtering.agents-api/agents_api/queries/docs/bulk_delete_docs.py
openapi_model.py
Enhanced OpenAPI models for Open Responses API.agents-api/agents_api/autogen/openapi_model.py
calls.
Includabletype for specifying response inclusion options.utils.py
Added utility for secure metadata filtering in queries.agents-api/agents_api/queries/utils.py
securely.
litellm.py
Enhanced LiteLLM client for Open Responses API.agents-api/agents_api/clients/litellm.py
enable_responsesflag.list_agents.py
Improved metadata filtering in agent listing queries.agents-api/agents_api/queries/agents/list_agents.py
list_docs.py
Improved metadata filtering in document listing queries.agents-api/agents_api/queries/docs/list_docs.py
algolia.py
Improved Algolia search request handling.integrations-service/integrations/utils/integrations/algolia.py
requests.
render.py
Enhanced tool handling in session rendering.agents-api/agents_api/routers/sessions/render.py
__init__.py
Added responses router to application routing.agents-api/agents_api/routers/init.py
__init__.py
Updated entry queries module exports.agents-api/agents_api/queries/entries/init.py
add_entry_relationsto the module exports.__init__.py
Initialized responses-related endpoints.agents-api/agents_api/routers/responses/init.py
create_responseandget_responsein the module exports.router.py
Added router for responses-related endpoints.agents-api/agents_api/routers/responses/router.py
openapi-1.0.0.yaml
Added OpenAPI specifications for new response endpoints and schemas.typespec/tsp-output/@typespec/openapi3/openapi-1.0.0.yaml
/responses.Responses.CreateResponse,Responses.Response, and various tool-relatedschemas.
Chat.CompetionUsagetoChat.CompletionUsage.configurations.
models.tsp
Introduced TypeSpec models for response creation and management.typespec/responses/models.tsp
CreateResponseandResponse.models.
effort.
create_agent_request.json
Modified schema for agent creation request.schemas/create_agent_request.json
attributes_to_retrievefield to accept an array of stringsinstead of an object.
create_task_request.json
Modified schema for task creation request.schemas/create_task_request.json
attributes_to_retrievefield to accept an array of stringsinstead of an object.
main.tsp
Integrated responses endpoints into the main API namespace.typespec/main.tsp
ResponsesRouteto the main API namespace.endpoints.tsp
Added TypeSpec endpoints for response operations.typespec/responses/endpoints.tsp
main.tsp
Added main TypeSpec file for responses module.typespec/responses/main.tsp
3 files
test_docs_metadata_filtering.py
Added tests for secure metadata filtering in document queries.agents-api/tests/test_docs_metadata_filtering.py
values.
test_agent_metadata_filtering.py
Added tests for secure metadata filtering in agent queries.agents-api/tests/test_agent_metadata_filtering.py
test_metadata_filter_utils.py
Added tests for metadata filter utility functions.agents-api/tests/test_metadata_filter_utils.py
9 files
env.py
Updated environment configuration for Open Responses API.agents-api/agents_api/env.py
key.
management.
docker-compose.yml
Updated Docker Compose configuration for Open Responses API.agents-api/docker-compose.yml
Compose file.
standalone-docker-compose.yaml
Added standalone Docker Compose configuration for Open Responses API.deploy/standalone-docker-compose.yaml
API.
vectorizer worker.
settings.
docker-compose-api.yml
Added Docker Compose configuration for agents API service.agents-api/docker-compose-api.yml
.env.example
Added example environment configuration for Open Responses API.deploy/.env.example
API.
.env.example
Added flag for enabling responses in the API..env.example
ENABLE_RESPONSESflag to control response feature in the API.docker-compose.yml
Enhanced Docker Compose configuration for integrations service.integrations-service/docker-compose.yml
Dockerfile.migrations
Added Dockerfile for memory store migrations.memory-store/Dockerfile.migrations
responses-build-docker-compose.yaml
Added build configuration for Open Responses API.deploy/responses-build-docker-compose.yaml
API.
store.
4 files
Chat.py
Fixed and updated completion usage model.integrations-service/integrations/autogen/Chat.py
CompletionUsageclass name.Chat.py
Fixed and updated completion usage model.agents-api/agents_api/autogen/Chat.py
CompletionUsageclass name.developer_id.py
Fixed assertion message for developer ID header.agents-api/agents_api/dependencies/developer_id.py
models.tsp
Corrected typo in chat model naming.typespec/chat/models.tsp
CompetionUsagemodel, renaming it toCompletionUsage.9 files
concepts.mdx
Added concepts documentation for Open Responses API.documentation/responses/concepts.mdx
quickstart.mdx
Added quickstart guide for Open Responses API.documentation/responses/quickstart.mdx
mint.json
Updated documentation navigation for Open Responses API.documentation/mint.json
examples.mdx
Added usage examples for Open Responses API.documentation/responses/examples.mdx
conversation history.
assistants.
cli.mdx
Added CLI documentation for Open Responses API setup and usage.documentation/responses/cli.mdx
managing API keys.
roadmap.mdx
Documented roadmap for Open Responses API development.documentation/responses/roadmap.mdx
algolia.mdx
Updated Algolia integration documentation for parameter changes.documentation/docs/integrations/search/algolia.mdx
attributes_to_retrieveparameter to accept a list instead of adictionary.
README.md
Added announcement for Open Responses API in README.README.md
self-hosting.
julep.mdx
Improved introduction documentation for Julep platform.documentation/docs/introduction/julep.mdx
features.