When Callback Is Not Received

More often than not, requests that include a callback URL should receive an asynchronous response, even if the callback receives an error.

When attempting to transcribe a large audio file, there are multiple reasons you may not receive your transcription.

📘

As of the moment of publishing this guide, you cannot yet see whether a callback errored from the Deepgram Console usage logs.

Express.js bodyParser / Next.js API Routes

Some serverless, including popular architecture like Express.s, use bodyParser to understand the body of the request being passed to your application.

By default, bodyParser includes a small default maximum payload size of 100kb, to responsibly limit impact of memory allocation on the server running your application. Essentially, you knowingly need to increase this, and hopefully understand what that would mean for the architecture you're working on. Especially for serverless environments.

If this limit is reached when Deepgram attempts a callback request, bodyParser will return a 413 Request Entity Too Large response. Your server will most likely log the errors occurance, as it rejects the request from Deepgram.

bodyParser Solution

For bodyParser being used as middleware, you need to configure the parser with a new limit.

// parse application/json
jsonParser = bodyParser.json({
  limit: '1mb' // raise from 100kb to 1mb
})

// parse raw
rawParser = bodyParser.raw({
  limit: '1mb' // raise from 100kb to 1mb
})

Next.js API Routes Solution

To resolve this error in in Next.js API Routes, you need to configure the parser with a new limit. At the top of your API Routes file, include additional config.

export const config = {
  api: {
    bodyParser: {
      sizeLimit: '1mb', // raise from 100kb to 1mb
    },
  }
}

NGINX

Many hosted servers, particularly NGINX based servers, have a maximum payload size for incoming requests. For example, NGINX has a default maximum payload size of 1 MB, which could be insufficient for larger transcripts.

A server will reject a callback due to the transcript size exceeding the payload limit, returning a 413 code and the message Request entity too large/Content too large/Payload too large, depending on which server receives the large payload.

NGINX Solution

To resolve the "Payload too large" issue for NGINX, follow these steps:

1. Confirm the server's maximum payload size: Determine if the server you are using has a maximum payload size limit. NGINX servers, for example, typically have a maximum payload size of 1 MB by default.
2. Adjust NGINX server configuration: You can modify the NGINX configuration to increase the maximum payload size. Locate and edit the NGINX configuration file, typically named nginx.conf, and find the client_max_body_size directive (or add it, if it's missing). Adjust its value to accommodate your transcript size. For example, if your transcript is 5 MB, you may set the value to 5m or higher.
3. Restart the server: After modifying the server configuration, save the changes and restart the server to apply the new settings. If you are running a Linux server, the command service nginx reload will restart the NGINX server.
4. Retry the transcription request: Once the server is restarted, attempt the transcription again. Ensure the transcript size now falls within the updated maximum payload limit. If successful, the 413: Payload too large error should no longer occur.