Skip to main content
The Padel API uses conventional HTTP response codes to indicate the success or failure of an API request.

Success Codes

200 - OK

The request was successful and the response contains the requested data.

Redirection Codes

302 - Found (Redirect)

The requested resource has been moved to a new location. This typically happens when a player, tournament, or match record has been updated or merged with new data. How to handle:
  • Follow the redirect URL provided in the Location header
  • Update any cached references to use the new URL
  • Most HTTP clients handle redirects automatically

Client Error Codes

401 - Unauthenticated

Authentication failed. Your API token is missing, invalid, or has been revoked. How to fix:
  1. Verify you’re including the Authorization header in your request
  2. Check that your token format is correct: Bearer YOUR_API_TOKEN
  3. Generate a new token at API Tokens if needed
Never share your API token publicly or commit it to version control.

402 - Payment Required

Your current subscription plan does not include access to this resource. How to fix:
  1. Check your current plan at padelapi.org/billing
  2. Upgrade your subscription to access premium endpoints
  3. Review the pricing plans for available features

404 - Not Found

The requested resource does not exist. This can happen when:
  • The ID doesn’t exist in the database
  • The resource was deleted
  • There’s a typo in the endpoint URL
How to fix:
  1. Verify the resource ID is correct
  2. Check the endpoint URL for typos
  3. Use a list endpoint to find valid IDs

422 - Unprocessable Entity

The request parameters failed validation. The response includes details about which parameters are invalid. How to fix:
  1. Review the error message for specific validation failures
  2. Check parameter types (string vs integer)
  3. Verify required parameters are included
  4. Ensure values are within allowed ranges

429 - Too Many Requests

You have exceeded the API rate limit. There are two, requests per minute and requests per day, and both return this same code.
The response carries a Retry-After header with the seconds until the exceeded limit resets, and X-RateLimit-Reset with the same moment as a Unix timestamp. A Retry-After of up to 60 seconds means you hit the per-minute limit; a longer one means the daily limit. How to handle:
  1. Stop sending requests until Retry-After has passed, then resume
  2. Do not retry in a loop: every request made while limited is rejected too, and keeps your client blocked
  3. Monitor the X-RateLimit-Remaining header to avoid hitting the limit
  4. Implement request throttling in your application. The Logs & Quota page shows your daily and monthly consumption
See Rate Limits for details on limits and available headers.

Server Error Codes

500 - Internal Server Error

Something went wrong on our servers. We automatically log all errors and work to fix them as quickly as possible. How to handle:
  1. Wait a few moments and retry your request
  2. If the error persists, contact us with the error_time included in the response
When reporting a 500 error, please include the error_time from the response. This helps us locate and fix the issue faster.
Contact support: ferran@padelapi.org

Best Practices

  1. Always check the status code before processing the response body
  2. Handle redirects — Configure your HTTP client to follow 302 redirects
  3. Implement retry logic for 500 errors with exponential backoff
  4. Log error responses to help debug integration issues
  5. Include error_time when reporting server errors to support
Last modified on October 26, 2026