Zuplo Changelog

When your API throws an error in local development, you will now see a formatted output that includes the error message and stack trace in a more readable format. This will help you quickly identify the issue and debug your application.

We have overhauled the local development logs to provide a cleaner and more useful output. The new logs make it easier to see the HTTP method, route, and status code for each request. This will help you quickly identify issues and debug your application.

The logs are now color-coded to make it easier to distinguish between different HTTP methods and errors are highlighted in red. Additionally, the logs are now formatted in a more readable way, making it easier to scan through the output.

We have made a number of improvements to the create-zuplo-api package to make it even easier to start a Zuplo API project locally. The updated package includes the following enhancements:

• Option to include ESLint and Prettier configuration files in the project
• Improved error handling and messaging
• Automatically installing dependencies after project creation

The Zuplo Identity Token is a new feature that allows developers to create a JWT token that uniquely and securely identifies their Zuplo API. This token can be used to authenticate downstream services or third-party APIs, enabling secure communication between services without the need for additional authentication mechanisms or sharing of sensitive credentials.

The Zuplo Identity Token is a JSON Web Token (JWT) that contains information about the Zuplo API that it represents. This token is signed by Zuplo and can be verified by downstream services or third-party APIs to ensure its authenticity and integrity.

The token contains claims for the Zuplo account, project, and deployment that can be used to uniquely identify the API and its associated resources. See the Zuplo Identity Token documentation for more information.

Using the Token#

Developers can access the Zuplo Identity Token in their code by calling the ZuploServices API. A custom audience can be provided to the token to ensure that it is only usable by the intended downstream service. Multiple tokens with different audiences can be created and caching is managed by Zuplo to ensure high performance.

import { ZuploServices, ZuploContext, ZuploRequest } from "@zuplo/runtime";

export default async function handler(
  request: ZuploRequeset,
  context: ZuploContext,
) {
  const idToken = await ZuploServices.getIDToken(context, {
    audience: "https://my-api.example.com",
  });

  const response = await fetch("https://my-api.example.com", {
    headers: {
      Authorization: `Bearer ${idToken}`,
    },
  });
}

Federated Identity increases the security of your Zuplo API by removing the need to share sensitive service account keys with your Zuplo API. Instead, Zuplo will use the Zuplo Identity Token to authenticate with Google Cloud Services on your behalf.

A new policy has been added to Zuplo that enables Federated Identity with Google Cloud Services. By utilizing this policy developers can secure their GCP API or other Google Cloud Resources (Storage, Pub/Sub, etc.) with GCP IAM and allow Zuplo to call these services on their behalf.

Federated Identity with GCP is available as a paid-addon to customers on enterprise plans. Contact your account manager or sales@zuplo.com to inquire about pricing.

For more information on how to configure Federated Identity with GCP, see the Federated Identity with GCP documentation.

Role-Based Access Control allows you to assign specific roles to users who access the Zuplo Portal. These roles determine the permissions that users have and the actions they can perform. For example, you can assign roles such as "Admin", "Developer", or "Viewer", each with different levels of access to resources and functionality.

With RBAC, you can:

• Assign roles to users based on their responsibilities and access requirements.
• Limit access to production resources to only select users.
• Enable more users access to the Zuplo Portal, such as API Analytics, without compromising security.

See the Account Members & Roles documentation for more information.

Developers can use Zuplo's CLI and API to automate tasks with the Zuplo platform. For example, you can create a custom CI/CD process to publish your Zuplo API or automate the management of environment variables. Previously, each account had only a single API key, which granted full access to all resources and functionality. With Fine-Grained API Keys, you can create multiple API keys with limited permissions.

These new capabilities allow:

• Create API keys with specific permissions for specific tasks, environments, or projects.
• Set expiration dates on API Keys to ensure that they are only valid for a limited time.
• Administrators can view and manage all API keys in the Zuplo portal to maintain security of their resources.

See the Zuplo API Key documentation for more information.

Over the past month, we have made several improvements to the API Monetization beta:

• Better Error Handling for Stripe Webhooks: We have improved the error handling for Stripe webhooks to ensure more robust and reliable operation.

• Improved Documentation: We have updated and expanded the documentation to provide clearer and more comprehensive guidance.

• Additional Logging: We have added more logging to help diagnose and troubleshoot issues more effectively.

• Editable Plans: We have made plans editable, allowing developers to modify quotas or fix misconfigurations as needed.

These improvements are part of our ongoing effort to refine and enhance the API Monetization beta. We have more enhancements planned before the General Availability (GA) release, and we aim to stabilize the feature in the next month.

We added a new plugin for API Brownouts, which allows developers to simulate outages of their API. This is useful for migrating users off of old versions of their API. You can read more about API Brownouts in our blog post here.

To learn more, please view our Policy documentation.