@zuplo/runtime 5.2340.0 → 5.2342.0

package/out/types/index.d.ts

@@ -2,15 +2,8 @@ import { KeyLike } from 'jose';
 import type { ValidateFunction as ValidateFunction_2 } from 'ajv';
 
 /**
- * Amberflo is a usage metering and billing service. This policy allows you to send metering calls for each API to their meter ingest endpoint.
- *
- * @remarks
- * Amberflo {@link https://www.amberflo.io|amberflo.com} is a usage metering and
- * billing service. This policy allows you to meter API calls going through Zuplo
- * and send them to your Amberflo account using your Amberflo API key.
- *
- * Add the policy to each route you want to meter. Note you can specify the Meter
- * API Name and Meter Value (meter increment) at the policy level.
+ * Amberflo is a usage metering and billing service. This policy allows
+ * you to send metering calls for each API to their meter ingest endpoint.
  *
  * @title Amberflo Metering / Billing
  * @public
@@ -79,16 +72,7 @@ declare interface AmberfloMeteringProperties extends Omit<AmberfloMeteringIngest
 }
 
 /**
- * Authenticates requests based on API Keys using Zuplo API Management. You
- * can learn more about the Zuplo API Key Service
- * [here](https://zuplo.com/docs/articles/api-key-api#buckets)
- *
- * @remarks
- * This policy uses the managed API key storage provided by Zuplo.
- * `allowUnauthenticatedRequests` defaults to false and rejects any request without
- * a valid API key (returning a `401 - Unauthorized` response). You can override
- * (set `"allowUnauthenticatedRequests" : true`) this to support multiple
- * authentication methods or support both authenticated and anonymous requests.
+ * Authenticates requests based on API Keys using Zuplo API Management.
  *
  * @deprecated Please use the new {@link https://zuplo.com/docs/policies/api-key-inbound|API Key Authentication} policy
  * instead. This policy will continue to work but will be removed in a future
@@ -116,19 +100,7 @@ export declare interface ApiAuthKeyInboundPolicyOptions {
 }
 
 /**
- * Authenticates requests based on API Keys using Zuplo API Management. You can learn more about the Zuplo API Key Service [here](https://zuplo.com/docs/articles/api-key-api#buckets)
- *
- * @remarks
- * Authenticate requests with Zuplo's fully managed API Key service. This policy is
- * the easiest way to secure your API and can be combined with other policies like
- * Rate limiting, quotas, and more to build a fully featured API to support your
- * partners, developers, or customers.
- *
- * For more information on Zuplo's API Key Management service and options enabling
- * self-serve API Key management see the following resources:
- *
- * - {@link https://zuplo.com/docs/articles/api-key-management|API Key Authentication Overview}
- * - {@link https://zuplo.com/docs/articles/api-key-api|API Key Management API}
+ * Authenticates requests based on API Keys using Zuplo API Management.
  *
  * @title API Key Authentication
  * @public
@@ -304,11 +276,6 @@ declare interface AuditLogRequestFilter {
 /**
  * Authenticate users using Auth0 issued JWT tokens.
  *
- * @remarks
- * Authenticate requests with JWT tokens issued by Auth0. This is a customized
- * version of the {@link https://zuplo.com/docs/policies/open-id-jwt-auth-inbound|OpenId JWT Policy} specifically
- * for Auth0.
- *
  * @title Auth0 JWT Auth
  * @public
  * @param request - The ZuploRequest
@@ -474,19 +441,6 @@ export declare class AWSLoggingPlugin extends LogPlugin {
 /**
  * Authorize requests using Axiomatics Policy Server.
  *
- * @remarks
- * This policy will authorize requests using Axiomatics Policy Server. If the
- * request is not authorized, a 403 response will be returned.
- *
- * This policy is designed to be highly customizable in order to tailor the
- * authorization requests to the specific needs of your application. You can
- * add default attributes on the policy that are included in every request, or
- * you can programmatically add attributes to the request using the
- * `setAuthAttributes` method.
- *
- * Using this policy in conjunction with an authorization policy will automatically
- * set AttributeSubject attributes for the user in the request.
- *
  * @title Axiomatics Authorization Inbound
  * @beta
  * @param request - The ZuploRequest
@@ -644,17 +598,6 @@ declare interface BasicAuthAccount {
 /**
  * Authenticate requests using basic auth (i.e. username and password)
  *
- * @remarks
- * The Basic Authentication policy allows you to authenticate incoming requests
- * using the Basic authentication standard. You can configure multiple accounts
- * with different passwords and a different bucket of user 'data'.
- *
- * The API will expect a Basic Auth header (you can generate samples
- * {@link https://www.debugbear.com/basic-auth-header-generator|here}). Requests with
- * invalid credentials (or no header) will not be authenticated. Authenticated
- * requests will populate the `user` property of the `ZuploRequest` parameter on
- * your RequestHandler.
- *
  * @title Basic Auth
  * @public
  * @param request - The ZuploRequest
@@ -689,20 +632,6 @@ declare interface BatchDispatcherOptions {
 /**
  * Authenticate requests based on the mTLS protocol.
  *
- * @remarks
- * The brownout policy allows performing scheduled downtime on your API. This can
- * be useful for helping notify clients of an impending deprecation or for
- * scheduling maintenance.
- *
- * This policy uses {@link https://crontab.guru|cron schedules} to check if a request
- * should experience a brownout or not. When a request falls into a scheduled
- * brownout an error response will be return. The error response can be customized
- * by setting the `problem` properties.
- *
- * For more information using brownouts to alert clients on impending API
- * changes/deprecations see our blog post
- * {@link https://zuplo.com/blog/2022/05/17/how-to-version-an-api|How to version an API}
- *
  * @title Brown Out
  * @public
  * @param request - The ZuploRequest
@@ -913,11 +842,6 @@ export declare interface ClearHeadersOutboundPolicyOptions {
 /**
  * Authenticate users using Clerk issued JWT tokens.
  *
- * @remarks
- * Authenticate requests with JWT tokens issued by Clerk. This is a customized
- * version of the {@link https://zuplo.com/docs/policies/open-id-jwt-auth-inbound|OpenId JWT Policy} specifically
- * for Clerk.
- *
  * @title Clerk JWT Auth
  * @public
  * @param request - The ZuploRequest
@@ -971,14 +895,6 @@ declare interface ClientCredentialsConfig {
 /**
  * Authenticate requests with JWT tokens issued by AWS Cognito.
  *
- * @remarks
- * Authenticate requests with JWT tokens issued by AWS Cognito. This is a
- * customized version of the {@link https://zuplo.com/docs/policies/open-id-jwt-auth-inbound|OpenId JWT Policy}
- * specifically for AWS Cognito.
- *
- * See {@link https://zuplo.com/docs/articles/oauth-authentication|this document} for more information
- * about OAuth authorization in Zuplo.
- *
  * @title AWS Cognito JWT Auth
  * @public
  * @param request - The ZuploRequest
@@ -1048,10 +964,6 @@ export declare type ComplexRateLimitFunction = RateLimitFunction<ComplexCustomRa
  * The Complex Rate Limiting policy is an advanced rate limiting policy that
  * let's you set rate limits based on custom counters (not just requests)
  *
- * @remarks
- * You can use the Complex Rate Limiting policy to limit the number of requests
- * based on complex counters, based on details of the request or the response
- *
  * @title Complex Rate Limiting
  * @enterprise
  * @param request - The ZuploRequest
@@ -1064,20 +976,6 @@ export declare class ComplexRateLimitInboundPolicy extends InboundPolicy<Complex
     /**
      * Override the increments for a limit in the current request.
      *
-     * @remarks
-     * If your policy is has a limit set as follows:
-     *
-     * ```
-     * "limits": {
-     *   "compute": 10
-     * }
-     * ```
-     *
-     * You can use this function to override the increments of the `compute` limit
-     * by calling `setIncrements(context, { compute: 5 })` on a custom policy.
-     * This can be useful if you want to dynamically change the increments of a limit
-     * based on data in the response (say a header).
-     *
      * @param context - The ZuploContext
      * @param increments - The increments to set.
      */
@@ -1126,13 +1024,6 @@ export declare interface ComplexRateLimitInboundPolicyOptions {
 /**
  * Creates a composite, or group policy - composed of other policies. For reuse across routes.
  *
- * @remarks
- * The Composite policy allows you to create groups of other policies, for easy
- * reuse across multiple routes. Other policies are referenced by their `name`.
- *
- * Be careful not to create circular references which can cause your gateway to
- * fail.
- *
  * @title Composite Inbound (Group Policies)
  * @public
  * @param request - The ZuploRequest
@@ -1312,11 +1203,6 @@ export declare class CryptoBeta extends BaseCryptoBeta {
 /**
  * Authenticate users using the Curity Phantom Token Pattern.
  *
- * @remarks
- * Authenticate requests with Phantom Tokens issued by Curity. The payload of the
- * Phantom JWT token, if successfully authenticated, with be on the
- * `request.user.data` object accessible to the runtime.
- *
  * @title Curity Phantom Token Auth
  * @public
  * @param request - The ZuploRequest
@@ -1448,14 +1334,6 @@ export declare interface ErrorHandler {
 /**
  * Authenticate users using Firebase issued JWT tokens.
  *
- * @remarks
- * Authenticate requests with JWT tokens issued by Firebase. The payload of the JWT
- * token, if successfully authenticated, with be on the `request.user.data` object
- * accessible to the runtime.
- *
- * See {@link https://zuplo.com/docs/articles/oauth-authentication|this document} for more information
- * about OAuth authorization in Zuplo.
- *
  * @title Firebase JWT Auth
  * @public
  * @param request - The ZuploRequest
@@ -3069,15 +2947,8 @@ declare interface MoesifContext {
 }
 
 /**
- * Moesif is an API analytics and billing service. This policy allows you to send metering calls for each API to their events batch endpoint.
- *
- * @remarks
- * Moesif {@link https://moesif.com|moesif.com} is an API analytics and monetization
- * platform. This policy allows you to measure (and meter) API calls flowing
- * through your Zuplo gateway.
- *
- * Add the policy to each route you want to meter. Note you can specify the Meter
- * API Name and Meter Value (meter increment) at the policy level.
+ * Moesif is an API analytics and billing service. This policy allows you to
+ * send metering calls for each API to their events batch endpoint.
  *
  * @title Moesif Analytics & Billing
  * @public
@@ -3110,13 +2981,6 @@ export declare interface MoesifInboundPolicyOptions {
 /**
  * The Monetization policy enables you to track & monetize by your API's usage
  *
- * @remarks
- * The Monetization policy allows you to track and monetize the usage of our API resources,
- * declaratively and programatically.
- *
- * Follow our {@link https://zuplo.com/docs/articles/monetization-dev-portal-setup|Quickstart guide for Monetization}
- * to get started.
- *
  * @title Monetization
  * @beta
  * @param request - The ZuploRequest
@@ -3199,11 +3063,6 @@ declare interface NotFoundOptions {
 /**
  * Authorize requests using Okta FGA.
  *
- * @remarks
- * This policy will authorize requests using Okta FGA. If the
- * request is not authorized, a 403 response will be returned.
- *
- *
  * @title Okta FGA Authorization Inbound
  * @beta
  * @param request - The ZuploRequest
@@ -3252,14 +3111,6 @@ export declare interface OktaFGAAuthZInboundPolicyOptions {
 /**
  * Authenticate users using Okta issued JWT tokens.
  *
- * @remarks
- * Authenticate requests with JWT tokens issued by Okta. This is a customized
- * version of the {@link https://zuplo.com/docs/policies/open-id-jwt-auth-inbound|OpenId JWT Policy} specifically
- * for Okta.
- *
- * See {@link https://zuplo.com/docs/articles/oauth-authentication|this document} for more information
- * about OAuth authorization in Zuplo.
- *
  * @title Okta JWT Auth
  * @public
  * @param request - The ZuploRequest
@@ -3786,11 +3637,6 @@ declare namespace OpenAPIV3_1 {
 /**
  * Authorize requests using OpenFGA.
  *
- * @remarks
- * This policy will authorize requests using OpenFGA. If the
- * request is not authorized, a 403 response will be returned.
- *
- *
  * @title OpenFGA Authorization Inbound
  * @beta
  * @param request - The ZuploRequest
@@ -3847,22 +3693,8 @@ declare interface OpenFGACheck {
 }
 
 /**
- * The Open ID JWT Authentication policy allows you to authenticate incoming requests using an Open ID compliant bearer token.
- *
- * @remarks
  * The Open ID JWT Authentication policy allows you to authenticate incoming
- * requests using an Open ID-compliant bearer token. It works with common
- * authentication services like Auth0 (sample here) but should also work with any
- * valid Open ID JWT token.
- *
- * When configured, you can have Zuplo check incoming requests for a JWT token and
- * automatically populate the `ZuploRequest` 's `user` property with a user object.
- * This `user` object will have a `sub` property - taking the `sub` id from the JWT
- * token. It will also have a `data` property populated by other data returned in
- * the JWT token (including any claims).
- *
- * See {@link https://zuplo.com/docs/articles/oauth-authentication|this document} for more information
- * about OAuth authorization in Zuplo.
+ * requests using an Open ID compliant bearer token.
  *
  * @title JWT Auth
  * @public
@@ -4109,11 +3941,6 @@ export declare class ProblemResponseFormatter {
 /**
  * Authenticate users using PropelAuth issued JWT tokens.
  *
- * @remarks
- * Authenticate requests with JWT tokens issued by {@link https://propelauth.com|PropelAuth}.
- * This is a customized version of the {@link https://zuplo.com/docs/policies/open-id-jwt-auth-inbound|OpenId JWT Policy}
- * specifically for PropelAuth.
- *
  * @title PropelAuth JWT Auth
  * @public
  * @param request - The ZuploRequest
@@ -4165,21 +3992,8 @@ declare type RateLimitHeaderMode = "none" | "retry-after";
 declare type RateLimitHeaderMode_2 = "none" | "retry-after";
 
 /**
- * The rate-limiting policy is used to limit the number of requests that can be made against your API based on a key.
- *
- * @remarks
- * Rate-limiting allows you to set a maximum rate of requests for your API gateway.
- * This is useful to enforce rate limits agreed with your clients and protect your
- * downstream services.
- *
- * The Zuplo Rate-Limit allows you to limit based on different attributes of the
- * incoming request. For example, you might set a rate limit of 10 requests per
- * second per user, or 20 requests per second for a given IP address.
- *
- * The Zuplo rate-limiter also allows you to set a custom bucket name by which to
- * effect a rate-limit using a function.
- *
- * When a client reaches a rate limit - they will receive a `429` response code.
+ * The rate-limiting policy is used to limit the number of requests that
+ * can be made against your API based on a key.
  *
  * @title Rate Limiting
  * @public
@@ -4270,12 +4084,8 @@ declare interface ReadmeMeteringInboundPolicyOptions {
 }
 
 /**
- * Readme is a developer documentation and API metrics company. This policy pushes logs to their API calls dashboard.
- *
- * @remarks
- * {@link https://readme.com|Readme} is a developer Documentation and
- * metrics service. This policy pushes the request/response data to their ingestion
- * endpoint so you can see your Zuplo API traffic in their API calls dashboard.
+ * Readme is a developer documentation and API metrics company. This
+ * policy pushes logs to their API calls dashboard.
  *
  * @title Readme Metrics
  * @public
@@ -4483,15 +4293,7 @@ export declare interface RequestUser<TUserData> {
 }
 
 /**
- * Validate inbound requests based on Open API specification
- *
- * @remarks
- * The Request Validation policy is used to validate incoming requests based on
- * schemas in OpenAPI specifications.
- *
- * When configured, any requests that do not conform to your OpenAPI schema will be
- * rejected with a `400: Bad Request` response containing a detailed error message
- * (in JSON) explaining why the request was not accepted.
+ * Validate inbound requests based on Open API specification.
  *
  * @title Request Validation
  * @public
@@ -4524,20 +4326,6 @@ export declare interface RequestValidationInboundPolicyOptions {
 /**
  * Sets an allow-list for an origin header
  *
- * @remarks
- * The Require Origin policy is used to enforce that the client is sending an
- * `origin` header that matches your allow-list specified in the policy options.
- *
- * This is useful if you want to stop any browser traffic from different domains.
- *
- * However, it is important to note that it does not guarantee that traffic is only
- * coming from a browser. Somebody could simulate a browser request from a backend
- * server and set any origin they like.
- *
- * If the incoming origin is missing, or not allowed - a 400 Forbidden Problem
- * Response will be sent to the client. You can customize the `detail` property in
- * the policy options.
- *
  * @title Require Origin
  * @public
  * @param request - The ZuploRequest
@@ -4723,15 +4511,8 @@ export declare interface ServiceProvider {
 /* Excluded from this release type: ServiceProviderImpl */
 
 /**
- * Sets the body of the request in the inbound pipeline - make sure to convert a GET/HEAD request to another method when using this policy.
- *
- * @remarks
- * The Set Body policy allows you to set or override the incoming request body.
- * {@link https://zuplo.com/docs/articles/zp-body-removed|GET or HEAD requests do not support bodies on Zuplo},
- * so be sure to use the {@link https://zuplo.com/docs/policies/change-method-inbound|Change Method}
- * policy to update the method to a `POST` or whatever is appropriate. You might
- * also need to use the {@link https://zuplo.com/docs/policies/set-headers-inbound|Set Header} policy to
- * set a `content-type`.
+ * Sets the body of the request in the inbound pipeline - make sure to convert
+ * a GET/HEAD request to another method when using this policy.
  *
  * @title Set Body
  * @public
@@ -4756,10 +4537,6 @@ export declare interface SetBodyInboundPolicyOptions {
 /**
  * Adds or sets headers on the incoming request.
  *
- * @remarks
- * The set header policy adds a header to the request in the inbound pipeline. This
- * can be used to set a security header required by the downstream service.
- *
  * @title Add or Set Request Headers
  * @public
  * @param request - The ZuploRequest
@@ -4963,10 +4740,6 @@ export declare interface StripeMonetizationPluginOptions {
 /**
  * The Stripe Webhook policy validates the authenticity of an incoming Stripe webhook.
  *
- * @remarks
- * The Stripe Webhook policy secures your incoming webhooks by validating that
- * the request was sent by Stripe.
- *
  * @title Stripe Webhook Auth
  * @public
  * @param request - The ZuploRequest
@@ -5017,21 +4790,8 @@ export declare class SumoLogicLoggingPlugin extends LogPlugin {
 }
 
 /**
- * The Supabase JWT Authentication policy supports user JWT tokens created by Supabase.
- *
- * @remarks
- * The Supabase JWT Authentication policy allows you to authenticate incoming
- * requests using a token created by {@link https://supabase.com|supabase.com}.
- *
- * When configured, you can have Zuplo check incoming requests for a JWT token and
- * automatically populate the `ZuploRequest`'s `user` property with a user object.
- *
- * This `user` object will have a `sub` property - taking the `sub` id from the JWT
- * token. It will also have a `data` property populated by other data returned in
- * the JWT token - including all your claims, `user_metadata` and `app_metadata`.
- *
- * You can also require specific claims to have specific values to allow
- * authentication to complete, providing a layer of authorization.
+ * The Supabase JWT Authentication policy supports user JWT tokens created
+ * by Supabase.
  *
  * @title Supabase JWT Auth
  * @public
@@ -5131,18 +4891,8 @@ declare interface UnauthenticatedCredentialConfig {
 }
 
 /**
- * Uses Azure Active Directory to add an Authorization header to the request in order to authenticate requests using Azure identity.
- *
- * @remarks
- * This policy adds a `Authorization` header to the upstream request that allows
- * using Azure AD to authenticate requests to your origin server. This is a useful
- * means of securing your origin server so that only your Zuplo gateway can make
- * requests against it.
- *
- * Using this policy allows you to delegate authentication and authorization to
- * your gateway without writing any code on your origin service. For instructions
- * on how to configure Azure AD authentication see
- * {@link https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad | Configure your App Service or Azure Functions app to use Azure AD login}.
+ * Uses Azure Active Directory to add an Authorization header to the request
+ * in order to authenticate requests using Azure identity.
  *
  * @title Upstream Azure AD Service Auth
  * @public
@@ -5181,19 +4931,8 @@ export declare interface UpstreamAzureAdServiceAuthInboundPolicyOptions {
 }
 
 /**
- * Creates a Firebase Admin token and attaches it to the outgoing request. Useful when calling Firebase services as an administrator.
- *
- * @remarks
- * This policy adds a Firebase Admin token to the outgoing `Authentication` header
- * allowing requests to Firebase using Service Account admin permissions. This can
- * be useful for calling Firebase services such as Firestore through a Zuplo
- * endpoint that is secured with other means of Authentication such as API keys.
- * Additionally, this policy can be useful for service content to all API users
- * (for example serving a specific Firestore document containing configuration
- * data)
- *
- * We recommend reading the `serviceAccountJson` from environment variables (so it
- * is not checked in to source control) using the `$env(ENV_VAR)` syntax.
+ * Creates a Firebase Admin token and attaches it to the outgoing request.
+ * Useful when calling Firebase services as an administrator.
  *
  * @title Upstream Firebase Admin Auth
  * @public
@@ -5224,19 +4963,8 @@ export declare interface UpstreamFirebaseAdminAuthInboundPolicyOptions {
 }
 
 /**
- * Creates a Firebase custom user token and attaches it to the outgoing request. Useful when calling Firebase services as user.
- *
- * @remarks
- * This policy adds a Firebase Admin token to the outgoing `Authentication` header
- * allowing requests to Firebase using Service Account admin permissions. This can
- * be useful for calling Firebase services such as Firestore through a Zuplo
- * endpoint that is secured with other means of Authentication such as API keys.
- * Additionally, this policy can be useful for service content to all API users
- * (for example serving a specific Firestore document containing configuration
- * data)
- *
- * We recommend reading the `serviceAccountJson` from environment variables (so it
- * is not checked in to source control) using the `$env(ENV_VAR)` syntax.
+ * Creates a Firebase custom user token and attaches it to the outgoing
+ * request. Useful when calling Firebase services as user.
  *
  * @title Upstream Firebase User Auth
  * @public
@@ -5284,17 +5012,9 @@ export declare interface UpstreamFirebaseUserAuthInboundPolicyOptions {
 }
 
 /**
- * Creates a self-signed JWT token (generated using a Google Service Account JSON) and attaches it to the outgoing request. Useful when calling GCP services like Cloud Endpoints / ESPv2
- *
- * @remarks
- * This policy adds a JWT token to the headers, ready for us in an outgoing request
- * when calling a GCP service (e.g. Cloud Endpoints / ESPv2). We recommend reading
- * the `serviceAccountJson` from environment variables (so it is not checked in to
- * source control) using the `$env(ENV_VAR)` syntax.
- *
- * CAUTION: This policy only works with {@link https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth | certain Google APIs}.
- * In most cases, the {@link https://zuplo.com/docs/policies/upstream-gcp-service-auth-inbound | Upstream GCP Service Auth}
- * should be used.
+ * Creates a self-signed JWT token (generated using a Google Service Account
+ * JSON) and attaches it to the outgoing request. Useful when calling GCP
+ * services like Cloud Endpoints / ESPv2
  *
  * @title Upstream GCP Self-Signed JWT
  * @public
@@ -5321,25 +5041,9 @@ export declare interface UpstreamGcpJwtInboundPolicyOptions {
 }
 
 /**
- * Creates an ID Token from Google's OAuth service and attaches it to the outgoing request. Useful when calling GCP services or Google APIs that are secured with GCP IAM.
- *
- * @remarks
- * This policy allows you to delegate authentication and authorization to your
- * gateway without writing any code on your origin service by adding a GCP Issued
- * ID Token to outgoing header allowing the service to be secured with GCP IAM.
- * This is a useful means of securing your origin server so that only your Zuplo
- * gateway can make requests against it.
- *
- *
- * This policy works with
- * {@link https://zuplo.com/docs/articles/gke-with-upstream-auth-policy|GCP Identity Aware Proxy}
- * or services like {@link https://cloud.google.com/iap/docs/managing-access|Cloud Run}
- * that natively support IAM authorization.
- *
- * We recommend reading the `serviceAccountJson` from environment variables (so it
- * is not checked in to source control) using the `$env(ENV_VAR)` syntax.
- *
- * For information on how Google's service based auth works see {@link https://cloud.google.com/functions/docs/securing/authenticating|Authenticating for invocation}
+ * Creates an ID Token from Google's OAuth service and attaches it to the
+ * outgoing request. Useful when calling GCP services or Google APIs that are
+ * secured with GCP IAM.
  *
  * @title Upstream GCP Service Auth
  * @public
@@ -5406,15 +5110,6 @@ declare type UserDataDefault = any;
 /**
  * Validates the body of an incoming request based on a JSON schema.
  *
- * @remarks
- * The Validate JSON Schema policy is used to validate the body of incoming
- * requests. It works using JSON Schemas defined in the `Schemas` folder of your
- * project.
- *
- * When configured, any requests that do not have a body conforming to your JSON
- * schema will be rejected with a `400: Bad Request` response containing a detailed
- * error message (in JSON) explaining why the body was not accepted.
- *
  * @title JSON Body Validation
  * @public
  * @deprecated Use the new {@link https://zuplo.com/docs/policies/request-validation-inbound|Request Validation Policy}.
@@ -5564,10 +5259,7 @@ declare interface XacmlRequest {
 }
 
 /**
- * Parses XML and converts it to JSON. This policy is useful for converting
- * legacy XML or SOAP APIs into modern REST APIs. It can be useful to add a
- * custom outbound policy that runs after this policy to further transform the
- * raw converted content into something more user friendly.
+ * Parses XML and converts it to JSON.
  *
  * @title XML to JSON Outbound
  * @public

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zuplo/runtime",
-  "version": "5.2340.0",
+  "version": "5.2342.0",
   "repository": "https://github.com/zuplo/zuplo",
   "author": "Zuplo, Inc.",
   "exports": {