Zuplo Changelog

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.

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.

We have added a new plugin for Curity Phantom Tokens, which allows developers to take advantage of the Curity Identity Management solution. This plugin uses Curity's unique Phantom Token approach which is a privacy-preserving token usage pattern for microservices. It combines the benefits of opaque and structured tokens. To read more about phantom tokens see this document.

To learn more, please view our Policy documentation.

Previously, Zuplo maintained separate infrastructures for development environments (working copy) and production APIs. We have now migrated to a unified infrastructure, where development environments use the same environments as production APIs.

• Consistency: Development environments are now exactly the same as production and preview environments. This ensures that the behavior in development matches that in production, reducing the likelihood of unexpected issues after deployment.

• Global Reach: Development environments are now deployed to over 300 edge locations. This allows developers to test their changes in an environment that closely mimics the distributed nature of our production infrastructure.

• Scalability: Development environments are now fully scalable. This means that they can handle increased load when necessary, providing a more accurate representation of production performance.

• Deployment Time: The trade-off for these benefits is a slightly longer deployment time. However, we are actively working on optimizing our deployment processes to reduce this time.

We believe that the benefits of this change significantly outweigh the trade-offs, and we are excited to see how it improves our development process moving forward.

We are excited to announce the release of API Monetization, a new feature that enables developers to charge for use of their APIs. This feature is available to all Zuplo users and can be configured through the Zuplo Portal. This feature is currently in beta, and we welcome feedback from our users. We aim to make this feature generally available in the coming months.

For more detail see the blog post on API Monetization: API Monetization Release

Logging plugins now include several new fields to help filter logs for different environment types:

• environment: This is the name of your Zuplo environment. This will be the same as your Zuplo subdomain. i.e. if your Zuplo URL is https://silver-lemming-main-b0cef33.zuplo.app, the environment is silver-lemming-main-b0cef33
• environmentType: This indicates where your environment is running. Possible values are:
  • edge: Environments deployed to our 300+ edge locations
  • working-copy: Environments deployed to your single-instance dev server
  • local: When running with Zuplo local development
• environmentStage: This indicates the deployment stage of your environment. Possible values are:
  • production: Environments deployed from your default git branch
  • preview: Environments deployed from any other git branch
  • working-copy: Environments deployed to your single-instance dev server
  • local: When running with Zuplo local development

A new Log Plugin is available for SumoLogic that enables sending your API Gateway logs to SumoLogic.

See the documentation for information on how to setup the plugins. The following are all the log plugins currently available:

• DataDog
• Dynatrace
• Google Cloud Logging
• Loki
• SumoLogic