Overview
Allow GPT to remember past conversations
While GPT chat completions are great for one-off conversations, they are unable to remember any facts from previous conversations. This can be irritating for users, who have to repeat themselves and explicitly give context about the things they’re saying every time.
SID Memory solves this problem by providing a chat completions API that intelligently remembers previous conversations and uses them to respond to user queries where it makes sense.
And all of this is possible without any extra work on your side: SID Memory completely mirrors the OpenAI chat completions endpoint, allowing you to get up and running in minutes.
Get Started
To use SID Memory, you’ll need to create an account on our developer dashboard and head over to the API Keys page to create a new API key.
Make sure to copy the API key and store it in a safe place, as you won’t be able to see it again.
Call the API
The SID Memory API entirely mirrors the OpenAI chat completions API, so you don’t need to make any changes to start using it.
Instead of POSTing to https://api.openai.com/v1/chat/completions, simply make your
requests to https://api.sid.ai/v1/memory/chat/completions instead.
Check out the details on how to do this in the python
and javascript openai packages.
Additionally, you can control the behaviour of the API by passing additional query parameters (discussed below).
By default, all conversations made through your account are stored in a single database, meaning that if you make your application accessible to multiple users, private conversation data will be shared between them. To learn how to segment data between your users, see the Multi-Tenancy section below.
Query Parameters
The SID Memory API supports a number of additional query parameters beyond those supported by the OpenAI chat completions API. These allow you to control behavior specific to SID Memory.
Multi-Tenancy
By default, all conversations are stored in a single database. This means that if you make your application accessible to multiple users, conversation data will be shared between them.
To prevent this, the API supports a namespace query parameter. Using this parameter,
you can segment conversations into different databases, making sure that each user
only has access to their own conversations.
Generally, you should have a unique user ID for each user, which you can then use as the namespace.
For example, for a user with ID user123, you would make requests to
Commit Timeout
The commit_after query parameter allows you to control after how many seconds a conversation
is considered complete and should be committed to the database.
The default value is 120, which means that if a particular conversation is inactive for 2 minutes,
it will be committed to the database.
If your application has long breaks between messages, you may want to increase this value. For example, to set the timeout to 5 minutes, you would make requests to
This can of course be combined with the namespace parameter as follows:
Chat ID
By default, the API will use a heuristic to determine which follow-up requests belong to a prior conversation.
This works well for most applications, but if you want to be more explicit,
you can optionally pass a chat_id query parameter.
For example, if you want to start a new conversation, you can pass a random UUID as the chat_id:
Then, when you want to continue the conversation, you can pass the same chat_id.
This will ensure that only one copy of the conversation is stored.
Was this page helpful?