16. OTHER REASONS
• When there’s no good built in HTTP request library
• Error handling
• Building clients with 100% API coverage
• Helping users with authentication
• Best practices with complex APIs
@taylor_atx
18. PRODUCT VS COMMUNITY SDKS
• Clearly define the two to set better expectations
• If you don’t build them, Community SDKs will appear
• Leads to a scattered developer experience
• Community SDK bugs will appear in your Support channels
@taylor_atx
19. DOCUMENTATION
• Write the SDK documentation first
• Consistency
• Helps evaluate the experience
@taylor_atx
20. DOCUMENTATION
• Include sections for
• Troubleshooting, with common errors and issues users run
into —> Your Support team will love you for this
• Changelog or release notes
@taylor_atx
21. SCARY WORLD OF DEPENDENCIES
• Help your users navigate it
• Users need to know changes between SDK versions
• Survey your options
😱
@taylor_atx
22. DANGERS OF NOT MAKING YOUR OWN SDKS
• Not eating your own dog food is dangerous
• Helps you understand the cost of building with your own API
• It’s also encouragement to add new API features into your
SDK when they released, not later
@taylor_atx
23. NATIVE AS POSSIBLE
• Please do not auto generate SDKs badly from your API
• Example: Go find a Go developer to write your Go SDK
• Start with the languages that are the most popular for your
target audience and that your team is familiar with
@taylor_atx
24. COMMON DATA STRUCTURES
• Avoid inconsistency in your users’ code
• Example: JSON is a great option for representing data
• Want to map well to data structures in many different
languages
@taylor_atx
25. USAGE TRACKING
• Great opportunity to learn about your users
• Critical statistics for developing, maintaining, and improving
your SDKs
• Every popular API company today is tracking this: SendGrid,
Twilio, Stripe, Dropbox, etc.
@taylor_atx
📊