Building robust integrations with Schiphol APIs requires following best practices that ensure reliability, performance, and a great user experience. This guide covers the essential patterns every developer should know.

Rate Limiting

All Schiphol APIs implement rate limiting to ensure fair usage and system stability. Understanding and respecting these limits is crucial for building reliable applications.

• Public tier: 100 requests per minute
• Partner tier: 1,000 requests per minute
• Private tier: 10,000 requests per minute

Caching Strategies

Many API responses can be cached to reduce the number of requests and improve performance:

• Static data (airlines, destinations) – Cache for 24 hours
• Flight schedules – Cache for 5-15 minutes
• Real-time status – Cache for 1-2 minutes maximum

Error Handling

Proper error handling ensures your application degrades gracefully when issues occur:

Always check HTTP status codes

• 200-299 – Success, process the response
• 400-499 – Client error, check your request
• 500-599 – Server error, retry with backoff

Handle specific error cases

• 401 – Refresh your authentication token
• 404 – Resource not found, check the ID or flight number
• 429 – Rate limited, wait before retrying
• 503 – Service temporarily unavailable, retry later

Versioning

Always specify the API version in your requests to avoid breaking changes:

• Use the Accept header: Accept: application/json; version=4
• Monitor our News & Updates for version announcements
• Test new versions in sandbox before upgrading production

Security Best Practices

• Never expose API keys in client-side code or public repositories
• Use environment variables to store credentials
• Rotate API keys regularly (at least every 90 days)
• Use separate API keys for development and production
• Monitor your API usage for unusual patterns

Need More Help?

Check out our API documentation for detailed endpoint references, or contact our developer support team if you have specific questions about your integration.