Projects, keys and DSNs

Everything an SDK sends is addressed to a project and authenticated by a key. Check-ins are no different from errors here, so this is the setup step that comes before any monitor work.

Create a project

In the panel at app.parsemend.com, open Settings → Projects and create one. The fields:

Field	Notes
Name	Free text. The slug is derived from it as you type
Slug	Must be unique in the organization
Platform	PHP, JavaScript, Python, Node.js, Ruby, Go, Java, .NET, or Other. Labelling only
Trace sample rate	Applies to performance transactions, not to check-ins

The organization is not a field. Whichever organization you are currently in owns the project, and Filament sets that on create.

Run one project per deployable service. Issues, monitors and uptime checks all hang off the project, so a shared "everything" project turns into one issue list that nobody reads.

Create a key

A new project has no key. Nothing is minted automatically, so a DSN does not exist until you make one.

Open the project, find the Keys section, and press Create key. The only field is a label, for your own benefit when you are looking at four of them. The public key itself is minted server-side as 32 hex characters.

The row then shows two copyable values:

• Public key on its own, for the rare case where you are assembling a request by hand.
• DSN, which is what you paste into an SDK.

What a DSN looks like

https://[email protected]/42
        └──────────── public key ───────────┘ └── ingest host ──┘ └┘
                                                                project id

Three parts, all of which the SDK needs:

• The public key authenticates the request. It is not a secret in the way an API token is: it ships inside browser bundles and mobile apps by design, and it can only write, never read.
• The ingest host is always ingest.parsemend.com in production. It gets its own subdomain precisely so the panel can be reorganized without breaking any SDK already deployed in the wild.
• The project id is the numeric id, not the slug. It is what the ingest endpoint routes on.

An SDK pointed at that DSN posts to POST /api/42/envelope/ on the ingest host and presents the public key in an X-Sentry-Auth header. That single endpoint carries errors, transactions, logs and check-ins alike.

Revoking a key

Each key row has a Revoke action, and a revoked key can be reactivated from the same place. Revoking is immediate: the next request presenting that key gets 401 invalid dsn.

Rotating means creating the new key first, deploying it, confirming the new key's Last used column is moving, and only then revoking the old one. There is no grace period on a revoked key, and a scheduled job that only runs nightly will not tell you it broke until the following night.

Rate limits

Ingest is rate limited per project on a fixed window, 300 requests per 60 seconds by default. Over the limit, ingest returns 429 with a Retry-After header and an X-Sentry-Rate-Limits header that Sentry SDKs already know how to back off against.

Check-ins are far too low-volume for that to be a real constraint. A job checking in twice per run, every minute, is 2 requests per minute against a budget of 300. The limit is shared with error and transaction traffic though, so a project in a crash loop can consume the budget and drop check-ins with it, which shows up as a phantom missed check-in. If you see missed check-ins that coincide exactly with an error spike, that is the mechanism.

Next

You now have a DSN. Take it to the monitors quickstart.