> This page is for version v4 (default). > For other versions, use one of these documentation indexes: > - v4 (default): https://help.getzep.com/v4/llms.txt > - v3: https://help.getzep.com/v3/llms.txt > - v2: https://help.getzep.com/v2/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://help.getzep.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://help.getzep.com/_mcp/server. ## Zep v4 API is generally available You can now use the Zep v4 API with the v4 SDKs for Python, TypeScript, and Go at version 4.0.0. The v4 API is a Context API for agents that call Zep while they work. The v4 documentation is now the default version of the documentation site. The v3 API continues to work, and v3 and v4 serve the same project data. Thus, you can move an application to v4 in steps. Read the docs ## Graph navigation in the v4 API You can now read a graph by connection. The `graph.node.list` method lists the most connected nodes first when `order_by` is `degree`. The `graph.node.list_neighbors` method returns the nodes that connect to one node, with the edges between them. The `graph.get_subgraph` method expands from up to 20 seed nodes and tells you when a limit stopped the expansion. The Context MCP Server gives the same navigation with the `get_node_neighbors` and `get_subgraph` tools. Read the docs ## Debug logs and Ingestion Traces in the v4 API You can now read the debug logs and the Ingestion Traces of an episode through the API and the SDKs. The `debug_log.enable` method turns on debug mode for a limited time. The `graph.episode.get_debug_logs` and `graph.episode.list_ingestion_traces` methods return the records for one episode. An Ingestion Trace shows why an extraction step made its decision, so you can find the cause of a wrong fact. Read the docs ## Zep UUIDs and safe retries in the v4 API The v4 API identifies each user, thread, and graph by a UUID that Zep generates. A create call returns the UUID, and each later call takes it. Store the UUID with your own record. The v3 `user_id`, `thread_id`, and `graph_id` values become legacy names. The SDKs send an idempotency key when they retry a create call, so a retry does not make a second resource. Read the docs ## Stable error codes in the v4 API Each v4 error response now has an `error` object with a stable `code`. Your code or your agent can use this code to select the next step. The object also gives the request field that caused the error. It also gives a request ID. The `X-Zep-Request-ID` header of each v4 response has the same request ID. Read the docs ## One search method for each scope in the v4 API Each search scope has its own v4 method: `graph.search_edges`, `graph.search_nodes`, `graph.search_episodes`, `graph.search_observations`, and `graph.search_thread_summaries`. Each method has one response type, so an agent can use each method as a separate tool. List methods use an opaque cursor in place of page numbers. Read the docs ## Custom attributes keep stored values When an episode does not give a value for a custom attribute, Zep now keeps the stored value on the node or the edge. Before, Zep could replace a stored value with a value that the text did not support. Read the docs ## Graph selectors on API keys You can now limit an API key to specific standalone graphs with graph selectors in a policy set. The guide gives the setup steps. Read the docs ## v4 edge search returns one edge for each hyperedge The v4 `graph.search_edges` method now returns one edge for each hyperedge. The returned edge is the best-ranked member of the hyperedge, and `page_size` and the cursor count facts. Before, the members of one hyperedge could fill the results. Use `graph.hyperedge.get` to read all of the members. Read the docs ## Fixed error messages for failed batch tasks A v4 `batch.process` task with the status `failed` or `partial` now always includes an `error` object. The error code is `batch_failed`, `batch_partial`, or `batch_canceled`, and each code has a fixed message. Give the task `uuid` to Zep support when you report a failed batch. Read the docs ## Batch completion webhooks retry after a delivery failure Zep now retries the `ingest.batch.completed` webhook when an attempt to send the webhook fails. Before, a failed attempt could cause a lost webhook. A retry carries the original completion time of the batch. Read the docs ## zep-ingest guide for version 0.4.0 The zep-ingest guide was updated for zep-ingest 0.4.0 and the v4 API. Read the docs