Thank you for your interest in contributing to the LeadMagic OpenAPI specification! This document provides guidelines and instructions for contributing.
- API Discrepancies: If you find the specification doesn't match the actual API behavior
- Documentation Errors: Typos, unclear explanations, or missing information
- Schema Validation Issues: Problems with request/response validation
- Missing Endpoints: If LeadMagic adds new API endpoints
- Better Examples: More realistic or comprehensive API examples
- Use Case Documentation: Additional use cases or implementation guides
- Developer Experience: Tools, scripts, or utilities that help developers
# Clone the repository
git clone https://github.com/LeadMagic/leadmagic-openapi.git
cd leadmagic-openapi
# Set up your API key for testing
export LEADMAGIC_API_KEY=your-api-key-here
# Test the current specification
node test-api.js- Edit
README.mdfor documentation changes - Ensure examples are accurate and helpful
- Test any code examples you add
- Edit both
leadmagic-openapi-3.1.yamlANDleadmagic-openapi-3.1.json - Ensure both files remain synchronized
- Validate the specification:
# Use Swagger CLI or similar tools swagger-codegen validate -i leadmagic-openapi-3.1.yaml
- Edit
test-api.jsto add new test cases - Ensure all tests pass with a valid API key
- Test edge cases and error conditions
# Ensure your API key is set
export LEADMAGIC_API_KEY=your-actual-api-key
# Run the comprehensive test suite
node test-api.js
# Test specific endpoints if you made targeted changes# Use online validators or tools like:
# - Swagger Editor (https://editor.swagger.io/)
# - Spectral CLI for advanced linting
# - OpenAPI Generator for code generation testing- Fork the repository on GitHub
- Create a feature branch from
main:git checkout -b feature/improve-email-validation-docs
- Make your changes following the guidelines above
- Test thoroughly against the live API
- Commit with clear messages:
git commit -m "docs: improve email validation response examples - Added more realistic company data examples - Clarified mx_provider field values - Updated use cases section"
- Push to your fork and create a Pull Request
- Consistent naming: Use
snake_casefor all field names (matches API) - Comprehensive examples: Include realistic, working examples
- Clear descriptions: Write helpful descriptions for all fields and endpoints
- Proper validation: Include appropriate validation rules and constraints
- Clear headings: Use descriptive section headers
- Code examples: Provide copy-paste ready examples
- Use cases: Include practical, real-world use cases
- Consistent formatting: Follow the existing markdown style
- Environment variables: Never hardcode API keys
- Error handling: Test both success and error cases
- Rate limiting: Respect API rate limits in tests
- Clean output: Provide clear, informative test output
- Test with live API: All field names and types must match the actual API
- Response validation: Ensure response schemas accurately reflect API responses
- Error scenarios: Document actual error responses and status codes
- Verify costs: Test actual credit consumption for each endpoint
- Update documentation: Keep credit cost tables current
- Note variations: Document when costs may vary (e.g., "per result")
- Review all changes thoroughly
- Test against live API with multiple scenarios
- Update version numbers if needed
- Create release notes highlighting changes
- Tag releases for stable versions
- Follow semantic versioning for the specification
- Major versions for breaking API changes
- Minor versions for new endpoints or significant additions
- Patch versions for documentation fixes and small improvements
- Respect all contributors and maintainers
- Provide constructive feedback
- Help newcomers get started
- Test changes against the actual API
- Provide evidence for API behavior claims
- Update documentation when the API changes
- Discuss major changes in issues before implementing
- Review others' contributions constructively
- Share knowledge and best practices
- Documentation Issues: Create an issue with the "documentation" label
- API Questions: Check LeadMagic's official documentation
- Specification Questions: Create an issue with the "question" label
- Technical Support: Contact support@leadmagic.io
Contributors will be recognized in:
- Release notes for significant contributions
- README acknowledgments
- GitHub contributor graphs
Thank you for helping make the LeadMagic OpenAPI specification better for all developers! 🎉