docs: update references to v2

apps/docs/analytics/overview.mdx

@@ -3,6 +3,10 @@ title: Overview
 description: "Unkey tracks everything for you"
 ---
 
+<Note>
+Analytics endpoints are currently only available in our v1 API. We're working on bringing these to v2 - stay tuned for updates!
+</Note>
+
 
 Consumption based billing for APIs is getting more and more popular, but it's tedious to build in house. For low frequency events, it's quite possible to emit usage events directly to Stripe or similar, but this becomes very noisy quickly. Furthermore if you want to build end-user facing or internal analytics, you need to be able to query the events from Stripe, which often does not provide the granularity required.
 

apps/docs/analytics/quickstarts.mdx

@@ -3,6 +3,10 @@ title: Quickstarts
 description: Power your own dashboard, reports or usage-based billing
 ---
 
+<Note>
+Analytics endpoints are currently only available in our v1 API. We're working on bringing these to v2 - stay tuned for updates!
+</Note>
+
 
 
 These scenarios should give you a good starting point to understand what is possible and what you need to do.

apps/docs/api-reference/v2/auth.mdx

@@ -17,7 +17,7 @@ Authorization: Bearer unkey_1234567890
 Example request:
 
 ```bash
-curl -X POST "https://api.unkey.dev/v1/keys.createKey" \
+curl -X POST "https://api.unkey.com/v2/keys.createKey" \
   -H "Authorization: Bearer unkey_1234567890" \
   -H "Content-Type: application/json" \
   -d '{ "apiId": "api_1234" }'

apps/docs/apis/features/analytics.mdx

@@ -61,10 +61,9 @@ Tags can be added in the request body.
 
 ```bash Providing Tags {7-10}
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.verifyKey \
+  --url https://api.unkey.com/v2/keys.verifyKey \
   --header 'Content-Type: application/json' \
   --data '{
-  "apiId": "api_1234",
   "key": "sk_1234",
   "tags": [
     "tag1",

apps/docs/apis/features/authorization/example.mdx

@@ -76,13 +76,13 @@ Now that we have permissions and roles in place, we can connect them to keys.
 <Tab title="Dashboard">
 
 1. In the sidebar, click on one of your APIs
-2. In the breakcrumb navigation on the top click Reqests and then keys 
+2. In the breakcrumb navigation on the top click Reqests and then keys
     <Frame>
       <img src="/apis/features/authorization/api-keys-navigation.png" alt="Breadcrumb Navigation"/>
     </Frame>
-  
+
 3. Select one of your existing keys by clicking on it
-4. Scroll down to the `Roles` section if not visible 
+4. Scroll down to the `Roles` section if not visible.
 
 You should now be on `/app/keys/key_auth_???/key_???`
 
@@ -113,7 +113,7 @@ You can attach roles to a key when creating it by providing the role names as an
 
 ```bash
 curl -XPOST \
-  --url https://api.unkey.dev/v1/keys.createKey \
+  --url https://api.unkey.com/v2/keys.createKey \
   -H "Authorization: Bearer ${ROOT_KEY}" \
   -H "Content-Type: application/json" \
   -d '{
@@ -123,7 +123,7 @@ curl -XPOST \
     ]
   }'
 ```
-See [here](/api-reference/keys/create) for details.
+See [here](/api-reference/v2/keys/create-api-key) for details.
 
 
 </Tab>

apps/docs/apis/features/authorization/roles-and-permissions.mdx

@@ -130,7 +130,7 @@ When a user of your app creates a new key, you can attach zero, one or multiple
 
 ```bash
 curl -XPOST \
-  --url https://api.unkey.dev/v1/keys.createKey \
+  --url https://api.unkey.com/v2/keys.createKey \
   -H "Authorization: Bearer ${ROOT_KEY}" \
   -H "Content-Type: application/json" \
   -d '{

apps/docs/apis/features/authorization/verifying.mdx

@@ -13,10 +13,10 @@ This will return valid if the key has the permission: `admin`
 ```bash Single Permission
 
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.verifyKey \
+  --url https://api.unkey.com/v2/keys.verifyKey \
+  --header 'Authorization: Bearer unkey_1234' \
   --header 'Content-Type: application/json' \
   --data '{
-    "apiId": "api_1234",
     "key": "sk_1234",
     "authorization": {
       "permissions": "admin"
@@ -28,10 +28,10 @@ curl --request POST \
  This will return valid if the key has either `admin` or both `dns.record.read` and `dns.record.update` permissions.
 ```bash Nested Query
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.verifyKey \
+  --url https://api.unkey.com/v2/keys.verifyKey \
+  --header 'Authorization: Bearer unkey_1234' \
   --header 'Content-Type: application/json' \
   --data '{
-    "apiId": "api_1234",
     "key": "sk_1234",
     "authorization": {
       "permissions": {
@@ -59,7 +59,7 @@ Sometimes you just don't know what permissions are required before loading resou
 In these cases you can manually check permissions as well.
 
 <Steps>
- 
+
 <Step title="Verify">
 Verify the key and all permissions that you already know before needing to query your database.
 

apps/docs/apis/features/enabled.mdx

@@ -16,7 +16,7 @@ Let's disable a key temperarily blocking access with that key.
 
 ```bash
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.updateKey \
+  --url https://api.unkey.com/v2/keys.updateKey \
   --header 'Authorization: Bearer <token>' \
   --header 'Content-Type: application/json' \
   --data '{
@@ -29,7 +29,7 @@ Now, when you verify the updated key it will show as invalid.
 
 ```bash
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.verifyKey \
+  --url https://api.unkey.com/v2/keys.verifyKey \
   --header 'Content-Type: application/json' \
   --data '{
 		"key": "<NEW_KEY>"

apps/docs/apis/features/ratelimiting/overview.mdx

@@ -17,7 +17,7 @@ Auto-apply ratelimits (`autoApply: true`) are checked automatically during every
 
 ```bash
 # Create a key with auto-apply ratelimit
-curl -X POST https://api.unkey.dev/v1/keys.createKey \
+curl -X POST https://api.unkey.com/v2/keys.createKey \
   -H "Authorization: Bearer <UNKEY_ROOT_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
@@ -35,11 +35,10 @@ curl -X POST https://api.unkey.dev/v1/keys.createKey \
 
 ```bash
 # Verify key - auto-apply ratelimits are checked automatically
-curl -X POST https://api.unkey.dev/v1/keys.verifyKey \
+curl -X POST https://api.unkey.com/v2/keys.verifyKey \
   -H "Authorization: Bearer <UNKEY_ROOT_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
-    "apiId": "api_123",
     "key": "your_api_key_here"
   }'
 ```
@@ -48,7 +47,7 @@ Manual ratelimits (`autoApply: false`) must be explicitly specified in verificat
 
 ```bash
 # Create a key with manual ratelimit
-curl -X POST https://api.unkey.dev/v1/keys.createKey \
+curl -X POST https://api.unkey.com/v2/keys.createKey \
   -H "Authorization: Bearer <UNKEY_ROOT_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
@@ -65,11 +64,10 @@ curl -X POST https://api.unkey.dev/v1/keys.createKey \
 
 ```bash
 # Verify key - override cost explicitly
-curl -X POST https://api.unkey.dev/v1/keys.verifyKey \
+curl -X POST https://api.unkey.com/v2/keys.verifyKey \
   -H "Authorization: Bearer <UNKEY_ROOT_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
-    "apiId": "api_123",
     "key": "your_api_key_here",
     "ratelimits": [
       {
@@ -85,7 +83,7 @@ curl -X POST https://api.unkey.dev/v1/keys.verifyKey \
 Configure ratelimits on a per-key or per-identity basis through the dashboard or API. Each ratelimit requires a unique name, limit count, and duration in milliseconds.
 
 ```bash
-curl -X POST https://api.unkey.dev/v1/keys.createKey \
+curl -X POST https://api.unkey.com/v2/keys.createKey \
   -H "Authorization: Bearer <UNKEY_ROOT_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
@@ -121,7 +119,7 @@ The legacy format converts automatically:
 
 ```bash
 # Legacy format (deprecated)
-curl -X POST https://api.unkey.dev/v1/keys.createKey \
+curl -X POST https://api.unkey.com/v2/keys.createKey \
   -H "Authorization: Bearer <UNKEY_ROOT_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
@@ -133,7 +131,7 @@ curl -X POST https://api.unkey.dev/v1/keys.createKey \
   }'
 
 # Automatically becomes
-curl -X POST https://api.unkey.dev/v1/keys.createKey \
+curl -X POST https://api.unkey.com/v2/keys.createKey \
   -H "Authorization: Bearer <UNKEY_ROOT_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
@@ -156,7 +154,7 @@ Remove the automatically migrated "default" ratelimit through the key settings i
 Configure ratelimits at the identity level to share limits across multiple keys. Identity ratelimits work alongside key-level ratelimits, with key-level settings taking precedence for naming conflicts.
 
 ```bash
-curl -X POST https://api.unkey.dev/v1/identities.createIdentity \
+curl -X POST https://api.unkey.com/v2/identities.createIdentity \
   -H "Authorization: Bearer <UNKEY_ROOT_KEY>" \
   -H "Content-Type: application/json" \
   -d '{

apps/docs/apis/features/refill.mdx

@@ -17,7 +17,7 @@ Let's create a new key that can be used 100 times a day.
 
 ```bash
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.createKey \
+  --url https://api.unkey.com/v2/keys.createKey \
   --header 'Authorization: Bearer <UNKEY>' \
   --header 'Content-Type: application/json' \
   --data '{
@@ -34,7 +34,7 @@ Now, when you verify the new key, you will receive the remaining verifications.
 
 ```bash
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.verifyKey \
+  --url https://api.unkey.com/v2/keys.verifyKey \
   --header 'Content-Type: application/json' \
   --data '{
 		"key": "<NEW_KEY>"

apps/docs/apis/features/remaining.mdx

@@ -20,12 +20,14 @@ Let's create a new key, which can be used 100 times.
 
 ```bash
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.createKey \
+  --url https://api.unkey.com/v2/keys.createKey \
   --header 'Authorization: Bearer <UNKEY>' \
   --header 'Content-Type: application/json' \
   --data '{
 	"apiId":"<API_ID>",
-	"remaining": 100
+	"credits": {
+		"remaining": 100
+	}
 }'
 ```
 
@@ -34,10 +36,9 @@ Now when you verify the new key, you will receive back the remaining verificatio
 
 ```bash
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.verifyKey \
+  --url https://api.unkey.com/v2/keys.verifyKey \
   --header 'Content-Type: application/json' \
   --data '{
-      "apiId":"<API_ID>",
       "key": "<NEW_KEY>"
 	}'
 ```
@@ -72,12 +73,11 @@ If a key would only have 3 remaining, the request would be rejected, as there is
 
 ```bash {7-9}
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.verifyKey \
+  --url https://api.unkey.com/v2/keys.verifyKey \
   --header 'Content-Type: application/json' \
   --data '{
-    "apiId":"<API_ID>",
     "key": "<NEW_KEY>",
-    "remaining": {
+    "credits": {
       "cost": 4
     }
   }'

apps/docs/apis/features/temp-keys.mdx

@@ -8,19 +8,19 @@ Temporary API Keys are API Keys that expire after a certain amount of time. They
 
 ## How to create a temporary API Key
 
-To create a temporary API Key, you need to make a `POST` request to the `/v1/keys` endpoint. You can read about all the parameters you can send in the [API Reference](/api-reference/keys/create).
+To create a temporary API Key, you need to make a `POST` request to the `/v2/keys.createKey` endpoint. You can read about all the parameters you can send in the [API Reference](/api-reference/keys/create).
 
 ```bash
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.createKey \
+  --url https://api.unkey.com/v2/keys.createKey \
   --header 'Authorization: Bearer <UNKEY>' \
   --header 'Content-Type: application/json' \
   --data '{
 	"apiId":"<API_ID>",
 	"prefix":"xyz",
 	"byteLength":16,
-	"ownerId":"USER_ID",
-	"expires": 1718718673000,
+	"externalId":"USER_ID",
+	"expires": 1718718673000
 }'
 ```
 

apps/docs/apis/introduction.mdx

@@ -73,10 +73,9 @@ func main() {
 ```
 ```bash cURL
 curl --request POST \
-  --url https://api.unkey.dev/v1/keys.verifyKey \
+  --url https://api.unkey.com/v2/keys.verifyKey \
   --header 'Content-Type: application/json' \
   --data '{
-    "apiId": "api_1234",
     "key": "sk_1234"
   }'
 ```