> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloud.gomry.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Quickstart
> Create a project, enable an API, mint a key and make your first billable Gomry Cloud request in about two minutes.
Every Gomry Cloud request needs three things: a **project**, the **API enabled** on that project, and a **key** scoped to the operation you are calling. This page gets you all three and a first response.
Before you start
You need a Gomry account and an organization with a payment method. Cloud is postpaid and metered: there is no free tier, and an organization with no card on file is refused at the gateway with `billing_required` before any work is done. See [Billing](/billing) for why the card comes first.
Make your first request
A project is the unit of isolation and of spend: keys, enabled APIs, usage and the monthly budget cap all belong to one. Most teams run one per environment — `production` and `staging` — because that is the boundary you want a budget and a key revocation to respect.
Open [Services](/services), pick the one you want and turn it on for the project. Enabling is separate from key scopes on purpose: a key minted with a broad scope still cannot reach an API this project never enabled.
Grant it only the scopes you will call. The plaintext key is shown **once** and never again — store it in your secret manager now. Set a monthly budget on the project at the same time: it is the ceiling on everything this key can spend.
Send the key as a bearer token. Endpoints take and return JSON. Most are `POST`; the ones that read or stop work already started are `GET` and `DELETE`.
```bash title="Request" theme={null}
export GOMRY_CLOUD_KEY=gck_live_...
curl -X POST https://api.cloud.gomry.com/v1/fetch \
-H "Authorization: Bearer $GOMRY_CLOUD_KEY" \
-H "Content-Type: application/json" \
-d '{ "url": "https://example.com" }'
```
Reading the response
Every response carries an `x-request-id` header. Log it: it is the one identifier that ties your call to our records of it, and the first thing support will ask for.
Every response body also tells you what it metered — `fetches` here, `pages` for an extraction. That field is the quantity that reaches your invoice, in the same payload as the result, so you never have to infer what you were charged.
```json title="Response" theme={null}
{
"rawHtml": "...",
"metadata": { "title": "Example Domain" },
"fetches": 1
}
```
Going live
There is nothing to swap. The key you integrated with is the key you run in production — same URL, same body, same response shape — so going live is a deployment, not a migration. What changes is the traffic you point at it.
Set a monthly budget on the project before you point production traffic at it. A project with no limit is capped only by your card. See [Billing](/billing).