Detect plagiarized and similar code across trillions of code sources on the web See what's new
Developer API

Limits & Security

Build plagiarism detection into your apps. Check code against 20+ billion sources.

const response = await fetch('https://codequiry.com/api/v1/check', { method: 'POST', headers: { 'apikey': 'YOUR_API_KEY' }, body: formData }); // Check created!
LIMITS & SECURITY

API Limits & Security

Understanding API usage limits, security measures, and best practices to ensure optimal performance and compliance with Codequiry's fair usage policies.

API Usage Limits

Two separate limits apply to the API: a request rate limit (how often you may call it) and your check credits (how much analysis you may run). They are independent — the rate limit is the same on every plan, while credits are what your plan actually buys you.

Request rate — same on every plan

60 requests/minute, counted per client IP address across the whole /api/v1 surface. Exceeding it returns 429. Upgrading your plan does not raise it.

Check credits — set by your plan

Each started check consumes credits based on the engine you pick (see Test Types). GET /api/v1/account returns your live balance in quota.remaining.

Upload limits

10 MB per ZIP and .zip only, on both /check/upload and /check/upload-batch. Batch uploads accept at most 50 files per request — call it repeatedly to add more.

There is no per-check submission cap. You can keep uploading ZIPs to the same check_id until you start it; the practical ceiling is analysis time, not a quota.

Security & Authentication

API Key Security

Best Practices:

  • Store API keys in environment variables
  • Never commit keys to version control
  • Rotate keys regularly (monthly)
  • Use different keys for dev/staging/prod
  • Implement key rotation in CI/CD
Example Implementation:
                # Environment variables
CODEQUIRY_API_KEY=your-production-key
CODEQUIRY_DEV_API_KEY=your-development-key

# .gitignore
.env
.env.local
*.key
                
Security
Data Protection

Security Measures:

  • HTTPS/TLS 1.3 - All API communication encrypted
  • SOC 2 Infrastructure - Enterprise security standards
  • GDPR Compliant - EU data protection
  • Data Retention - Configurable retention policies
  • Access Logging - Complete audit trails
Headers Required:
                apikey: your-api-key-here
Accept: application/json
Content-Type: application/json
User-Agent: YourApp/1.0
                
Headers

Rate Limiting Details

The API uses a fixed one-minute window. Your first request opens the window; the counter resets 60 seconds later. There is no burst allowance above the limit and no separate per-endpoint limit — every /api/v1 call draws on the same counter.

Property Value
Limit 60 requests per minute — identical on every plan, including Enterprise
Counted per Client IP address, not per API key
Window Fixed 60-second window, no burst allowance
Scope Shared across all /api/v1 endpoints
Over limit 429 Too Many Requests with a Retry-After header (seconds)
The limit is per IP, so keys share it. Several API keys calling from the same server — or from one NAT gateway, CI runner, or serverless region — draw on a single 60/minute budget. Failed calls count too: a 401 from a bad key still consumes one request. Budget for the host, not the key.
Rate limit headers
Header Sent on Meaning
X-RateLimit-Limit Every response Always 60.
X-RateLimit-Remaining Every response Calls left in the current window.
Retry-After 429 only Seconds to wait before retrying.
X-RateLimit-Reset 429 only Unix timestamp when the window reopens.
Throttle on X-RateLimit-Remaining, not on X-RateLimit-Reset. X-RateLimit-Reset is only present once you have already been throttled, so a client that waits for it will never see it on the successful responses leading up to the limit.

Abuse Prevention

Automated systems monitor usage patterns to prevent abuse while maintaining service quality for legitimate users.

Usage Monitoring

Monitored Patterns:

  • Abnormal request volumes
  • Repeated failed requests
  • Unusual upload patterns
  • Resource-intensive operations
  • Suspicious API key usage
Progressive Actions

Response Sequence:

  1. Warning - Email notification
  2. Throttling - Reduced rate limits
  3. Queue Priority - Lower processing priority
  4. Temporary Suspension - 24-48 hour cooldown
  5. Account Review - Manual investigation
Best Practices

Avoid Issues:

  • Implement exponential backoff
  • Cache results when possible
  • Batch operations efficiently
  • Monitor rate limit headers
  • Use appropriate timeouts

Processing Time Guidelines

Understanding typical processing times helps with application design and user expectations.

Check Size File Count Standard Queue Priority Queue Factors
Small 1-10 files 2-5 minutes 1-3 minutes File size, language complexity
Medium 11-50 files 5-15 minutes 3-10 minutes Peer comparisons, web search depth
Large 51-200 files 15-45 minutes 10-30 minutes Database size, analysis thoroughness
Enterprise 200+ files 45+ minutes 30+ minutes Custom processing, detailed analysis
Timeout Recommendations: Set client timeouts to at least 60 minutes for large checks. Use polling with 30-second intervals to monitor progress.

Implementation Guidelines

Error Handling
        // Robust error handling
async function makeApiRequest(url, options) {
    const maxRetries = 3;
    let attempt = 0;

    while (attempt < maxRetries) {
        try {
            const response = await fetch(url, options);

            if (response.status === 429) {
                // Rate limited - exponential backoff
                const delay = Math.pow(2, attempt) * 1000;
                await new Promise(resolve => setTimeout(resolve, delay));
                attempt++;
                continue;
            }

            if (!response.ok) {
                throw new Error(`HTTP ${response.status}: ${response.statusText}`);
            }

            return await response.json();

        } catch (error) {
            attempt++;
            if (attempt === maxRetries) {
                throw error;
            }

            // Linear backoff for other errors
            await new Promise(resolve => setTimeout(resolve, 2000 * attempt));
        }
    }
}
        
Error Handling
Rate Limit Monitoring
        # Monitor rate limits
class RateLimitMonitor:
    def __init__(self):
        self.remaining = None
        self.reset_time = None

    def update_from_headers(self, headers):
        self.remaining = int(headers.get('X-RateLimit-Remaining', 0))
        self.reset_time = int(headers.get('X-RateLimit-Reset', 0))

        # Warn when approaching limit
        if self.remaining < 10:
            print(f"⚠️ Rate limit warning: {self.remaining} requests remaining")

        # Pause if rate limited
        if self.remaining <= 0:
            wait_time = self.reset_time - time.time()
            if wait_time > 0:
                print(f"Rate limited. Waiting {wait_time:.0f} seconds...")
                time.sleep(wait_time)

    def should_throttle(self):
        return self.remaining is not None and self.remaining < 5
        
Monitoring

Support & Resources

Technical Resources
Support Channels