Verify your connection
Prove that your request reaches the intended instance with the intended authority.
Use a read-only request before adding data. This separates endpoint, authentication, and namespace problems from application logic.
Set the connection values
Set MINDS_INSTANCE_URL to the endpoint of your Mind and MINDS_CAPABILITY to its issued signed capability. Load the credential from your secret manager or local environment; do not place a literal secret in source code.
curl --fail-with-body "$MINDS_INSTANCE_URL/v1/keyspaces" \
-H "x-akasha-capability: $MINDS_CAPABILITY"This uses the current daemon's capability header. A Bearer token alone does not satisfy a deployment with AKASHA_REQUIRE_CAPABILITY enabled. A deployment can require an additional legacy JWT; consult instance authentication.
Read the result
A successful keyspace response confirms this operation was authorized on this endpoint. An empty collection can be valid for a new Mind. It does not prove that a different namespace, write operation, model service, or agent integration is available.
| Result | Next step |
|---|---|
| Cannot reach host | Recheck endpoint, instance state, and network access |
| 401 or authentication error | Check credential type, signature, expiry, and required headers |
| 403 or authority error | Check namespace and action permissions |
| 404 | Confirm method/path and whether the service is enabled |
| 5xx | Check instance health and preserve the request time for diagnosis |
Then prove the workflow
For persistence, write one harmless record in an authorized test namespace, read it with a second request, then reconnect and read it again. Use the endpoint's exact schema from the instance reference. For an agent, perform the read through the agent as well as directly through HTTP.
A setup wizard's green check is useful only if it represents a real request. The current connection wizard and some transports have known gaps described in compatibility.