Genace
Sign inGet started

generation API request size limit: enforce a clear policy in your proxy

A public generation proxy needs a body-size policy even if the upstream model requires only a nonempty prompt. Body bytes, prompt characters, array length, and reference image bytes are different limits. Define each at the appropriate boundary and tell users which values are application policy rather than a documented Genace-wide guarantee.

Bound bytes before JSON parsing

Configure the reverse proxy or framework body parser to reject oversized requests before allocating an unrestricted body. A Content-Length check can reject some requests early, but it is not sufficient when the header is missing or the transport streams a body. The actual consumed bytes must remain bounded too.

An Express application can begin with an explicit parser policy like this:

app.use(express.json({ limit: '16kb', type: 'application/json' }));

app.use((error, request, response, next) => {
  if (error.type === 'entity.too.large') {
    return response.status(413).json({ error: 'Request exceeds this application limit' });
  }
  return next(error);
});

This snippet belongs inside your own Express setup and assumes Express is already imported. Sixteen kilobytes is an example local setting, not the Genace gateway’s published maximum. Ensure the error handler is placed after routes or parsers whose errors it must handle in your actual application.

Validate the parsed structure separately

Once parsing succeeds, trim prompts, enforce your character policy, allow only reviewed fields, and validate model-specific numeric ranges. A small JSON document can still ask for a larger image batch or expensive video parameters. Conversely, a long escaped string can use many more bytes than its visible prompt length suggests.

Reference images should be represented by reachable URLs in image_inputs, not copied as arbitrary base64 blobs into this JSON contract. Validate the number and URL policy you support. Image upload byte limits belong to the upload pipeline and should not be confused with the generation request-body limit.

Preserve useful rejection categories

The current generation routes parse JSON and report INVALID_JSON for parsing errors. Provider schemas then validate supported parameters. They do not declare one comprehensive public maximum body size in those handlers. Hosting infrastructure may impose additional limits, so do not derive a universal promise from a local observation.

Return a controlled application 413 when your own parser rejects size, a validation error when the parsed fields are unsupported, and an appropriate upstream error when a forwarded request fails. Keep the stage in telemetry without logging the entire rejected body.

Test the real boundary

Create requests just below and above the byte limit, including multibyte text and escaped characters. Test missing Content-Length through the transport your platform supports and confirm streamed input cannot bypass the cap. Verify rejected requests never call the generation client.

Also test a tiny body with an excessive batch value and a valid body with an unsupported field. These cases prove byte limits and semantic validation are independent controls. A user should receive a useful correction path without your service creating a paid job as part of validation.

See JSON content types, input validation, and upload validation.

Continue with security

Where these facts come from