# Enzoguard documentation > Enzoguard is a machine-authentication service for issuing, managing, and verifying API keys over HTTP. --- ## Getting started Source: https://enzoguard.com/docs/getting-started.md This guide takes you from a new Enzoguard account to a verified API key in less than 10 minutes. You will create an API key and verify it. ## Before you begin You need: - [`curl`](https://curl.se/) installed on your local machine. - A terminal where you can run shell commands. This guide uses two different credentials: - A **system key** lets your backend manage apps and API keys, and call the verification API. - An **API key** identifies a client, service, or workload using your backend. Treat both values as secrets. Enzoguard shows each plaintext key only once. ## 1. Sign up [Create an Enzoguard account](https://enzoguard.com/auth/register), then log in. ## 2. Create a system key Open [System Key Management](https://enzoguard.com/dashboard/system-keys), enter a recognizable description such as `getting-started`, and select **Create key**. Copy the key immediately, then save it in your current shell: ```sh export EZ_SYSTEM_KEY='paste-your-system-key-here' ``` Do not commit the key to source control or include it in logs. For production, store it in your platform's secret manager. ## 3. Create an app An app represents a specific consumer of your backend product. It can represent an organization, a server, or any other client. Create an app named `quickstart`: ```sh curl https://api.enzoguard.com/v1/realms/defaultrealm/apps \ --header "Authorization: Bearer $EZ_SYSTEM_KEY" \ --header 'Content-Type: application/json' \ --data '{"name":"quickstart"}' ``` The response contains the new app's ID and name. Enzoguard accepts either value in app management URLs, so the next command uses the name `quickstart`. ## 4. Create an API key Create an API key for the app: ```sh curl https://api.enzoguard.com/v1/realms/defaultrealm/apps/quickstart/api-keys \ --header "Authorization: Bearer $EZ_SYSTEM_KEY" \ --header 'Content-Type: application/json' \ --data '{"description":"getting-started"}' ``` Copy the value of the `key` field from the response. This is the only time Enzoguard returns the complete API key. Save it in your current shell: ```sh export API_KEY='paste-your-api-key-here' ``` ## 5. Verify the API key Your backend verifies an API key by sending the key and its realm ID to Enzoguard. The request itself is authenticated with your system key: ```sh curl https://api.enzoguard.com/v1/verify-key \ --header "Authorization: Bearer $EZ_SYSTEM_KEY" \ --header 'Content-Type: application/json' \ --data "{\"realm_id\":\"defaultrealm\",\"api_key\":\"$API_KEY\"}" ``` A successful verification returns `"valid":true` together with the app and realm identifiers. Your application can use that identity to decide what the caller is allowed to do. You have now completed the full Enzoguard flow: create an app, issue an API key, and verify it. ## Where to go next - Read [Core concepts](../concepts/) to learn how realms, apps, system keys, and API keys fit together. - Use the [HTTP API reference](../api-reference/) for lifecycle operations such as listing, reading, and revoking API keys. --- ## Core concepts Source: https://enzoguard.com/docs/concepts.md Enzoguard's configuration model has a small number of explicit resources. ## Realm A realm is a logical configuration namespace. Realm names are unique within an Enzoguard cluster. ## App An app belongs to a realm. Apps can carry tags and provide the resource boundary for customer API keys. ## Customer API key A customer API key belongs to an app. Enzoguard returns plaintext key material only when the key is created; stored API-key resources do not contain the plaintext value. The verification endpoint accepts a customer key and reports whether it is valid, together with the identifiers needed by the caller. ## System key A system key authenticates configuration API requests. Send it using the HTTP `Authorization` header: ```text Authorization: Bearer ``` System keys and customer API keys serve different purposes. A system key manages configuration; a customer key is verified by an application using Enzoguard. --- ## Plan limits Source: https://enzoguard.com/docs/limits.md Limits apply across all data in an organization. | Plan | Reads/min | Writes/min | Verifications/min | Realms | Apps | API keys | | --- | ---: | ---: | ---: | ---: | ---: | ---: | | Free | 20 | 20 | 60 | 2 | 10,000 | 10,000 | | Starter | 60 | 60 | 200 | 5 | 1,000,000 | 1,000,000 | | Professional | 60 | 60 | 1,000 | 5 | 1,000,000 | 1,000,000 | | Business | 60 | 60 | 10,000 | Unlimited | Unlimited | Unlimited | ## Request rate limits Read, write, and verification limits are independent. `GET` requests count as reads, `/v1/verify-key` requests count as verifications, and other authenticated API requests count as writes. When a request exceeds its rate limit, the API returns `429 Too Many Requests` with a `Retry-After` header indicating how many seconds to wait before retrying. --- ## HTTP API reference Source: https://enzoguard.com/docs/api-reference.md The generated [OpenAPI 3.0 contract](/openapi.yaml) is the canonical reference for request bodies, response bodies, authentication, and status codes. ## Endpoint groups | Group | Paths | Purpose | | --- | --- | --- | | Metadata | `/meta/version`, `/meta/openapi.json` | Inspect the running server and its embedded contract. | | Realms | `/v1/realms`, `/v1/realms/{id}` | Create, list, inspect, and delete realms. | | Apps | `/v1/realms/{realm_id}/apps` | Manage apps within a realm. | | API keys | `/v1/realms/{realm_id}/apps/{app_id}/api-keys` | Create, list, inspect, and delete customer API keys. | | Verification | `/v1/verify-key` | Verify a customer API key. | ## Authentication Metadata endpoints are public. Other endpoints use the `systemKey` bearer security scheme unless the operation explicitly overrides it. ## Contract URLs - [`/openapi.yaml`](/openapi.yaml) is the static contract published with this site. - `/meta/openapi.json` is the contract embedded in a running Enzoguard server. Use the static YAML for code generation and documentation tooling. Use the runtime JSON endpoint when you need to inspect the exact server you are calling. --- ## Documentation for AI agents Source: https://enzoguard.com/docs/ai-access.md Every documentation and blog page is published in both HTML and Markdown. The HTML contains an alternate link to its Markdown representation. ## Discovery files - [`/llms.txt`](/llms.txt) is a compact index of available content. - [`/llms-full.txt`](/llms-full.txt) combines the documentation and blog into one file. - [`/sitemap.xml`](/sitemap.xml) provides the complete HTML URL inventory. - [`/openapi.yaml`](/openapi.yaml) describes the public HTTP interface. ## Page-level Markdown Append `.md` to a page's path. For example: ```text /docs/concepts/ HTML /docs/concepts.md Markdown ``` The page context menu also provides **Copy as Markdown** and **View as Markdown** actions. ## Content guarantees Documentation and blog sources use portable Markdown without Hugo or Hextra shortcodes. An automated site check rejects shortcodes in those sections so the published Markdown remains directly useful outside the website renderer. --- ## Support Source: https://enzoguard.com/docs/support.md ## Contact support Need support? We are here to help you! Email [support@enzoguard.com](mailto:support@enzoguard.com) for help with Enzoguard. We usually try to respond as quickly as possible. Expect a response anywhere within 1 to 3 business days. To help us investigate, include the affected realm or app, relevant timestamps with a time zone, and any error messages or request IDs. Do not send API keys, system keys, passwords, or other secrets. ## Service status Visit [status.enzoguard.com](https://status.enzoguard.com/) for current service availability, incident updates, and maintenance information. If the status page shows that services are operational but you are still having trouble, email support with the details above.