Connection details

Secret key. What comes back is a password.

1curl "$BASE/v1/data/_connection" -H "authorization: Bearer $SK"

1{2  "connectionString": "postgresql://booking_owner:…@ep-…-pooler.c-5.eu-central-1.aws.neon.tech/booking?sslmode=require&channel_binding=require",3  "directConnectionString": "postgresql://booking_owner:…@ep-….c-5.eu-central-1.aws.neon.tech/booking?sslmode=require&channel_binding=require",4  "database": "booking",5  "role": "booking_owner",6  "region": "aws-eu-central-1",7  "regionName": "Frankfurt",8  "rotatedAt": null9}

Requires the data:read scope.

A key only carries the services your project had when the key was issued, so a key older than this service — or older than the day you turned it on — does not have it, and this call answers 403. Issue a new key in the studio with Database ticked; rotating the old one deliberately keeps its original grant, because rotation replaces a credential rather than widening one.

Why this exists

So a deploy can fetch the string rather than a person copying it into a secret store. The copying step is where credentials end up in chat messages, and it is the step this removes.

1DATABASE_URL=$(curl -fsS "$BASE/v1/data/_connection" \2  -H "authorization: Bearer $SK" | jq -r .connectionString)

It answers to servers only

A publishable key is refused, and there are no CORS headers on this route at all. A browser cannot call it even if a secret key ends up in a bundle, and that protection does not depend on anybody reading an error message.

1{ "error": "This is a publishable key. A connection string is a credential — use a secret key (sk_…) from a server." }

There is no POST

Creating a database is a studio action. See create a database for why.

Errors

One answer covers all three 503 cases. Your move is the same for each — look at the studio — and distinguishing them would tell an unauthenticated caller about our internal state for no benefit to a legitimate one.