zuplo 6.69.3 → 6.69.5

package/docs/articles/api-key-administration.mdx

@@ -1,6 +1,6 @@
 ---
-title: Managing API Keys in the Portal
-sidebar_label: Managing Keys
+title: Manage Keys in the Portal
+sidebar_label: Manage in the Portal
 ---
 
 API Key Consumers can be managed in the Zuplo Portal's **Services** section.
@@ -8,7 +8,7 @@ Each project is created with three API Key Buckets - one for production, one
 shared by preview environments, and one for development (working copy)
 environments.
 
-![Services](../../public/media/api-key-administration/image.png)
+![Services](../../public/media/api-key-administration/services-page.png)
 
 You can view the buckets for each environment or for all environments using the
 drop down.

package/docs/articles/api-key-api.mdx

@@ -1,6 +1,6 @@
 ---
-title: Using the API Key API
-sidebar_label: Using the API
+title: Use the Developer API
+sidebar_label: Developer API
 ---
 
 Zuplo runs a globally distributed API Key management service that scales to
@@ -13,6 +13,16 @@ end-users in the Zuplo Developer Portal. However, all management operations
 regarding API Keys can also be performed using the
 [Zuplo Developer API](https://zuplo.com/docs/api/api-keys-keys).
 
+:::tip{title="Building API key management into your product?"}
+
+If you want to add self-serve API key creation, rotation, and deletion to your
+own application's UI, see
+[Build Self-Serve API Key Management in Your Product](./api-key-self-serve-integration.mdx)
+for a complete implementation guide with architecture, code examples, and
+security guidance.
+
+:::
+
 :::info
 
 In order to obtain an API Key for the Developer API, go to your account settings
@@ -188,7 +198,7 @@ The response will look like this:
 
 Key rotation is a critical part of API key lifecycle management. Instant
 revocation of a key can break every system that depends on it, so Zuplo supports
-**rolling transitions** — creating a new key while keeping the old key active
+**rolling transitions** - creating a new key while keeping the old key active
 for a defined grace period.
 
 When you call the roll key endpoint, Zuplo:
@@ -204,13 +214,13 @@ old one stops working.
 The right `expiresOn` value depends on how quickly consumers can update their
 keys:
 
-- **Leaked key response** — set `expiresOn` to a past date or within minutes.
+- **Leaked key response** - set `expiresOn` to a past date or within minutes.
   Security incidents demand immediate action; a brief disruption is preferable
   to continued exposure.
-- **Routine rotation** — 24 to 72 hours gives most teams enough time to
+- **Routine rotation** - 24 to 72 hours gives most teams enough time to
   propagate the new key through CI/CD pipelines, environment variables, and
   secret managers.
-- **Scheduled rotation** — for large organizations, 7 to 14 days accommodates
+- **Scheduled rotation** - for large organizations, 7 to 14 days accommodates
   deploy freezes, multi-team coordination, and staged rollouts.
 
 :::tip{title="Multiple keys per consumer"}

package/docs/articles/api-key-authentication.mdx

@@ -1,5 +1,5 @@
 ---
-title: API Key Authentication & Authorization
+title: Authentication and Authorization
 sidebar_label: Authentication
 ---
 

package/docs/articles/api-key-best-practices.mdx

@@ -0,0 +1,199 @@
+---
+title: API Key Best Practices
+sidebar_label: Best Practices
+---
+
+A well-designed API key system handles much more than authentication. It covers
+key format, rotation, leak detection, caching, and the end-user experience. This
+guide covers the 8 practices that define a production-grade API key
+implementation and shows how each one works in Zuplo.
+
+If you have already decided that API keys are the right fit for your API, these
+are the practices that separate a production-grade implementation from a basic
+one.
+
+## 1. Use a structured, prefixed key format
+
+Key format is the foundation everything else in this guide builds on. Checksum
+validation, leak detection, and fast rejection all depend on a well-structured
+key.
+
+API keys should not be random strings with no structure. A good key format
+serves multiple purposes: identification, validation, and integration with
+security tooling.
+
+Zuplo API keys use the format `zpka_<random>_<checksum>`:
+
+- The **`zpka_` prefix** identifies the string as a Zuplo API key in logs,
+  config files, and security scans.
+- The **random body** provides the cryptographic entropy.
+- The **checksum suffix** enables instant format validation without a database
+  call.
+- **Underscore separators** allow double-click selection of the entire key in
+  most text editors and terminals. Keys that use hyphens, dots, or mixed
+  delimiters often result in partial selection, leading to accidental truncation
+  when copying.
+
+This structure means scanners, support teams, and automated tools can all
+identify and validate a Zuplo key on sight.
+
+See [API key format](../concepts/api-keys.md#api-key-format) for the full
+breakdown of each part.
+
+## 2. Enable checksum validation for fast rejection
+
+Building on the structured format, every API key request should go through a
+fast pre-check before touching any database or cache. If the key is malformed -
+a typo, a truncated copy-paste, or random garbage - it should be rejected in
+microseconds.
+
+Zuplo keys include a checksum signature that can be verified mathematically at
+the edge. This happens as part of the
+[validation flow](./api-key-management.mdx#how-authentication-works): the format
+and checksum are checked before any network call, rejecting invalid keys with
+near-zero cost.
+
+## 3. Support secret scanning and leak detection
+
+The structured prefix from practice 1 also enables automated leak detection. API
+keys inevitably end up in places they should not - committed to GitHub, pasted
+in Slack, logged in plaintext. A good key format makes automated detection
+possible.
+
+Zuplo is an official
+[GitHub secret scanning partner](https://github.blog/changelog/2022-07-13-zuplo-is-now-a-github-secret-scanning-partner/).
+When a `zpka_`-prefixed key is committed to any GitHub repository, GitHub
+detects it, verifies the checksum, and notifies Zuplo. You receive an alert with
+the repository URL where the key was found.
+
+This works because of the structured key format - the prefix provides a reliable
+regex pattern, and the checksum eliminates false positives. Leak detection is
+enabled automatically for all keys using the standard format and is available on
+all plans, including free.
+
+See [API Key Leak Detection](./api-key-leak-detection.mdx) for the full scan
+flow and recommended response actions.
+
+## 4. Support key rotation with transition periods
+
+Rotating an API key should not be an all-or-nothing event. Without a transition
+period, a routine key rotation becomes an incident - every system using the old
+key breaks simultaneously. A good rotation mechanism creates a new key while
+keeping the old one active for a defined grace period.
+
+Zuplo's [roll-key API](./api-key-api.mdx#roll-a-consumers-keys) does exactly
+this:
+
+1. Creates a new key with no expiration
+2. Sets an `expiresOn` date on existing keys that have no expiration
+
+This gives consumers time to update their integration before the old key stops
+working. The transition period is configurable - minutes for a leaked key
+response, days or weeks for routine rotation.
+
+Consumers can also manage rotation themselves by creating a second key,
+deploying it, verifying traffic, and then deleting the old key on their own
+schedule. Zuplo supports multiple active keys per consumer for this pattern.
+
+## 5. Use read-through caching at the edge
+
+Validating an API key on every request by hitting a central database adds
+latency and creates a single point of failure. A good system caches validation
+results close to the user.
+
+Zuplo validates API keys at the edge across 300+ data centers. After the first
+validation, the result is cached locally for the configured TTL (default 60
+seconds). Subsequent requests using the same key are served from cache with
+near-zero latency.
+
+The `cacheTtlSeconds` option on the
+[API Key Authentication policy](../policies/api-key-inbound.mdx) controls this
+trade-off:
+
+- **Higher values** reduce latency and database load but delay the effect of key
+  revocation.
+- **Lower values** make revocation faster but increase the frequency of key
+  service lookups.
+- **Default (60 seconds)** is a good balance for most use cases.
+
+Because validation results are cached at the edge, repeated requests with the
+same key - whether valid or invalid - are served from cache rather than hitting
+the key service on every call.
+
+## 6. Choose retrievable or irretrievable keys
+
+This is an architectural decision with security trade-offs in both directions.
+Irretrievable keys (shown once, stored as a hash) force consumers to save the
+key immediately, often in locations you don't control. Retrievable keys let
+consumers go back to the portal when they need the key again.
+
+**Zuplo keys are retrievable.** Consumers can view their keys in the developer
+portal or through the API. This reduces the support burden from lost keys and
+avoids pushing consumers toward insecure storage habits.
+
+For a deeper comparison, see
+[retrievable vs irretrievable keys](./when-to-use-api-keys.md#retrievable-vs-irretrievable-keys).
+
+## 7. Hide keys until needed in the UI
+
+Even with retrievable keys, the default display state should be masked. Keys
+should only be visible when the user explicitly asks to see them, and copying
+should be possible without revealing the key at all.
+
+The Zuplo Developer Portal follows this pattern - keys are masked by default,
+with explicit actions to reveal or copy.
+
+This protects against shoulder-surfing, screen recording, and accidental
+exposure in screenshots or screen shares.
+
+When building a custom integration with the
+[Zuplo Developer API](./api-key-self-serve-integration.mdx), use the
+`key-format=masked` parameter for list views and `key-format=visible` only
+behind an explicit reveal action.
+
+:::tip
+
+Advise your API consumers to store keys in environment variables or a secrets
+manager - never in source code or version control.
+
+:::
+
+## 8. Show key creation dates
+
+Consumers and administrators need to know when a key was created to make
+informed decisions about rotation. A key created three years ago with no
+rotation is a different risk profile than one created last week.
+
+Every Zuplo API key includes a `createdOn` timestamp that is visible in the
+portal, the developer portal, and through the API. This makes it easy to
+identify stale keys that should be rotated and to audit key age across your
+consumer base.
+
+## Putting it all together
+
+These 8 practices are not independent - they reinforce each other:
+
+- The **structured format** (practice 1) enables **checksum validation**
+  (practice 2) and **leak detection** (practice 3).
+- **Edge caching** (practice 5) makes the **checksum pre-check** (practice 2)
+  even faster by avoiding unnecessary cache lookups for malformed keys.
+- **Retrievable keys** (practice 6) combined with **masked display**
+  (practice 7) balance convenience with security.
+- **Rotation with transition periods** (practice 4) combined with **creation
+  dates** (practice 8) give teams the tools to manage key lifecycle without
+  downtime.
+
+Zuplo implements all 8 practices out of the box. There is no configuration
+needed to enable the key format, checksum validation, leak detection, or edge
+caching - they are built into the platform.
+
+## Next steps
+
+- [When to Use API Keys](./when-to-use-api-keys.md) - decide if API keys are the
+  right auth method for your API
+- [API Keys Overview](./api-key-management.mdx) - get started with Zuplo API
+  keys
+- [Build Self-Serve API Key Management](./api-key-self-serve-integration.mdx) -
+  add key management to your own product
+- [API Key Leak Detection](./api-key-leak-detection.mdx) - how GitHub secret
+  scanning works with Zuplo keys

package/docs/articles/api-key-buckets.mdx

@@ -1,5 +1,6 @@
 ---
 title: Buckets and Environments
+sidebar_label: Buckets
 ---
 
 API keys are stored in "buckets," which organize and isolate authentication

package/docs/articles/api-key-end-users.mdx

@@ -1,52 +1,102 @@
 ---
-title: API Key End User Access
-sidebar_label: End User Access
+title: Share Keys with End Users
+sidebar_label: End-User Access
 ---
 
-For any API Key to be useful it needs to be shared with the right end-user.
-Zuplo provides several options depending on the level of customization required.
+Once your API uses [API Key Authentication](../policies/api-key-inbound.mdx),
+the next step is getting a key into the hands of each consumer. Zuplo offers
+three options depending on who creates the key and where the management UI
+lives.
 
-## Dev & Testing
+A **consumer** is the identity that owns one or more API keys (typically a
+customer, team, or application). A **manager** is an email address assigned to a
+consumer that grants self-serve access. When a user signs in to a Developer
+Portal with an email matching the manager email, they see that consumer's keys
+on their settings page.
 
-For development and testing, the easiest way to obtain an API key is right in
-the [Zuplo Management Portal](https://portal.zuplo.com). From inside the **API
-Key Consumers** section in the **Settings** tab you can create and manage
-consumers and their keys.
+## Pick an option
 
-For quick access the newest, non-expired API key is shown in this section.
+| Want this experience                                               | Use                       |
+| ------------------------------------------------------------------ | ------------------------- |
+| Quickly create a key for yourself or a teammate during development | Zuplo Portal (admin only) |
+| Let consumers self-serve through a Zuplo-hosted UI                 | Zuplo Developer Portal    |
+| Build the key management UI inside your own product                | Zuplo Developer API       |
 
-![API key section](../../public/media/api-key-end-users/98a3d62f-1b61-4f41-8bac-665e0b02309e.png)
+The rest of this page expands on each option.
 
-## Zuplo Developer Portal
+:::note
+
+The **Zuplo Portal** ([portal.zuplo.com](https://portal.zuplo.com)) is your
+admin dashboard for building and operating your API. The **Zuplo Developer
+Portal** is the public, customer-facing site you publish for your API consumers.
+They are different products and serve different audiences.
+
+:::
+
+## Manual key creation (admin only)
+
+:::caution
+
+This flow is for development, testing, and ad-hoc use only. Creating keys by
+hand in the admin portal does not scale to a production user base.
+
+:::
 
-If you are using Zuplo's integrated developer portal to share your API with your
-end-users, you can easily enable API Key management to authenticated users of
-the portal.
+For development or one-off needs, the easiest way to obtain an API key is in the
+[Zuplo Portal](https://portal.zuplo.com). Open **Services > API Key Service**,
+click **Configure**, and you can view existing keys or create new keys for your
+consumers manually.
 
-When API Key Managers log into the Developer Portal they can copy, manage, or
-create new API Keys.
+![API key section](../../public/media/api-key-end-users/api-key-service.png)
 
-![API Keys in Developer Portal](../../public/media/api-key-dev-portal.png)
+## Zuplo Developer Portal
+
+If you publish a [Zuplo Developer Portal](../dev-portal/introduction.mdx) for
+your API consumers, you can let authenticated users manage their own keys
+without contacting your team.
 
-## React Component and API
+By default, a consumer's keys are visible to any signed-in user whose email
+matches a manager email assigned to that consumer. Consumers can copy and rotate
+the keys they have access to from the **API Keys** section of the portal.
 
-If you would prefer to integrate API Key management inside of your own portal
-and you are building with React, Zuplo offers an
-[open source API Key Manager component](https://github.com/zuplo/api-key-manager)
-that makes it easy to allow your users self serve access to their keys.
+![API Keys in Developer Portal](../../public/media/api-key-end-users/api-key-portal.png)
 
-Additionally, you can use the
-[Auth Translation API](https://github.com/zuplo/sample-auth-translation-api)
-sample as a starting point for building your management API using Zuplo.
+The default Developer Portal does not include a self-serve flow for creating
+brand-new keys. To enable that you have two options:
 
-You can find a demo of this component at https://api-key-manager.com.
+- **Roll your own self-serve flow.** Follow the
+  [Dev Portal with API Keys example](https://zuplo.com/examples/dev-portal-with-api-keys)
+  to add a "Create key" button backed by your own logic.
+- **Use Zuplo Monetization.**
+  [Monetization](https://zuplo.com/docs/articles/monetization) bundles
+  self-serve key creation with plans, metering, and an upgrade flow in one
+  developer portal. Self-serve via Monetization works on free plans during
+  development; production use of Monetization requires a paid Zuplo plan.
 
 ## Zuplo Developer API
 
-Finally, if you want complete control over the entire experience, you can
-utilize Zuplo's Developer API to manage the full lifecycle of API Consumers and
-Keys.
+Use the [Zuplo Developer API](https://dev.zuplo.com/docs/) when you want
+complete control over the experience, for example building an "API Keys" section
+directly into your product's settings page.
+
+This approach works with any tech stack. Your backend authenticates users with
+your own auth system, then proxies requests to the Zuplo Developer API to
+create, list, rotate, and delete keys on their behalf. You control the UI, the
+access rules, and the onboarding flow.
+
+:::caution
+
+The Zuplo Developer API is a privileged, backend-only API. It accepts a
+management token that grants full access to your account's consumers and keys.
+Never call it from the browser.
+
+:::
+
+To get started:
 
-For more information on using the API to manage consumers and keys, see
-[Programmatic API Key Management](./api-key-api.mdx) and the
-[Zuplo Developer API documentation](https://dev.zuplo.com).
+1. Read the
+   [Build Self-Serve Key Management](./api-key-self-serve-integration.mdx)
+   walkthrough for architecture, code examples, and security guidance.
+2. Refer to [Use the Developer API](./api-key-api.mdx) and the
+   [Zuplo Developer API documentation](https://dev.zuplo.com/docs/) for the raw
+   endpoint reference once you are implementing specific operations.

package/docs/articles/api-key-management.mdx

@@ -15,42 +15,33 @@ To start using Zuplo API Keys in only a few minutes
 
 :::
 
-## Why API keys?
-
-API keys are the standard authentication method for API-first companies like
-Stripe, Twilio, and SendGrid. They are the right choice when you need to
-authenticate an organization, system, or service rather than an individual user
-acting on their own behalf (which is where OAuth excels).
-
-Compared to JWT-based auth, API keys offer simpler developer experience — a
-single string in a header, easy to test with curl, and no token refresh flow.
-API keys are opaque, meaning they don't leak claim structure the way a decoded
-JWT does. And because each key maps to a consumer identity in Zuplo, you can
-revoke access instantly — you don't need to wait for a token to expire.
-
-For a deeper comparison, see the Zuplo blog post on
-[API key authentication best practices](https://zuplo.com/blog/api-key-authentication).
+Not sure if API keys are the right auth method? See
+[When to Use API Keys](./when-to-use-api-keys.md). For the practices that define
+a production-grade implementation, see
+[API Key Best Practices](./api-key-best-practices.mdx).
 
 ## What you get with Zuplo API keys
 
-- **Thoughtful key format** — keys use a `zpka_` prefix, cryptographically
+- **Thoughtful key format** - keys use a `zpka_` prefix, cryptographically
   random body, and checksum signature. The prefix enables
   [GitHub secret scanning](./api-key-leak-detection.mdx), the checksum allows
   instant format validation without a database call, and the underscore
   formatting means a double-click selects the entire key. See
   [API key format](../concepts/api-keys.md#api-key-format) for the full
   breakdown.
-- **Leak detection** — Zuplo is a
+- **Leak detection** - Zuplo is a
   [GitHub secret scanning partner](./api-key-leak-detection.mdx). If a key is
   committed to any GitHub repository, you are notified immediately.
-- **Self-serve key management** — give your API consumers a
+- **Self-serve key management** - give your API consumers a
   [developer portal](./api-key-end-users.mdx) where they can create, view, roll,
-  and revoke their own keys.
-- **Edge validation** — keys are validated at the edge, keeping latency low and
-  your backend protected. See
-  [how validation works](../concepts/api-keys.md#how-validation-works) for
-  details on caching and replication.
-- **Key rotation with transition periods** — the
+  and revoke their own keys. Or
+  [build key management into your own product](./api-key-self-serve-integration.mdx).
+- **Edge validation** - keys are validated through a multi-step process at the
+  edge: format check, checksum verification, cache lookup, then key service
+  query. See
+  [how validation works](../concepts/api-keys.md#how-validation-works) for the
+  full flow.
+- **Key rotation with transition periods** - the
   [roll-key API](./api-key-api.mdx#roll-a-consumers-keys) creates a new key and
   sets an expiration on existing keys, so consumers have time to migrate without
   downtime.
@@ -59,96 +50,28 @@ For a deeper comparison, see the Zuplo blog post on
 
 Zuplo builds and manages the API key infrastructure so you don't have to. The
 service handles key storage, global replication, edge caching, and validation at
-scale — supporting millions of keys and virtually unlimited throughput.
+scale - supporting millions of keys and virtually unlimited throughput.
 
 Keys replicate around the world in seconds. When a key is created, revoked, or
 deleted, the change propagates to all 300+ edge locations within seconds,
 ensuring your API is never open to unauthorized access for longer than the
 configured cache TTL.
 
-## How authentication works
-
-When a request arrives at Zuplo with an API key, the
-[API Key Authentication policy](../policies/api-key-inbound.mdx) validates it
-through a multi-step process:
-
-1. **Format check** — the key is checked for the correct `zpka_` prefix and
-   structure. Malformed keys are rejected immediately without any network call.
-2. **Checksum validation** — the key's built-in checksum signature is verified.
-   This catches typos and garbage keys in microseconds.
-3. **Cache lookup** — the edge checks its local cache for this key. If the key
-   was recently validated (or recently rejected), the cached result is used.
-4. **Key service lookup** — if the key isn't cached, Zuplo's globally
-   distributed key service is queried. The result is then cached for the
-   configured TTL (default 60 seconds).
-
-After successful validation, `request.user` is populated with the consumer's
-identity and metadata, which downstream policies and handlers can use for
-authorization, rate limiting, and routing. See
-[how validation works](../concepts/api-keys.md#how-validation-works) for more
-details.
-
-:::note
-
-The `cacheTtlSeconds` option on the API Key Authentication policy controls how
-long validation results are cached at each edge location. Higher values reduce
-latency but delay the effect of key revocation. A revoked key could still be
-accepted for up to `cacheTtlSeconds` after revocation. The default of 60 seconds
-is a good balance for most use cases.
-
-:::
-
-## Key Concepts
-
-### Consumers
-
-An API Key Consumer is the identity that can invoke your API - typically people,
-customers, partners or services. A consumer can have multiple API Keys
-associated with it - but each key authorizes the same consumer (for example
-identity)
-
-### Consumer Metadata
-
-Each consumer can be assigned metadata. This information (a
-[small JSON object](./api-key-service-limits.mdx)) is made available to the
-runtime when a user access your API using that key.
-
-For example, a Consumer might have metadata that specifies the company they're a
-member of and the plan for the account.
-
-```json
-{
-  "companyId": 123,
-  "plan": "gold"
-}
-```
-
-### Consumer Tags
-
-Consumers can also have tags associated with them. Tags are simple key value
-pairs. Tags are used for management purposes only (for example querying
-consumers through the Zuplo API). Tags don't get sent to the runtime as part of
-authorization.
-
-For example, a Consumer might be tagged in order to track the customer
-associated with the consumer.
-
-```txt
-customer=1234
-```
-
-You can see more on how to use tags in the document on
-[managing consumers and keys using the API](./api-key-api.mdx)
-
-### API Keys
-
-API Keys are the actual string value used to authenticate with an API. Unlike
-some other forms of bearer tokens, API Keys don't contain any actual data within
-the key itself.
-
-Zuplo API Keys use a structured format: a `zpka_` prefix, a cryptographically
-random body, and a checksum signature. This format enables
-[leak detection via GitHub secret scanning](./api-key-leak-detection.mdx) and
-allows instant format validation without a database call. Zuplo's API Key
-management service also supports custom key formats (enterprise plan required),
-though custom formats lose leak detection support.
+## Key concepts
+
+The API key system has three core objects. For full details, see the
+[API Keys concepts page](../concepts/api-keys.md).
+
+- **Consumers** - the identities that own API keys. Each consumer has a unique
+  `name` within its bucket (used as `request.user.sub` at runtime), optional
+  [metadata](../concepts/api-keys.md#consumer-metadata) available on every
+  authenticated request, and optional
+  [tags](../concepts/api-keys.md#tags-vs-metadata) for management queries.
+- **API Keys** - the credential strings used to authenticate. Each consumer can
+  have multiple keys. All keys for a consumer share the same identity and
+  metadata. Keys use the `zpka_` format by default; enterprise customers can use
+  [custom key formats](../concepts/api-keys.md#api-key-format), though custom
+  formats lose leak detection support.
+- **Buckets** - group consumers for an environment. Each project has buckets for
+  production, preview, and development. See
+  [API Key Buckets](./api-key-buckets.mdx) for details.

package/docs/articles/api-key-react-component.mdx

@@ -83,8 +83,23 @@ const MyComponent = () => {
 
 ## Backend API
 
-The API Key Manager component interacts with an API that allows authorized users
-to manage their own keys. The easiest way to get started is to use the
+The React component does not call the Zuplo Developer API directly. Instead, it
+talks to a backend API that you control - this backend authenticates the user
+with your own auth system, then proxies requests to the Zuplo Developer API
+using your Zuplo API key. This keeps your Zuplo credentials server-side and lets
+you enforce access control (for example, ensuring users can only manage keys for
+their own organization).
+
+The `<BASE_URL>` in the usage example above should point to this backend API.
+The `<ACCESS_TOKEN>` is your own auth token (session cookie, JWT, etc.) that
+your backend uses to identify the user.
+
+The easiest way to get started is to use the
 [Auth Translation API](https://github.com/zuplo/sample-auth-translation-api)
-sample and deploy it to [Zuplo](https://zuplo.com). By default this sample
-connects the [Zuplo API Key Management Service](./api-key-management.mdx).
+sample and deploy it to [Zuplo](https://zuplo.com). This sample provides the
+backend endpoints the component expects and connects to the
+[Zuplo API Key Management Service](./api-key-management.mdx) out of the box.
+
+For a full walkthrough of building this backend yourself (including the
+architecture, all API operations, and security considerations), see
+[Build Self-Serve API Key Management in Your Product](./api-key-self-serve-integration.mdx).