502 Bad Gateway Errors

Why Am I Getting a 502 or Payload Error?

If your API call returns a502 Bad Gatewayor times out, it usually means the response payload is too large to process. This typically happens when:

You request a large page_size (e.g., 100).

Each returned record contains rich nested data, such as long skill lists, full education history, detailed patents, or extensive job experiences.

✅ Best Practices to Avoid Payload Errors

1. 🔁 Use Pagination Parameters

To control the volume of data returned and keep response sizes manageable, use the following parameters:

Parameter	Description	Default	Required
page_size	Number of results to return per page (1–100).	20	Optional
page_number	The page index to retrieve.	1	Optional

Tip: Start with page_size: 10–25 to reduce the risk of large payloads.

2. 🧠 Understand Which Fields Increase Response Size

Each profile may contain:

Field	Impact on Size	Description
r_skills	High	Detailed and lengthy lists of skills
education	High	Multiple degrees with descriptions and dates
patents	High	Long text, grant info, inventor details
experiences	Very High	Role history, companies, responsibilities, dates

Requesting many records where these fields are populated increases the risk of exceeding response limits.

Examples

❌ Example Likely to Fail (Too Large)

{  
  "parameters": {  
    "completion_rate": [  
      {  
        "operator": "greater than",  
        "value": 0.89  
      }  
    ]  
  },  
  "reveal_all_data": false,  
  "page_size": 100  
}

🔴 Why? Even if records match your query, 100 complete profiles can exceed payload limits due to rich nested data (skills, experience, educations,...).

🧪 Example - revised

{  
  "parameters": {  
    "completion_rate": [  
      {  
        "operator": "greater than",  
        "value": 0.89  
      }  
    ]  
  },  
  "reveal_all_data": false,  
  "page_size": 20
  "page_number": 1
}

✅ What Was Corrected?
In this version:

The page_size was reduced from a large value (e.g., 100) to a safer limit of 20. This helps keep the total response payload well under the system's maximum threshold.

The page_number was explicitly added, allowing users to paginate through the result set in smaller, controlled batches rather than retrieving all matching records at once.

This approach helps avoid timeouts or 502 errors while still allowing complete access to your data, page by page.

💬 Need Help?

Still seeing issues? Reach out to [email protected]

We're happy to help you fine-tune your query structure or provide alternate access options for high-volume data needs.