New assistant integrations should use Apostra identifiers. Existing Murph
integrations keep working without a change. The two names use the same
authentication, permissions, rate limits, conversation identity, streaming
behaviour, and error responses.
This is an additive migration. Apostra does not redirect a request from a
Murph URL, and a retry must stay on the endpoint family that started the
request.
Use Apostra for a new integration
Choose the Apostra name that matches the interface you are connecting:
For direct REST clients, replace only the path family. For example:
For MCP clients such as Claude, ChatGPT, and other MCP hosts, connect to
/mcp/v2/apostra or /mcp/apostra. Those endpoints advertise ask_apostra
and Apostra resource URIs. The Murph endpoints advertise ask_murph and Murph
resource URIs. A single MCP endpoint never advertises both names for the same
assistant capability.
If an integration already uses Murph successfully, it does not need an
urgent change. Test the Apostra configuration in a separate connection,
confirm its normal workflow, then update your saved endpoint and tool name
together.
Update a TypeScript integration
The Apostra package exports the matching Apostra type and schema aliases. The
Murph package path stays available for existing consumers.
When your integration uses the Sessions contracts, change the subpath too:
The alias exports preserve the existing schemas and runtime behaviour. You do
not need to change request fields or response handling as part of this rename.
Check a migrated integration
Before changing a production configuration, confirm all of the following in a
test connection:
- OAuth or API-key authentication succeeds with the Apostra endpoint.
- MCP discovery returns
ask_apostra, not ask_murph.
- The assistant can continue an existing conversation and handles a streamed
response as before.
- A linked MCP App opens the Apostra resource URI.
- Your package consumer builds with the Apostra import path.
Keep the Murph connection configuration available until your team has confirmed
the Apostra path in production. Do not send a retry for a streaming or OAuth
request to the other endpoint family.
Compatibility policy
There is no retirement date for Murph identifiers. They will remain available
for at least 90 days after the Apostra production release. We will review
compatibility on 15 January 2027. We will not remove a Murph identifier
until the adoption records show zero active production clients and each
affected named customer has migrated. Apostra will notify affected customers
before proposing any retirement date.
The Apostra product team owns the compatibility review. We will publish any
future retirement date here before changing legacy behaviour.
Need help?
If your integration cannot move to the Apostra identifiers, keep using its
working Murph configuration and contact Apostra support with the endpoint,
tool, or package path you use. Do not include API keys, access tokens, or
customer data in the request. 
